PCE Working Group
Internet Engineering Task Force (IETF) B. Rajagopalan
Internet-Draft
Request for Comments: 9863 V. Beeram
Intended status:
Category: Standards Track Juniper Networks
Expires: 30 August 2025
ISSN: 2070-1721 S. Peng
ZTE Corporation
M. Koldychev
Ciena Corporation
G. Mishra
Verizon Communications Inc.
26 February
September 2025
Path Computation Element Protocol (PCEP) Extension for Color
draft-ietf-pce-pcep-color-12
Abstract
Color is a 32-bit numerical (unsigned integer) attribute used to
associate a Traffic Engineering (TE) tunnel or policy with an intent
or objective. For example, a TE Tunnel constructed to deliver low
latency services and whose path is optimized for delay can be tagged
with a color that represents "low latency." This document specifies
extensions to the Path Computation Element Protocol (PCEP) to carry
the color attribute.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for a maximum publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of six months RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 30 August 2025.
https://www.rfc-editor.org/info/rfc9863.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info)
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4
3.1. Color Capability . . . . . . . . . . . . . . . . . . . . 4
3.2. Color TLV . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. Manageability Considerations . . . . . . . . . . . . . . . . 5
5.1. Control of Function through Configuration and Policy . . 5
5.2. Information and Data Models . . . . . . . . . . . . . . . 5
5.3. Liveness Detection and Monitoring . . . . . . . . . . . . 5
5.4. Verifying Correct Operation . . . . . . . . . . . . . . . 6
5.5. Requirements on Other Protocols . . . . . . . . . . . . . 6
5.6. Impact on Network Operation . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6.1. PCEP TLV Type Indicator . . . . . . . . . . . . . . . . . 6
6.2. STATEFUL-PCE-CAPABILITY TLV Flag Field . . . . . . . . . 6
6.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 6
6.4. LSP-ERROR-CODE TLV Error Code Field . . . . . . . . . . . 7
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1.
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2.
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgments
Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
A Traffic Engineering (TE) tunnel ([RFC3209]) [RFC3209] or Segment Routing (SR)
policy ([RFC9256]) [RFC9256] can be associated with an intent or objective (e.g.,
low latency) by tagging it with a color. This color attribute is
used as a guiding criterion for mapping services onto the TE tunnel ([RFC9012])
[RFC9012] or SR policy ([RFC9256]). [RFC9256]. The term color "color" used in this
document must not be interpreted as the 'thread color' "thread color" specified in
[RFC3063] or the 'resource color' "resource color" (also referred to as 'link
color') "link color")
specified in [RFC3630], [RFC5329], [RFC5305] [RFC5305], and [RFC7308].
[RFC8231] specifies extensions to the Path Computation Element
Protocol (PCEP) that enable the deployment of a stateful Path
Computation Element (PCE) model. These extensions allow a Path
Computation Client (PCC) to delegate control of the Label Switched
Paths (LSPs) associated with its TE Tunnels to a stateful PCE.
[RFC8281] specifies extensions that allow a PCE to instantiate and
manage PCE-initiated LSPs on a PCC under the stateful PCE model.
[RFC8664] specifies extensions that enable stateful control of SR
paths via PCEP.
This document introduces extensions to PCEP to allow a color tag to
be assigned to any TE path operated under a stateful PCE model
(including those set up using RSVP-TE [RFC8408] or Segment Routing
[RFC8664]). The only exception where the extensions defined in this
document MUST NOT be used to carry the color attribute is for SR
paths established using the extensions defined in
[I-D.ietf-pce-segment-routing-policy-cp]. [RFC9862]. For
these SR paths, the associated color is already included as part of
the SR policy identifier encoding.
The mechanism employed by the PCC for mapping services onto a TE path
associated with a color attribute is outside the scope of this
document, as is any other use of the color tag.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Protocol Operation
When the PCEP session is created, a PCEP (PCE/PCC) speaker sends an
Open message with an OPEN object that contains the STATEFUL-PCE-
CAPABILITY TLV, as defined in [RFC8231]. A STATEFUL-PCE-CAPABILITY
TLV Flag (See (see Section 3.1) is introduced in this document to enable
the PCEP speaker to advertise color capability.
In PCRpt, PCUpd, and PCInitiate messages, the LSP object ([RFC8231],
[RFC8281]) [RFC8231]
[RFC8281] is a mandatory inclusion and is used to carry information
specific to the target LSP. A TLV called the Color TLV (see
Section 3.2), which MAY be carried in the LSP object, is introduced
in this document to carry the color attribute associated with the
LSP. Only one COLOR TLV SHOULD be included in the LSP object. If
the COLOR TLV appears in the LSP object more than once, only the
first occurrence is processed, and any others MUST be ignored.
A PCEP speaker that has advertised color capability MUST NOT send
Color TLV encoded in the LSP object to a PCEP Peer that has not
advertised color capability. A PCEP speaker that advertises both
color capability and SR Policy Association [RFC9862] capability
([I-D.ietf-pce-segment-routing-policy-cp]) MUST
NOT send Color TLV encoded in the LSP object for SR Paths. The Color
TLV is ignored if it shows up in the LSP object of a message which that
carries an ASSOCIATION object of type SR Policy Association
([I-D.ietf-pce-segment-routing-policy-cp]).
[RFC9862]. The color encoded in the SR Policy Association takes
precedence in such a scenario.
If a PCC is unable to honor a color value passed in a PCUpd or a
PCInitiate message, the PCC MUST reject the message and send a PCErr
message with Error-type=19 Error-Type=19 (Invalid Operation) and error-value=TBD1 Error-value=31
(Invalid color). This is expected behavior in scenarios where a PCC
implementation does not support a color value of zero for specific
path setup types, and it receives that value in the COLOR TLV of a
PCUpd or a PCInitiate message.
When LSPs that belong to the same TE tunnel are within the same Path
Protection Association Group [RFC8745], they are all expected to have
the same color attached to them. If a PCEP speaker determines
inconsistency in the color associated with the LSPs belonging to the
same Path Protection Association Group, it MUST reject the message
carrying the inconsistent color and send a PCErr message with Error-
type=19
Type=19 (Invalid Operation) and error-value=TBD2 Error-value=32 (Inconsistent color).
3. Protocol Extensions
3.1. Color Capability
Section 7.1.1 of [RFC8231] defines STATEFUL-PCE-CAPABILITY TLV flags.
The following flag is used to indicate if the speaker supports color
capability:
C-bit (Bit 20): A PCE/PCC indicates that it supports the color
capability defined in this document by setting this bit.
3.2. Color TLV
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Color TLV
Type has the value 67. Length carries a value of 4. The 'color' "Color"
field is 4-bytes long, 4 bytes long and carries the actual color value (specified
as an unsigned integer). A color Color value of zero is allowed.
4. Security Considerations
This document defines a TLV for color and a flag for color capability
negotiation, which do not add any security concerns beyond those
discussed in [RFC5440], [RFC8231] [RFC8231], and [RFC8281].
An unauthorized PCE may maliciously associate the LSP with an
incorrect color. The procedures described in [RFC8253] and [RFC9325]
can be used to protect against this attack.
5. Manageability Considerations
This section follows the advice and guidance of [RFC6123].
5.1. Control of Function through Configuration and Policy
An implementation supporting this document SHOULD allow the operator
to turn on and off the PCEP color capability advertisement
(Section 3.1). An implementation supporting this document SHOULD
allow the configuration of color assignment to a TE Tunnel or an SR
Policy. A PCC MAY have a local policy configuration that specifies
how the color tag is used. This policy configuration is outside the
scope of this document.
5.2. Information and Data Models
An implementation supporting this document SHOULD allow the inclusion
of color in the data model used to retrieve the operational state of
a TE tunnel or an SR policy. The YANG model in
[I-D.ietf-teas-yang-te] [YANG-TE] could be
used to retrieve the operational state of a TE tunnel, and the YANG
model in
[I-D.ietf-spring-sr-policy-yang] [SR-POLICY-YANG] could be used to retrieve the operational
state of an SR policy.
5.3. Liveness Detection and Monitoring
The extensions defined in this document do not require any additional
liveness detection and monitoring support. See [RFC5440] and
[RFC5886] for more information.
5.4. Verifying Correct Operation
The operator MAY retrieve the operational state of TE Paths to verify
if they are tagged with the correct intended color.
5.5. Requirements on Other Protocols
This document places no explicit requirements on other protocols.
5.6. Impact on Network Operation
The impact on network operations depends on how the color tag is used
in the deployment. This is outside the scope of this document.
6. IANA Considerations
6.1. PCEP TLV Type Indicator
This document introduces
IANA has assigned a value in the "PCEP TLV Type Indicators" registry
of the "Path Computation Element Protocol (PCEP) Numbers" registry
group as follows:
+=======+=============+===========+
| Value | Description | Reference
---------------------------------------------- |
+=======+=============+===========+
| 67 | Color This document
Note: The code point specified for the TLV Type Indicator is an early
allocation by IANA. | RFC 9863 |
+-------+-------------+-----------+
Table 1
6.2. STATEFUL-PCE-CAPABILITY TLV Flag Field
This document introduces
IANA has assigned a bit value in the "STATEFUL-PCE-CAPABILITY TLV
Flag Field" registry of the "Path Computation Element Protocol (PCEP)
Numbers" registry group as follows:
+=======+==================+===========+
| Value | Description | Reference
---------------------------------------------- |
+=======+==================+===========+
| 20 | COLOR-CAPABILITY This document
Note: The code point specified for the STATEFUL-PCE-CAPABILITY TLV
Flag is an early allocation by IANA. | RFC 9863 |
+-------+------------------+-----------+
Table 2
6.3. PCEP-Error Object
This document introduces
IANA has assigned two Error-values for Error-Type=19 (Invalid
Operation) within the "PCEP-ERROR Object Error Types and Values"
registry of the "Path Computation Element Protocol (PCEP) Numbers"
registry group as follows:
Error-
+============+===================+===================+===========+
| Error-Type | Meaning | Error-value | Reference
Type
------------------------------------------------------------------ |
+============+===================+===================+===========+
| 19 | Invalid Operation TBD1: | 31: Invalid Color This document
TBD2: | RFC 9863 |
| | +-------------------+-----------+
| | | 32: Inconsistent | RFC 9863 |
| | | Color This document | |
+------------+-------------------+-------------------+-----------+
Table 3
6.4. LSP-ERROR-CODE TLV Error Code Field
An earlier
A draft version of this document added an error code in the "LSP-
ERROR-CODE TLV Error Code Field" registry of the "Path Computation
Element Protocol (PCEP) Numbers" registry group, which was also early
allocated by the IANA.
IANA is requested to cancel the early allocation made which is not
needed anymore. As per the instructions from the chairs, please mark has marked it as deprecated.
+=======+================================+===========+
| Value | Meaning | Reference
------------------------------------------------------ |
+=======+================================+===========+
| 9 | Deprecated (Unsupported Color) This document
7. Implementation Status
[Note to the RFC Editor - remove this section before publication, as
well as remove the reference to | RFC 7942.]
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to [RFC7942], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
At the time of publication of this version, there are no known
implementations. Juniper Networks has plans to implement the
extensions defined in this document.
8. Acknowledgments
The authors would like to thank Kaliraj Vairavakkalai, Colby Barth,
Natrajan Venkataraman, Tarek Saad, Dhruv Dhody, Adrian Farrel, Andrew
Stone, Diego Achaval, and Narasimha Kommuri for their review and
suggestions.
9. Contributors
The following people have contributed to this document:
Quan Xiong
ZTE Corporation
Email: xiong.quan@zte.com.cn
10. 9863 |
+-------+--------------------------------+-----------+
Table 4
7. References
10.1.
7.1. Normative References
[I-D.ietf-pce-segment-routing-policy-cp]
Koldychev, M., Sivabalan, S., Sidor, S., Barth, C., Peng,
S., and H. Bidgoli, "Path Computation Element
Communication Protocol (PCEP) Extensions for Segment
Routing (SR) Policy Candidate Paths", Work in Progress,
Internet-Draft, draft-ietf-pce-segment-routing-policy-cp-
22, 25 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
segment-routing-policy-cp-22>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>.
[RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
Hardwick, "Conveying Path Setup Type in PCE Communication
Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408,
July 2018, <https://www.rfc-editor.org/info/rfc8408>.
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "Path Computation Element Communication
Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
DOI 10.17487/RFC8664, December 2019,
<https://www.rfc-editor.org/info/rfc8664>.
[RFC8745] Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I.,
and M. Negi, "Path Computation Element Communication
Protocol (PCEP) Extensions for Associating Working and
Protection Label Switched Paths (LSPs) with Stateful PCE",
RFC 8745, DOI 10.17487/RFC8745, March 2020,
<https://www.rfc-editor.org/info/rfc8745>.
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
"The BGP Tunnel Encapsulation Attribute", RFC 9012,
DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/info/rfc9012>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
10.2. Informative References
[I-D.ietf-spring-sr-policy-yang]
Raza, S. K., Saleh, T., Shunwan, Z., Voyer, D., Durrani,
[RFC9862] Koldychev, M., Matsushima, Sivabalan, S., Sidor, S., Barth, C., Peng,
S., and V. P. Beeram, "YANG Data Model H. Bidgoli, "Path Computation Element
Communication Protocol (PCEP) Extensions for Segment
Routing Policy", Work in Progress, Internet-Draft,
draft-ietf-spring-sr-policy-yang-04, 22 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
sr-policy-yang-04>.
[I-D.ietf-teas-yang-te]
Saad, T., Gandhi, R., Liu, X., Beeram, V. P., and I.
Bryskin, "A YANG Data Model for Traffic Engineering
Tunnels, Label Switched Paths and Interfaces", Work in
Progress, Internet-Draft, draft-ietf-teas-yang-te-37, 9
October 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-teas-yang-te-37>. (SR) Policy Candidate Paths", RFC 9862,
DOI 10.17487/RFC9862, September 2025,
<https://www.rfc-editor.org/info/rfc9862>.
7.2. Informative References
[RFC3063] Ohba, Y., Katsube, Y., Rosen, E., and P. Doolan, "MPLS
Loop Prevention Mechanism", RFC 3063,
DOI 10.17487/RFC3063, February 2001,
<https://www.rfc-editor.org/info/rfc3063>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,
"Traffic Engineering Extensions to OSPF Version 3",
RFC 5329, DOI 10.17487/RFC5329, September 2008,
<https://www.rfc-editor.org/info/rfc5329>.
[RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of
Monitoring Tools for Path Computation Element (PCE)-Based
Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010,
<https://www.rfc-editor.org/info/rfc5886>.
[RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path
Computation Element (PCE) Working Group Drafts", RFC 6123,
DOI 10.17487/RFC6123, February 2011,
<https://www.rfc-editor.org/info/rfc6123>.
[RFC7308] Osborne, E., "Extended Administrative Groups in MPLS
Traffic Engineering (MPLS-TE)", RFC 7308,
DOI 10.17487/RFC7308, July 2014,
<https://www.rfc-editor.org/info/rfc7308>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
[SR-POLICY-YANG]
Raza, S. K., Saleh, T., Zhuang, S., Voyer, D., Durrani,
M., Matsushima, S., and V. P. Beeram, "YANG Data Model for
Segment Routing Policy", Work in Progress, Internet-Draft,
draft-ietf-spring-sr-policy-yang-05, 25 May 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
sr-policy-yang-05>.
[YANG-TE] Saad, T., Gandhi, R., Liu, X., Beeram, V. P., and I.
Bryskin, "A YANG Data Model for Traffic Engineering
Tunnels, Label Switched Paths and Interfaces", Work in
Progress, Internet-Draft, draft-ietf-teas-yang-te-38, 29
May 2025, <https://datatracker.ietf.org/doc/html/draft-
ietf-teas-yang-te-38>.
Acknowledgments
The authors would like to thank Kaliraj Vairavakkalai, Colby Barth,
Natrajan Venkataraman, Tarek Saad, Dhruv Dhody, Adrian Farrel, Andrew
Stone, Diego Achaval, and Narasimha Kommuri for their review and
suggestions.
Contributors
The following people have contributed to this document:
Quan Xiong
ZTE Corporation
Email: xiong.quan@zte.com.cn
Authors' Addresses
Balaji Rajagopalan
Juniper Networks
Email: balajir@juniper.net
Vishnu Pavan Beeram
Juniper Networks
Email: vbeeram@juniper.net
Shaofu Peng
ZTE Corporation
Email: peng.shaofu@zte.com.cn
Mike Koldychev
Ciena Corporation
Email: mkoldych@proton.me
Gyan Mishra
Verizon Communications Inc.
Email: gyan.s.mishra@verizon.com