RFC 8233

Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs)

📅 published September 2017, from ietf

Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs) 🎀

Okay bestie, the title block is giving everything 📋 This is RFC 8233 from the Internet Engineering Task Force (IETF), filed under Standards Track ✨. It's dated September 2017 and has ISSN 2070-1721. The authors are D. Dhody (Huawei), Q. Wu (Huawei), V. Manral (Nano Sec Co), Z. Ali (Cisco Systems), and K. Kumaki (KDDI Corporation) 💜 The title block doesn't list anything this RFC obsoletes or updates, so it stands on its own 🌸

Abstract 💖

In certain networks, like financial information networks (think stock market data providers, but not only those), network performance criteria such as latency are becoming just as critical to data path selection as other metrics and constraints 📈 These metrics are tied to the Service Level Agreement (SLA) between customers and service providers. Link bandwidth utilization (the total bandwidth of a link actually in use for forwarding) is another big factor to consider during path computation 🔥

IGP Traffic Engineering (TE) Metric Extensions describe the mechanisms that distribute network performance information via OSPF and IS-IS, respectively 🦋 The Path Computation Element Communication Protocol (PCEP) gives Path Computation Elements (PCEs) a way to do path computations in response to Path Computation Client (PCC) requests 🧚 This document extends PCEP to carry latency, delay variation, packet loss, and link bandwidth utilization as constraints for end-to-end path computation 👑

Status of This Memo 📜

This one's an Internet Standards Track document, so it's the real deal ✨

It's a product of the IETF and represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards lives in Section 2 of RFC 7841 💅

Info about the current status of this document, any errata, and how to give feedback on it is at https://www.rfc-editor.org/info/rfc8233 🌈

Copyright (c) 2017 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) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions with respect to this document 📖 Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 💜

Table of Contents 🌸

1. Introduction ....................................................3
   1.1. Requirements Language ......................................4
2. Terminology .....................................................4
3. PCEP Extensions .................................................5
   3.1. Extensions to METRIC Object ................................5
        3.1.1. Path Delay Metric ...................................6
               3.1.1.1. Path Delay Metric Value ....................7
        3.1.2. Path Delay Variation Metric .........................7
               3.1.2.1. Path Delay Variation Metric Value ..........8
        3.1.3. Path Loss Metric ....................................8
               3.1.3.1. Path Loss Metric Value .....................9
        3.1.4. Non-Understanding / Non-Support of
               Service-Aware Path Computation ......................9
        3.1.5. Mode of Operation ..................................10
               3.1.5.1. Examples ..................................11
        3.1.6. Point-to-Multipoint (P2MP) .........................11
               3.1.6.1. P2MP Path Delay Metric ....................11
               3.1.6.2. P2MP Path Delay Variation Metric ..........12
               3.1.6.3. P2MP Path Loss Metric .....................12
   3.2. Bandwidth Utilization .....................................12
        3.2.1. Link Bandwidth Utilization (LBU) ...................12
        3.2.2. Link Reserved Bandwidth Utilization (LRBU) .........13
        3.2.3. Bandwidth Utilization (BU) Object ..................13
               3.2.3.1. Elements of Procedure .....................14
   3.3. Objective Functions .......................................15
4. Stateful PCE and PCE Initiated LSPs ............................16
5. PCEP Message Extension .........................................17
   5.1. The PCReq Message .........................................17
   5.2. The PCRep Message .........................................18
   5.3. The PCRpt Message .........................................19
6. Other Considerations ...........................................20

   6.1. Inter-domain Path Computation .............................20
        6.1.1. Inter-AS Links .....................................20
        6.1.2. Inter-Layer Path Computation .......................20
   6.2. Reoptimizing Paths ........................................21
7. IANA Considerations ............................................21
   7.1. METRIC Types ..............................................21
   7.2. New PCEP Object ...........................................22
   7.3. BU Object .................................................22
   7.4. OF Codes ..................................................22
   7.5. New Error-Values ..........................................23
8. Security Considerations ........................................23
9. Manageability Considerations ...................................24
   9.1. Control of Function and Policy ............................24
   9.2. Information and Data Models ...............................24
   9.3. Liveness Detection and Monitoring .........................24
   9.4. Verify Correct Operations .................................24
   9.5. Requirements on Other Protocols ...........................24
   9.6. Impact on Network Operations ..............................24
10. References ....................................................25
    10.1. Normative References .....................................25
    10.2. Informative References ...................................26
Appendix A. PCEP Requirements .....................................28
Acknowledgments ...................................................29
Contributors ......................................................30
Authors' Addresses ................................................31

1. Introduction ✨

Real-time network performance info is becoming super critical for path computation in some networks 🦋 Mechanisms to measure latency, delay variation, and packet loss in an MPLS network are described in [RFC6374]. It really matters that these get considered during path selection, even before the Label Switched Path (LSP) is set up 👑

Link bandwidth utilization based on real-time traffic along the path is also becoming critical during path computation in some networks. So it's important that it gets factored in during path computation too 💅

The Traffic Engineering Database (TED) gets filled with network performance info like link latency, delay variation, packet loss, and bandwidth parameters (residual bandwidth, available bandwidth, and utilized bandwidth). That happens through TE Metric Extensions in OSPF [RFC7471] or IS-IS [RFC7810], or through a management system 🧚 [RFC7823] explains how a Path Computation Element (PCE) [RFC4655] can use that info for path selection for explicitly routed LSPs 🌸

A Path Computation Client (PCC) can ask a PCE for a path that meets end-to-end network performance criteria. This document extends the Path Computation Element Communication Protocol (PCEP) [RFC5440] to handle network performance constraints made up of any combination of latency, delay variation, packet loss, and bandwidth utilization constraints 🌈

[RFC7471] and [RFC7810] describe various considerations regarding:

  • Announcement thresholds and filters
  • Announcement suppression
  • Announcement periodicity and network stability

The first two give configurable mechanisms to bound the number of re-advertisements in IGP. The third gives a way to throttle announcements 🫶 Section 1.2 of [RFC7823] also describes the oscillation and stability considerations while advertising and considering service-aware information 💜

1.1. Requirements Language 📜

Here's the key-word deal 🔥 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. Terminology 📖

The following terminology is used in this document 🦋

IGP:      Interior Gateway Protocol; either of the two routing
          protocols, Open Shortest Path First (OSPF) or Intermediate
          System to Intermediate System (IS-IS).

IS-IS:    Intermediate System to Intermediate System

LBU:      Link Bandwidth Utilization (see Section 3.2.1)

LRBU:     Link Reserved Bandwidth Utilization (see Section 3.2.2)

MPLP:     Minimum Packet Loss Path (see Section 3.3)

MRUP:     Maximum Reserved Under-Utilized Path (see Section 3.3)

MUP:      Maximum Under-Utilized Path (see Section 3.3)
OF:       Objective Function; a set of one or more optimization
          criteria used for the computation of a single path (e.g.,
          path cost minimization) or for the synchronized computation
          of a set of paths (e.g., aggregate bandwidth consumption
          minimization, etc.).  (See [RFC5541].)

OSPF:     Open Shortest Path First

PCC:      Path Computation Client; any client application requesting
          a path computation to be performed by a Path Computation
          Element.

PCE:      Path Computation Element; an entity (component,
          application, or network node) that is capable of computing
          a network path or route based on a network graph and
          applying computational constraints.

RSVP:     Resource Reservation Protocol

TE:       Traffic Engineering

TED:      Traffic Engineering Database

3. PCEP Extensions 🦋

This section defines PCEP extensions (see [RFC5440]) for the requirements outlined in Appendix A 💖 The proposed solution is used to support network performance and service-aware path computation ✨

3.1. Extensions to METRIC Object ✨

okay so the METRIC object is defined in Section 7.8 of [RFC5440] 🎀. It's got a metric-value, a metric-type (that's the T field), and a flags field with a couple of bit flags (the B bit and the P bit) 💅. This doc adds these types for the METRIC object:

  • T=12: Path Delay metric (Section 3.1.1)
  • T=13: Path Delay Variation metric (Section 3.1.2)
  • T=14: Path Loss metric (Section 3.1.3)
  • T=15: P2MP Path Delay metric (Section 3.1.6.1)
  • T=16: P2MP Path Delay Variation metric (Section 3.1.6.2)
  • T=17: P2MP Path Loss metric (Section 3.1.6.3)

Here's the vocab we're using, and we'll level it up as we go 🧚

  • A network comprises of a set of N links {Li, (i=1...N)}.
  • A path P of a point-to-point (P2P) LSP is a list of K links {Lpi,(i=1...K)}.

3.1.1. Path Delay Metric 🌸

The Link Delay metric is defined in [RFC7471] and [RFC7810] as "Unidirectional Link Delay" 🦋. The Path Delay metric type of the METRIC object in PCEP is the sum of the Link Delay metric of all links along a P2P path, so it's basically the total delay for the whole trip 🚗💨. Here's how it breaks down:

  • A Link Delay metric of link L is denoted D(L).
  • A Path Delay metric for the P2P path P is P = Sum {D(Lpi), (i=1...K)}.

This is as per the sum of means composition function (Section 4.2.5 of [RFC6049]). Section 1.2 of [RFC7823] covers oscillation and stability considerations, and Section 2.1 of [RFC7823] explains how the end-to-end Path Delay metric gets calculated. Also, Section 4.2.9 of [RFC6049] tells you when this composition function may fail 💀.

Metric Type T=12: Path Delay metric 💖

A PCC MAY use the Path Delay metric in a Path Computation Request (PCReq) message to request a path meeting the end-to-end latency requirement. In this case, the B bit MUST be set to suggest a bound (a maximum) for the Path Delay metric that must not be exceeded for the PCC to consider the computed path as acceptable. The Path Delay metric must be less than or equal to the value specified in the metric-value field.

A PCC can also use this metric to ask the PCE to optimize the path delay during path computation. In this case, the B bit MUST be cleared.

A PCE MAY use the Path Delay metric in a Path Computation Reply (PCRep) message along with a NO-PATH object in the case where the PCE cannot compute a path meeting this constraint. A PCE can also use this metric to send the computed Path Delay metric to the PCC.

3.1.1.1. Path Delay Metric Value 🔥

[RFC7471] and [RFC7810] define "Unidirectional Link Delay Sub-TLV" to advertise the link delay in microseconds in a 24-bit field. [RFC5440] defines the METRIC object with a 32-bit metric value encoded in IEEE floating point format (see [IEEE.754]). So, the encoding for the Path Delay metric value is quantified in microseconds and encoded in IEEE floating point format. Heads up though: the conversion from 24-bit integer to 32-bit IEEE floating point could introduce some loss of precision 🙈.

3.1.2. Path Delay Variation Metric 🌈

The Link Delay Variation metric is defined in [RFC7471] and [RFC7810] as "Unidirectional Delay Variation". The Path Delay Variation metric type of the METRIC object in PCEP encodes the sum of the Link Delay Variation metric of all links along the path. Here's the breakdown:

  • A delay variation of link L is denoted DV(L) (average delay variation for link L).
  • A Path Delay Variation metric for the P2P path P is P = Sum {DV(Lpi), (i=1...K)}.

Section 1.2 of [RFC7823] describes oscillation and stability considerations, and Section 2.1 of [RFC7823] describes the calculation of the end-to-end Path Delay Variation metric. Further, Section 4.2.9 of [RFC6049] states when this composition function may fail.

Note that the IGP advertisement for link attributes includes the average delay variation over a period of time. An implementation, therefore, MAY use the sum of the average delay variation of links along a path to derive the delay variation of the path. An end-to-end bound on delay variation is typically used as a constraint in the path computation. An implementation MAY also use some enhanced composition function for computing the delay variation of a path with better accuracy 🧠.

Metric Type T=13: Path Delay Variation metric 💜

A PCC MAY use the Path Delay Variation metric in a PCReq message to request a path meeting the path delay variation requirement. In this case, the B bit MUST be set to suggest a bound (a maximum) for the Path Delay Variation metric that must not be exceeded for the PCC to consider the computed path as acceptable. The path delay variation must be less than or equal to the value specified in the metric-value field.

A PCC can also use this metric to ask the PCE to optimize the path delay variation during path computation. In this case, the B flag MUST be cleared.

A PCE MAY use the Path Delay Variation metric in a PCRep message along with a NO-PATH object in the case where the PCE cannot compute a path meeting this constraint. A PCE can also use this metric to send the computed end-to-end Path Delay Variation metric to the PCC.

3.1.2.1. Path Delay Variation Metric Value ✨

[RFC7471] and [RFC7810] define "Unidirectional Delay Variation Sub-TLV" to advertise the link delay variation in microseconds in a 24-bit field. [RFC5440] defines the METRIC object with a 32-bit metric value encoded in IEEE floating point format (see [IEEE.754]). So the encoding for the Path Delay Variation metric value is quantified in microseconds and encoded in IEEE floating point format. Same tea as before: the conversion from 24-bit integer to 32-bit IEEE floating point could introduce some loss of precision 🫶.

3.1.3. Path Loss Metric 🍓

[RFC7471] and [RFC7810] define "Unidirectional Link Loss". The Path Loss (as a packet percentage) metric type of the METRIC object in PCEP encodes a function of the unidirectional loss metrics of all links along a P2P path. The end-to-end packet loss for the path is represented by this metric. Here's the math:

  • The percentage link loss of link L is denoted PL(L).
  • The fractional link loss of link L is denoted FL(L) = PL(L)/100.
  • The percentage Path Loss metric for the P2P path P is (1 - ((1-FL(Lp1)) * (1-FL(Lp2)) * .. * (1-FL(LpK)))) * 100 for a path P with links Lp1 to LpK.

This is as per the composition function described in Section 5.1.5 of [RFC6049].

Metric Type T=14: Path Loss metric 🦋

A PCC MAY use the Path Loss metric in a PCReq message to request a path meeting the end-to-end packet loss requirement. In this case, the B bit MUST be set to suggest a bound (a maximum) for the Path Loss metric that must not be exceeded for the PCC to consider the computed path as acceptable. The Path Loss metric must be less than or equal to the value specified in the metric-value field.

A PCC can also use this metric to ask the PCE to optimize the path loss during path computation. In this case, the B flag MUST be cleared.

A PCE MAY use the Path Loss metric in a PCRep message along with a NO-PATH object in the case where the PCE cannot compute a path meeting this constraint. A PCE can also use this metric to send the computed end-to-end Path Loss metric to the PCC.

3.1.3.1. Path Loss Metric Value 💅

[RFC7471] and [RFC7810] define "Unidirectional Link Loss Sub-TLV" to advertise the link loss in percentage in a 24-bit field. [RFC5440] defines the METRIC object with a 32-bit metric value encoded in IEEE floating point format (see [IEEE.754]). So the encoding for the Path Loss metric value is quantified as a percentage and encoded in IEEE floating point format.

3.1.4. Non-Understanding / Non-Support of Service-Aware Path Computation 🙅‍♀️

Okay, this part is about what happens when a PCE gets a METRIC object it doesn't fully get. Four scenarios, bestie 👑:

If a PCE receives a PCReq message containing a METRIC object with a type defined in this document, and the PCE does not understand or support that metric type, and the P bit is clear in the METRIC object header, then the PCE SHOULD simply ignore the METRIC object as per the processing specified in [RFC5440].

If the PCE does not understand the new METRIC type, and the P bit is set in the METRIC object header, then the PCE MUST send a PCEP Error (PCErr) message containing a PCEP-ERROR Object with Error-Type = 4 (Not supported object) and Error-value = 4 (Unsupported parameter) [RFC5440][RFC5441].

If the PCE understands but does not support the new METRIC type, and the P bit is set in the METRIC object header, then the PCE MUST send a PCErr message containing a PCEP-ERROR Object with Error-Type = 4 (Not supported object) with Error-value = 5 (Unsupported network performance constraint). The path computation request MUST then be canceled 🚫.

If the PCE understands the new METRIC type, but the local policy has been configured on the PCE to not allow network performance constraint, and the P bit is set in the METRIC object header, then the PCE MUST send a PCErr message containing a PCEP-ERROR Object with Error-Type = 5 (Policy violation) with Error-value = 8 (Not allowed network performance constraint). The path computation request MUST then be canceled 🛑.

3.1.5. Mode of Operation 🌟

As explained in [RFC5440], the METRIC object is optional and can be used for several purposes. In a PCReq message, a PCC MAY insert one or more METRIC objects:

  • To indicate the metric that MUST be optimized by the path computation algorithm (path delay, path delay variation, or path loss).
  • To indicate a bound on the METRIC (path delay, path delay variation, or path loss) that MUST NOT be exceeded for the path to be considered as acceptable by the PCC.

In a PCRep message, the PCE MAY insert the METRIC object with an Explicit Route Object (ERO) so as to provide the METRIC (path delay, path delay variation, or path loss) for the computed path. The PCE MAY also insert the METRIC object with a NO-PATH object to indicate that the metric constraint could not be satisfied.

The path computation algorithmic aspects used by the PCE to optimize a path with respect to a specific metric are outside the scope of this document 🧁.

All the rules of processing the METRIC object as explained in [RFC5440] are applicable to the new metric types as well.

3.1.5.1. Examples 🎀

Say a PCC sends a path computation request to a PCE where the metric to optimize is the path delay, and the path loss must not exceed the value of M. Then two METRIC objects get inserted in the PCReq message:

  • First METRIC object with B=0, T=12, C=1, metric-value=0x0000
  • Second METRIC object with B=1, T=14, metric-value=M

As per [RFC5440], if a path satisfying the set of constraints can be found by the PCE and there is no policy that prevents the return of the computed metric, then the PCE inserts one METRIC object with B=0, T=12, metric-value= computed path delay. Additionally, the PCE MAY insert a second METRIC object with B=1, T=14, metric-value= computed path loss 🥰.

3.1.6. Point-to-Multipoint (P2MP) 🦄

This section defines the following types for the METRIC object to be used for the P2MP TE LSPs ✨.

3.1.6.1. P2MP Path Delay Metric

okay so this one is giving "worst case wins" 😭🔥 The P2MP Path Delay metric type in the METRIC object reports the path delay for whichever destination in the P2MP tree has the worst delay out of all of them. bestie, the most delayed destination is the one that gets the spotlight 💅 Here's how it works:

  • A P2MP tree T has a set of M destinations {Dest_j, (j=1...M)}.
  • The P2P Path Delay metric of the path to destination Dest_j is PDM(Dest_j).
  • The P2MP Path Delay metric for the P2MP tree T is T = Maximum {PDM(Dest_j), (j=1...M)}.

The value for the P2MP Path Delay metric type (T) is 15 🎀

3.1.6.2. P2MP Path Delay Variation Metric

same energy, different metric 🦋 The P2MP Path Delay Variation metric type in the METRIC object reports the delay variation for the destination with the worst delay variation among every destination in the P2MP tree. it's the jitter main character of the tree, ngl 😭

  • A P2MP tree T has a set of M destinations {Dest_j, (j=1...M)}.
  • The P2P Path Delay Variation metric of the path to the destination Dest_j is PDVM(Dest_j).
  • The P2MP Path Delay Variation metric for the P2MP tree T is T = Maximum {PDVM(Dest_j), (j=1...M)}.

The value for the P2MP Path Delay Variation metric type (T) is 16 ✨

3.1.6.3. P2MP Path Loss Metric

and the last one 🌈 The P2MP Path Loss metric type in the METRIC object reports the packet loss for the destination with the worst packet loss among all destinations in the P2MP tree. the one losing the most packets gets reported, periodt 💀

  • A P2MP tree T is made up of a set of M destinations {Dest_j, (j=1...M)}.
  • The P2P Path Loss metric of the path to destination Dest_j is PLM(Dest_j).
  • The P2MP Path Loss metric for the P2MP tree T is T = Maximum {PLM(Dest_j), (j=1...M)}.

The value for the P2MP Path Loss metric type (T) is 17 🍓

3.2. Bandwidth Utilization

the LBU on a link, forwarding adjacency, or bundled link gets stored in the TED 🧚 It's carried in the "Unidirectional Utilized Bandwidth Sub-TLV" defined in [RFC7471] and [RFC7810]. For a link or forwarding adjacency, the bandwidth utilization is the actual utilization of the link, as measured in the router. For a bundled link, it's the sum of the bandwidth utilization of its component links. And this counts traffic from both RSVP-TE and non-RSVP-TE label switched path packets, so nothing gets left out 👑

The LBU as a percentage is:

(utilized bandwidth / maximum bandwidth) * 100

The "maximum bandwidth" is defined in [RFC3630] and [RFC5305], and the "utilized bandwidth" is defined in [RFC7471] and [RFC7810] 💜

the LRBU on a link, forwarding adjacency, or bundled link can be worked out from the TED 🦋 The utilized bandwidth covers traffic from both RSVP-TE and non-RSVP-TE LSPs, but the reserved bandwidth utilization only looks at the RSVP-TE LSPs. So the math goes like this: the reserved bandwidth utilization is found using the residual bandwidth, available bandwidth, and utilized bandwidth from [RFC7471] and [RFC7810]. First you subtract the available bandwidth from the residual bandwidth to get the bandwidth used by non-RSVP-TE traffic ([RFC7471] and [RFC7810]). Then you subtract that from the utilized bandwidth, and what's left is the reserved bandwidth utilization. Like this:

reserved bandwidth utilization = utilized bandwidth - (residual
bandwidth - available bandwidth)

The LRBU as a percentage is:

(reserved bandwidth utilization / maximum reservable bandwidth) * 100

The "maximum reservable bandwidth" is defined in [RFC3630] and [RFC5305]. The "utilized bandwidth", "residual bandwidth", and "available bandwidth" are defined in [RFC7471] and [RFC7810] 🌸

3.2.3. Bandwidth Utilization (BU) Object

the BU object is how you tell the PCE the upper limit for acceptable link bandwidth utilization, as a percentage 🎀

The BU object MAY be carried within the PCReq message and PCRep messages.

BU Object-Class is 35.

BU Object-Type is 1.

Here's the layout of the BU object body 📐

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Reserved                         |    Type       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Bandwidth Utilization                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        BU Object Body Format

The fields are:

  • Reserved (24 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt.
  • Type (8 bits): The bandwidth utilization type. Two values are defined right now.
    • Type 1 is LBU (Link Bandwidth Utilization).
    • Type 2 is LRBU (Link Residual Bandwidth Utilization).
  • Bandwidth Utilization (32 bits): The bandwidth utilization as a percentage (as described in Sections 3.2.1 and 3.2.2), encoded in IEEE floating point format (see [IEEE.754]).

The BU object body has a fixed length of 8 bytes 🧸

3.2.3.1. Elements of Procedure

here's how the BU object actually gets handled 🫶

A PCC that wants the PCE to take bandwidth utilization into account during path computation puts a BU object in the PCReq message. A PCE that supports this object MUST ensure that no link on the computed path has an LBU or LRBU percentage above the given value.

A PCReq or PCRep message MAY contain multiple BU objects, as long as each one is for a different bandwidth utilization type. If a message has more than one BU object with the same bandwidth utilization type, the first one MUST be processed by the receiver, and the later ones MUST be ignored 🙈

If the BU object is unknown or unsupported, the PCE is expected to follow the procedures in [RFC5440]. So if the P bit is set, the PCE sends a PCErr message with error type 3 or 4 (Unknown / Not supported object) and error value 1 or 2 (unknown / unsupported object class / object type), and the related path computation request gets discarded. If the P bit is cleared, the PCE is free to ignore the object 🌈

If the PCE understands the BU object but doesn't support path computation requests that use it, and the P bit is set in the BU object header, then the PCE MUST send a PCErr message with a PCEP-ERROR Object Error-Type = 4 (Not supported object) with Error-value = 5 (Unsupported network performance constraint), and the related path computation request MUST be discarded 💀

If the PCE understands the BU object, but its local policy is set to not allow network performance constraints, and the P bit is set in the BU object header, then the PCE MUST send a PCErr message with a PCEP-ERROR Object Error-Type = 5 (Policy violation) with Error-value = 8 (Not allowed network performance constraint). The path computation request MUST then be canceled 🚫

If path computation fails, a PCE MAY insert a BU object (along with a NO-PATH object) into a PCRep message to show which constraints couldn't be satisfied ✨

Using the BU object for P2MP LSPs is outside the scope of this document 🌸

3.3. Objective Functions

okay the objective function part is where the path math gets spicy 🔥 [RFC5541] defines how to specify an objective function that a PCE uses when it computes a path. The new metric types for path delay and path delay variation can keep using the existing objective function, Minimum Cost Path (MCP) [RFC5541]. For path loss, this document defines a new OF:

  • A network is made up of a set of N links {Li, (i=1...N)}.
  • A path P is a list of K links {Lpi,(i=1...K)}.
  • The percentage link loss of link L is denoted PL(L).
  • The fractional link loss of link L is denoted FL(L) = PL(L) / 100.
  • The percentage path loss of a path P is denoted PL(P), where:
PL(P) = (1 - ((1-FL(Lp1)) * (1-FL(Lp2)) * .. * (1-FL(LpK)))) * 100

Here's the new one for path loss 🦋

Objective Function Code:  9
Name: Minimum Packet Loss Path (MPLP)
Description: Find a path P such that PL(P) is minimized.

Two more objective functions, the Maximum Under-Utilized Path (MUP) and the Maximum Reserved Under-Utilized Path (MRUP), are needed to optimize bandwidth utilization. These two new objective function codes are defined below, using these extra terms:

  • The bandwidth utilization on link L is denoted u(L).
  • The reserved bandwidth utilization on link L is denoted ru(L).
  • The maximum bandwidth on link L is denoted M(L).
  • The maximum reservable bandwidth on link L is denoted R(L).

Here's how the two new objective functions are described 💅

Objective Function Code:  10
Name: Maximum Under-Utilized Path (MUP)
Description: Find a path P such that (Min {(M(Lpi)- u(Lpi))
/ M(Lpi), i=1...K } ) is maximized.
Objective Function Code:  11
Name: Maximum Reserved Under-Utilized Path (MRUP)
Description: Find a path P such that (Min {(R(Lpi)- ru(Lpi))
/ R(Lpi), i=1...K } ) is maximized.

These new objective functions optimize paths using bandwidth utilization as the criteria 🌈

If a PCE doesn't know or support the objective functions defined in this document, then the procedure in Section 3.1.1 of [RFC5541] gets followed 🧚

4. Stateful PCE and PCE Initiated LSPs ✨

[RFC8231] defines a set of PCEP extensions for stateful control of MPLS-TE and GMPLS LSPs through PCEP, and for keeping track of those LSPs at the stateful PCE. It also splits things into active and passive stateful PCEs. A passive stateful PCE uses the LSP state it learns from PCCs to improve path computations, but it doesn't actively change LSP state. An active stateful PCE, on the other hand, uses LSP delegation to update LSP parameters on the PCCs that handed control of their LSPs over to it 👑 [PCE-INITIATED] covers setting up, maintaining, and tearing down PCE-initiated LSPs under the stateful PCE model, and defines the PCInitiate message a PCE uses to ask a PCC to set up a new LSP 🫶

The new metric type and objective functions in this document can also be used with the stateful PCE extensions. PCEP messages described in [RFC8231] and [PCE-INITIATED] use <intended-attribute-list> and <attribute-list>, respectively, to carry the service-aware parameters. The <intended-attribute-list> is the attribute-list defined in Section 6.5 of [RFC5440] and extended in Section 5.2 of this document 💖

A stateful PCE implementation MAY use the PCReq and PCRep message extensions defined in Sections 5.1 and 5.2 to enable service-aware parameters during passive stateful operations 🦋

5. PCEP Message Extension 🌸

the message formats in this document are written in Routing Backus-Naur Form (RBNF), the same way [RFC5440] does it, and as defined in [RFC5511] 🎀

5.1. The PCReq Message 💖

okay so the PCReq message is getting a glow-up ✨ it picks up three things:

  • new metric types, using the existing METRIC object
  • a new optional BU object 🦋
  • new objective functions, using the existing OF object [RFC5541]

Here's how the PCReq message is laid out now, building on [RFC5541] and [RFC8231] 👑

      <PCReq Message> ::= <Common Header>
                           [<svec-list>]
                           <request-list>
      where:
           <svec-list> ::= <SVEC>
                           [<OF>]
                           [<metric-list>]
                           [<svec-list>]

           <request-list> ::= <request> [<request-list>]

           <request> ::= <RP>
                         <END-POINTS>
                         [<LSP>]
                         [<LSPA>]
                         [<BANDWIDTH>]
                         [<bu-list>]
                         [<metric-list>]
                         [<OF>]
                         [<RRO>[<BANDWIDTH>]]
                         [<IRO>]
                         [<LOAD-BALANCING>]

      and where:
           <bu-list>::=<BU>[<bu-list>]
           <metric-list> ::= <METRIC>[<metric-list>]

5.2. The PCRep Message 🎀

the PCRep message gets the same three upgrades: new metric types on the existing METRIC object, a new optional BU object, and new objective functions on the existing OF object [RFC5541]. The BU object here is for the moment when a path computation fails, since it can show the bandwidth utilization as the reason why 🙈

The layout (again building on [RFC5541] and [RFC8231]) looks like this:

      <PCRep Message> ::= <Common Header>
                          [<svec-list>]
                          <response-list>

      where:

            <svec-list> ::= <SVEC>
                            [<OF>]
                            [<metric-list>]
                            [<svec-list>]

           <response-list> ::= <response> [<response-list>]

           <response> ::= <RP>
                          [<LSP>]
                          [<NO-PATH>]
                          [<attribute-list>]
                          [<path-list>]

           <path-list> ::= <path> [<path-list>]

           <path> ::= <ERO>
                      <attribute-list>

      and where:

           <attribute-list> ::= [<OF>]
                                [<LSPA>]
                                [<BANDWIDTH>]
                                [<bu-list>]
                                [<metric-list>]
                                [<IRO>]

           <bu-list>::=<BU>[<bu-list>]
           <metric-list> ::= <METRIC> [<metric-list>]

5.3. The PCRpt Message 🌈

so the PCRpt message is the one a PCC sends to a PCE to report an LSP's current state or to hand over control of it (it's also called the Path Computation LSP State Report message). In a PCRpt, the BU object shows the upper limit the PCC had set at the moment the LSP got delegated to an active stateful PCE. Iconic behaviour 💅

The format of the PCRpt message is described in [RFC8231]. It uses the <intended-attribute-list>, which is the attribute-list defined in Section 6.5 of [RFC5440] and extended by PCEP extensions.

The PCRpt message can use the updated <attribute-list> (as extended in Section 5.2) so it can include the BU object ✨

6. Other Considerations 🫶

6.1. Inter-domain Path Computation 🌍

[RFC5441] describes the Backward Recursive PCE-Based Computation (BRPC) procedure. It's how cooperating PCEs work out an end-to-end optimised inter-domain path together, and it's giving teamwork 🤝

The new metric types from this document can be used for end-to-end path computation, kind of like the existing IGP or TE metrics. The new BU object can be used there too, in a similar way to a METRIC object with its B bit set to 1 🦋

All domains should have the same understanding of the METRIC (path delay variation, etc.) and the BU object for end-to-end inter-domain path computation to make sense. Otherwise, some form of metric normalization as described in [RFC5441] MUST be applied. Like, this part is non-negotiable bestie 😭

the IGP in each neighbour domain can advertise its inter-domain TE link capabilities. That's covered in [RFC5316] for IS-IS and [RFC5392] for OSPF. The network performance link properties are described in [RFC7471] and [RFC7810]. The same properties must be advertised using the mechanism described in [RFC5392] (OSPF) and [RFC5316] (IS-IS) 🌸

6.1.2. Inter-Layer Path Computation

[RFC5623] gives us a framework for PCE-based inter-layer MPLS and GMPLS traffic engineering. Lower-layer LSPs that get advertised as TE links into the higher-layer network form a Virtual Network Topology (VNT) 🧚

The advertisement into the higher-layer network should include network performance link properties based on the end-to-end metric of the lower-layer LSP. Also, the new metrics here apply to end-to-end path computation even when the path crosses multiple layers. Layers are not the vibe-killer here 💜

6.2. Reoptimizing Paths 🔁

[RFC6374] defines how loss, delay, and related metrics get measured over LSPs, and a PCC can use those measurement techniques. If it spots a degradation in network performance compared to the constraint it gave when the path was set up, or compared to an implementation-specific threshold, it MAY ask the PCE to reoptimize the path. It does that by sending a PCReq with the R bit set in the RP object, as per [RFC5440] 💅

A PCC can also notice degradation without measuring anything itself. It just watches the TED (the one the IGP fills in) for changes in the network performance parameters of the links carrying its LSPs. Then it can issue a reoptimization request for any impacted LSPs 👀

For example, a PCC can keep an eye on link bandwidth utilization along its path by watching changes in the bandwidth utilization parameters of one or more links on that path in the TED. If the bandwidth utilization percentage of any link in the path drops to a value less than the one required when the path was set up, or less than an implementation-specific threshold, then the PCC can send a reoptimization request to a PCE 🙌

A stateful PCE can also figure out which LSPs should be reoptimized, based on network events or triggers from external monitoring systems. For instance, when a particular link deteriorates and its loss increases, that can trigger the stateful PCE to automatically work out which LSPs are impacted and should be reoptimized 🍓

7. IANA Considerations 📋

7.1. METRIC Types 🔢

IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" registry at <http://www.iana.org/assignments/pcep>. Inside that registry, IANA keeps a subregistry for "METRIC Object T Field". Six new metric types are defined in this document for the METRIC object (specified in [RFC5440]) ✨

IANA has made the following allocations:

     Value       Description                        Reference
     ----------------------------------------------------------
     12          Path Delay metric                  RFC 8233
     13          Path Delay Variation metric        RFC 8233
     14          Path Loss metric                   RFC 8233
     15          P2MP Path Delay metric             RFC 8233
     16          P2MP Path Delay variation metric   RFC 8233
     17          P2MP Path Loss metric              RFC 8233

7.2. New PCEP Object 🧩

IANA maintains the Object-Types inside the "PCEP Objects" registry. IANA has made the following allocation:

      Object    Object     Name                  Reference
      Class     Type
      ------------------------------------------------------
      35        0          Reserved              RFC 8233
                1          BU                    RFC 8233

7.3. BU Object 🦋

IANA has created a new subregistry, named "BU Object Type Field", inside the "Path Computation Element Protocol (PCEP) Numbers" registry. It manages the Type field of the BU object. New values are to be assigned by Standards Action [RFC8126]. Each value should be tracked with the following qualities:

  • Type
  • Name
  • Reference

The following values are defined in this document:

   Type    Name                                        Reference
   ---------------------------------------------------------------
   0       Reserved                                    RFC 8233

   1       LBU (Link Bandwidth Utilization)            RFC 8233

   2       LRBU (Link Residual Bandwidth Utilization)  RFC 8233

7.4. OF Codes 🎯

IANA maintains the "Objective Function" subregistry (described in [RFC5541]) within the "Path Computation Element Protocol (PCEP) Numbers" registry. Three new objective functions have been defined in this document. IANA has made the following allocations:

 Code     Name                                         Reference
 Point
 -----------------------------------------------------------------
 9        Minimum Packet Loss Path (MPLP)              RFC 8233

 10       Maximum Under-Utilized Path (MUP)            RFC 8233

 11       Maximum Reserved Under-Utilized Path (MRUP)  RFC 8233

7.5. New Error-Values 🚨

IANA keeps a registry of Error-Types and Error-values for use in PCEP messages. It's maintained as the "PCEP-ERROR Object Error Types and Values" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry.

Two new Error-values are defined here, for the Error-Type "Not supported object" (type 4) and "Policy violation" (type 5). IANA has made the following allocations:

    Error-Type     Meaning and error values           Reference
    -------------------------------------------------------------
       4           Not supported object

                   Error-value
                   5: Unsupported network             RFC 8233
                   performance constraint

       5           Policy violation

                   Error-value
                   8: Not allowed network             RFC 8233
                   performance constraint

8. Security Considerations 🔐

this part is serious, bestie 😭 This document defines new METRIC types, a new BU object, and new OF codes. In itself, they do not add any new security concerns beyond the ones already discussed in [RFC5440] and [RFC5541]. But some deployments may find service-aware information like delay and packet loss extra sensitive, and it could be used to influence path computation and setup in an adverse way. On top of that, snooping on PCEP messages carrying that data, or using PCEP messages for network reconnaissance, may give an attacker sensitive information about how the network operates 👀

So, such deployments should employ suitable PCEP security mechanisms, like TCP Authentication Option (TCP-AO) [RFC5925] or [PCEPS]. The procedure based on Transport Layer Security (TLS) in [PCEPS] is considered a security enhancement, which makes it much better suited for sensitive service-aware information. Protect your data like it's your main character era 🛡️💖

9. Manageability Considerations 🛠️

9.1. Control of Function and Policy 🎛️

The only configurable item is the support of the new constraints on a PCE. That support MAY be controlled by a policy module on an individual basis. If the new constraint is not supported or allowed on a PCE, it MUST send a PCErr message accordingly 🙅‍♀️

9.2. Information and Data Models 📚

[RFC7420] describes the PCEP MIB. There are no new MIB Objects for this document 🌷

9.3. Liveness Detection and Monitoring ✨

okay so, the stuff in this doc doesn't add any new liveness detection or monitoring requirements on top of what [RFC5440] already lists 💖

9.4. Verify Correct Operations 🔍

same vibe here, bestie: no new operation verification requirements beyond the ones already in [RFC5440] 🫶

9.5. Requirements on Other Protocols 🌈

the PCE needs its TED (traffic engineering database) to be stuffed with network performance info, like link latency, delay variation, packet loss, and utilized bandwidth 📊 the way that gets done is described in [RFC7471] and [RFC7810] 🦋

9.6. Impact on Network Operations 🌸

the mechanisms here don't have any impact on network operations beyond what's already listed in [RFC5440]. nothing sneaky going on 💅

10. References 📚

10.1. Normative References 🎀

ngl these are the must-reads, so here they are, copied exactly:

[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>.

[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>.

[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>.

[RFC5511]  Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
           Used to Form Encoding Rules in Various Routing Protocol
           Specifications", RFC 5511, DOI 10.17487/RFC5511, April
           2009, <https://www.rfc-editor.org/info/rfc5511>.

[RFC5541]  Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
           Objective Functions in the Path Computation Element
           Communication Protocol (PCEP)", RFC 5541,
           DOI 10.17487/RFC5541, June 2009,
           <https://www.rfc-editor.org/info/rfc5541>.

[RFC7471]  Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
           Previdi, "OSPF Traffic Engineering (TE) Metric
           Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
           <https://www.rfc-editor.org/info/rfc7471>.

[RFC7810]  Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and
           Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions",
           RFC 7810, DOI 10.17487/RFC7810, May 2016,
           <https://www.rfc-editor.org/info/rfc7810>.

[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,
           <http://www.rfc-editor.org/info/rfc8231>.

10.2. Informative References 🧚

and these are the extra-credit reads 💜

[IEEE.754]
           IEEE, "Standard for Binary Floating-Point Arithmetic",
           IEEE Standard 754-2008, DOI 10.1109/IEEESTD.2008.4610935,
           August 2008.

[PCE-INITIATED]
           Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
           Extensions for PCE-initiated LSP Setup in a Stateful PCE
           Model", Work in Progress,
           draft-ietf-pce-pce-initiated-lsp-10, June 2017.

[PCEPS]    Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure
           Transport for PCEP", Work in Progress,
           draft-ietf-pce-pceps-16, September 2017.

[RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
           Element (PCE)-Based Architecture", RFC 4655,
           DOI 10.17487/RFC4655, August 2006,
           <https://www.rfc-editor.org/info/rfc4655>.

[RFC5316]  Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
           Support of Inter-Autonomous System (AS) MPLS and GMPLS
           Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316,
           December 2008, <https://www.rfc-editor.org/info/rfc5316>.

[RFC5392]  Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in
           Support of Inter-Autonomous System (AS) MPLS and GMPLS
           Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392,
           January 2009, <https://www.rfc-editor.org/info/rfc5392>.

[RFC5441]  Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
           "A Backward-Recursive PCE-Based Computation (BRPC)
           Procedure to Compute Shortest Constrained Inter-Domain
           Traffic Engineering Label Switched Paths", RFC 5441,
           DOI 10.17487/RFC5441, April 2009,
           <https://www.rfc-editor.org/info/rfc5441>.

[RFC5623]  Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
           "Framework for PCE-Based Inter-Layer MPLS and GMPLS
           Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623,
           September 2009, <https://www.rfc-editor.org/info/rfc5623>.

[RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
           Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
           June 2010, <https://www.rfc-editor.org/info/rfc5925>.

[RFC6049]  Morton, A. and E. Stephan, "Spatial Composition of
           Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011,
           <https://www.rfc-editor.org/info/rfc6049>.

[RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
           Measurement for MPLS Networks", RFC 6374,
           DOI 10.17487/RFC6374, September 2011,
           <https://www.rfc-editor.org/info/rfc6374>.

[RFC7420]  Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
           Hardwick, "Path Computation Element Communication Protocol
           (PCEP) Management Information Base (MIB) Module",
           RFC 7420, DOI 10.17487/RFC7420, December 2014,
           <https://www.rfc-editor.org/info/rfc7420>.

[RFC7823]  Atlas, A., Drake, J., Giacalone, S., and S. Previdi,
           "Performance-Based Path Selection for Explicitly Routed
           Label Switched Paths (LSPs) Using TE Metric Extensions",
           RFC 7823, DOI 10.17487/RFC7823, May 2016,
           <https://www.rfc-editor.org/info/rfc7823>.

[RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
           Writing an IANA Considerations Section in RFCs", BCP 26,
           RFC 8126, DOI 10.17487/RFC8126, June 2017,
           <https://www.rfc-editor.org/info/rfc8126>.

Appendix A. PCEP Requirements 🎀

so this appendix is basically the PCEP wishlist for service providers, and they're all about end-to-end service optimization based on latency, delay variation, packet loss, and link bandwidth utilization 💅 the key requirements are:

  1. A PCE supporting this specification MUST have the capability to compute end-to-end paths with latency, delay variation, packet loss, and bandwidth utilization constraints. It MUST also support the combination of network performance constraints (latency, delay variation, loss,...) with existing constraints (cost, hop-limit,...).
  2. A PCC MUST be able to specify any network performance constraint in a PCReq message to be applied during the path computation.
  3. A PCC MUST be able to request that a PCE optimizes a path using any network performance criteria.
  4. A PCE that supports this specification is not required to provide service-aware path computation to any PCC at any time.

Therefore, it MUST be possible for a PCE to reject a PCReq message with a reason code that indicates service-aware path computation is not supported. Furthermore, a PCE that does not support this specification will either ignore or reject such requests using pre-existing mechanisms; therefore, the requests MUST be identifiable to legacy PCEs, and rejections by legacy PCEs MUST be acceptable within this specification. 🙈

  1. A PCE SHOULD be able to return end-to-end network performance information of the computed path in a PCRep message.
  2. A PCE SHOULD be able to compute multi-domain (e.g., Inter-AS, Inter-Area, or Multi-Layer) service-aware paths.

Such constraints are only meaningful if used consistently. For instance, if the delay of a computed path segment is exchanged between two PCEs residing in different domains, a consistent way of defining the delay must be used. It's giving "same definitions or it's chaos" energy 💀

Acknowledgments 🫶

we owe a big thank-you to Alia Atlas, John E. Drake, David Ward, Young Lee, Venugopal Reddy, Reeja Paul, Sandeep Kumar Boina, Suresh Babu, Quintin Zhao, Chen Huaimo, Avantika, and Adrian Farrel for their useful comments and suggestions 🌷

the authors also gratefully acknowledge the reviews and feedback from Qin Wu, Alfred Morton, and Paul Aitken during the performance directorate review 🍓

a huge thanks to Jonathan Hardwick for shepherding this document and giving valuable comments 👑 his help with the editorial and grammatical issues is also appreciated 💖

thanks to Christian Hopps for the routing directorate review 🦋

thanks to Jouni Korhonen and Alfred Morton for the operational directorate review ✨

thanks to Christian Huitema for the security directorate review 🔥

thanks to Deborah Brungard for being the responsible AD 🎀

and thanks to Ben Campbell, Joel Jaeggli, Stephen Farrell, Kathleen Moriarty, Spencer Dawkins, Mirja Kuehlewind, Jari Arkko, and Alia Atlas for the IESG reviews 🌈

Contributors 🌸

the contributors, exactly as listed:

Clarence Filsfils
Cisco Systems
Email: cfilsfil@cisco.com

Siva Sivabalan
Cisco Systems
Email: msiva@cisco.com

George Swallow
Cisco Systems
Email: swallow@cisco.com

Stefano Previdi
Cisco Systems, Inc
Via Del Serafico 200
Rome  00191
Italy
Email: sprevidi@cisco.com

Udayasree Palle
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka  560066
India
Email: udayasree.palle@huawei.com

Avantika
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka  560066
India
Email: avantika.sushilkumar@huawei.com

Xian Zhang
Huawei Technologies
F3-1-B R&D Center, Huawei Base Bantian, Longgang District
Shenzhen, Guangdong  518129
China
Email: zhang.xian@huawei.com

Authors' Addresses 🦋

and last but not least, the authors' addresses 💜

Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka  560066
India

Email: dhruv.ietf@gmail.com


Qin Wu
Huawei Technologies
101 Software Avenue, Yuhua District
Nanjing, Jiangsu  210012
China

Email: bill.wu@huawei.com


Vishwas Manral
Nano Sec Co
3350 Thomas Rd.
Santa Clara, CA
United States of America

Email: vishwas@nanosec.io


Zafar Ali
Cisco Systems

Email: zali@cisco.com


Kenji Kumaki
KDDI Corporation

Email: ke-kumaki@kddi.com

That's the whole thing, bestie! 🌈✨ 💅

📦 where this page comes from