RFC 9294

Application-Specific Link Attributes Advertisement Using the Border Gateway Protocol - Link State (BGP-LS)

📅 published August 2022, from ietf

Okay bestie, let's get into RFC 9294! 🦋 Quick tour of the title block first, because it tells us SO much 💅

Document number: RFC 9294. It's a Standards Track doc, which means it's the real deal, not just a suggestion 👑

Authors: K. Talaulikar (editor 🖊️) from Arrcus Inc., P. Psenak from Cisco Systems, and J. Tantsura from Microsoft. Girlies from three different networking companies all came together for this one 🫶

Date: August 2022 🌸

Obsoletes / Updates: the header doesn't mark this one as obsoleting or updating anything, so it's a brand-new spec 🎀

ISSN: 2070-1721 📚

Abstract

okay so the whole point of this doc is that link-state routing protocols already have these super useful application-specific link attributes (stuff like the link info that Segment Routing 🧚 needs), and now BGP-LS can carry all that info too. 💜 It's giving "let's share the whole topology, no secrets" 🙈

Status of This Memo

this is an Internet Standards Track document ✨ it's a product of the IETF, it has the community's consensus, got public review, and the IESG approved it for publication. 🌈 more info on Internet Standards lives in Section 2 of RFC 7841, and the current status, errata, and feedback info is at https://www.rfc-editor.org/info/rfc9294 💅

copyright (c) 2022 IETF Trust and the document authors, all rights reserved 🔥 this doc is under BCP 78 and the IETF Trust's Legal Provisions (https://trustee.ietf.org/license-info). if you pull code out of it, it needs the Revised BSD License text from Section 4.e of the Trust Legal Provisions, and it comes with no warranty 🫶 read the legal stuff, it's important, bestie 💀

Table of Contents

  • 1. Introduction 🦋
    • 1.1. Requirements Language ✨
  • 2. Application-Specific Link Attributes TLV 💖
  • 3. Application-Specific Link Attributes 🌸
  • 4. Procedures 🎀
    • 4.1. Illustration for IS-IS 🧚
  • 5. Deployment Considerations 🌈
  • 6. IANA Considerations 📚
  • 7. Manageability Considerations 🍓
  • 8. Security Considerations 🔥
  • 9. References 💜
    • 9.1. Normative References
    • 9.2. Informative References
  • Acknowledgements 🫶
  • Authors' Addresses 💌

1. Introduction 🦋

okay so BGP-LS [RFC7752] is how link-state topology info gets shared from link-state routing protocols (that's IS-IS [RFC1195], OSPFv2 [RFC2328], and OSPFv3 [RFC5340]) over to an app like a controller or a Path Computation Engine (PCE) 🧚 through BGP. The controller or PCE gets the end-to-end topology across IGP domains, so it can do path computations for things like end-to-end traffic engineering (TE) 💅

the link-state topology info that BGP-LS shares already includes link attributes that were first defined for MPLS TE, meaning the ones used by RSVP-TE [RFC3209] or GMPLS [RFC4202] 🌸 but lately, newer apps showed up that also use link attributes, like Segment Routing (SR) Policy [RFC8402] and Loop-Free Alternates (LFA) [RFC5286] ✨ [RFC8919] and [RFC8920] extend IS-IS and OSPF (respectively) so they can advertise application-specific link attributes for these apps and future ones too 🎀 so now BGP-LS needs a matching extension to carry this extra link-state info as well 🙈

this document is the BGP-LS extension for advertising those application-specific link attributes 💖 the attributes can show up as top-level TLVs (i.e., TLVs of the BGP-LS Attribute) or as sub-TLVs of the top-level Application-Specific Link Attributes (ASLA) TLV 🦋 it also covers how these attributes get advertised from the underlying IGPs and talks about deployment stuff 🌈

1.1. Requirements Language

okay bestie, this is the important bit for keywords 🔥 the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read as described in BCP 14 [RFC2119] [RFC8174], but ONLY when they're written in all capitals, just like here 💅 no capitals means no special meaning, periodt ✨

so BGP-LS [RFC7752] has the Link Network Layer Reachability Information (NLRI) for advertising links and their attributes using the BGP-LS Attribute 🦋 the ASLA TLV is an OPTIONAL top-level BGP-LS Attribute TLV that gets introduced for Link NLRIs 🌸 it's built so it can act as a container for certain existing and future link attributes that need an application-specific definition ✨ it's giving "one box to hold all the app stuff" 🎁

the format is below. it's similar to the matching ASLA sub-TLVs for OSPF and IS-IS in [RFC8920] and [RFC8919] respectively 💜

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | SABM Length   | UDABM Length  |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Standard Application Identifier Bit Mask (variable)      //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    User-Defined Application Identifier Bit Mask (variable)   //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Link Attribute sub-TLVs                 //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 1: Application-Specific Link Attributes TLV

where:

  • Type: 1122 🎀
  • Length: variable 💅
  • SABM Length: a 1-octet field that carries the Standard Application Identifier Bit Mask Length in octets, as defined in [RFC8920] 🌸
  • UDABM Length: a 1-octet field that carries the User-Defined Application Identifier Bit Mask Length in octets, as defined in [RFC8920] ✨
  • Reserved: a 2-octet field that MUST be set to zero on transmission and MUST be ignored on reception 🙈 no wiggle room here, bestie
  • Standard Application Identifier Bit Mask: an OPTIONAL set of bits (size 0, 4, or 8 octets, as indicated by the SABM Length), where each bit stands for one standard application as defined in [RFC8919] 🦋
  • User-Defined Application Identifier Bit Mask: an OPTIONAL set of bits (size 0, 4, or 8 octets, as indicated by the UDABM Length), where each bit stands for one user-defined application as defined in [RFC8919] and [RFC8920] 💖
  • Link Attribute sub-TLVs: the BGP-LS Attribute TLVs that correspond to the Link NLRI and are application-specific (including the existing ones specified in Section 3) get included as sub-TLVs of the ASLA TLV 🧚

the semantics for the standard and user-defined bit masks, plus the encoding scheme for application-specific attributes, are as specified in [RFC8920] 💜

the ASLA TLV and its sub-TLVs can ONLY be added to the BGP-LS Attribute associated with the Link NLRI of the node that originates the underlying IGP link attribute TLVs and sub-TLVs 🔥 the procedures for originating link attributes in the ASLA TLV from the underlying IGPs are specified in Section 4 ✨

To be continued in Part 2 💜 don't you dare log off, bestie 🫶

okay so bestie, this section is where things get spicy 🌶️ because it's all about the BGP-LS Attribute TLVs that describe links and can have application-specific vibes. several of these are already defined in BGP-LS [RFC7752], and more can show up later 🦋. the rule is that anything the underlying IGPs have flagged as application-specific also gets encoded similarly in BGP-LS. it's giving consistency 🎀

here's the table of the currently defined BGP-LS Attribute TLVs for Link NLRI that can carry application-specific semantics, based on the IGP specs in [RFC8919] and [RFC8920]. these were originally given RSVP-TE and GMPLS semantics in BGP-LS by their own reference docs, so they've been around the block 👑

+================+========================+====================+
| TLV Code Point | Description            | Reference Document |
+================+========================+====================+
|      1088      | Administrative group   | [RFC7752]          |
|                | (color)                |                    |
+----------------+------------------------+--------------------+
|      1092      | TE Default Metric      | [RFC7752]          |
+----------------+------------------------+--------------------+
|      1096      | Shared Risk Link Group | [RFC7752]          |
+----------------+------------------------+--------------------+
|      1114      | Unidirectional Link    | [RFC8571]          |
|                | Delay                  |                    |
+----------------+------------------------+--------------------+
|      1115      | Min/Max Unidirectional | [RFC8571]          |
|                | Link Delay             |                    |
+----------------+------------------------+--------------------+
|      1116      | Unidirectional Delay   | [RFC8571]          |
|                | Variation              |                    |
+----------------+------------------------+--------------------+
|      1117      | Unidirectional Link    | [RFC8571]          |
|                | Loss                   |                    |
+----------------+------------------------+--------------------+
|      1118      | Unidirectional         | [RFC8571]          |
|                | Residual Bandwidth     |                    |
+----------------+------------------------+--------------------+
|      1119      | Unidirectional         | [RFC8571]          |
|                | Available Bandwidth    |                    |
+----------------+------------------------+--------------------+
|      1120      | Unidirectional         | [RFC8571]          |
|                | Utilized Bandwidth     |                    |
+----------------+------------------------+--------------------+
|      1173      | Extended               | [RFC9104]          |
|                | Administrative Group   |                    |
+----------------+------------------------+--------------------+

Table 1: Existing BGP-LS TLVs Identified as Application-Specific

now the strict stuff 🙈 all the BGP-LS Attribute TLVs in that table MUST be advertised as a top-level TLV in the BGP-LS Attribute when they're carrying link attributes specific to RSVP-TE. 💖

and any BGP-LS Attribute TLVs for Link NLRI that the underlying IGP advertises as application-specific MUST be encoded inside an ASLA TLV. 🧚

link attributes with no application-specific semantics MUST NOT go in the ASLA TLV. not even a little bit 🚫💀

last one in this bit: if the same application-specific link attributes show up both inside the ASLA TLV and as top-level TLVs in the BGP-LS Attribute, the ASLA one wins 👑 for whichever applications are listed in that ASLA TLV encoding. it's giving priority 🫶

4. Procedures 🎀

okay the procedures are where the real chaos lives, so buckle up 😭

the BGP-LS originator figures out which applications an application-specific attribute belongs to by reading the underlying IGP's Link State Advertisements (LSAs) or Link State Packets (LSPs) that it's using for topology info. [RFC8920] and [RFC8919] are the ones that explain how OSPF and IS-IS advertise these attributes, respectively. 🔍✨

if application-specific link attributes come from an IGP node without using ASLA encodings, they CONTINUE to be encoded with the matching top-level BGP-LS TLVs from Table 1, as their own reference documents say. 🌸

okay now here's the twist 🌀: ASLA in OSPF is pretty similar to BGP-LS, but in IS-IS it's a whole different vibe 🙃 there's an L-flag to deal with, and the IS-IS side also has to collate info from two kinds of encodings (the IS-IS ASLA sub-TLV and the IS-IS Application-Specific Shared Risk Link Group (SRLG) TLV) and then carry them together in the BGP-LS ASLA TLV. it's a lot, bestie, but we got this 💪

a BGP-LS originator that's advertising link-state info using ASLA encodings picks its BGP-LS encoding using these rules:

  1. application-specific link attributes from an OSPF node using an ASLA sub-TLV, or from an IS-IS node using an ASLA sub-TLV or an Application-Specific SRLG TLV, MUST be encoded in the BGP-LS ASLA TLV as sub-TLVs. the exceptions are in (2)(F) and (2)(G) below. 💅
  2. for IS-IS, follow these procedures:

A. when application-specific link attributes come from a node with the L-flag set in the IS-IS ASLA sub-TLV, and application bits (other than RSVP-TE) are set in the application bit masks, then those attributes from the matching legacy IS-IS TLVs and sub-TLVs MUST be encoded inside the BGP-LS ASLA TLV as sub-TLVs, with the application bits (other than the RSVP-TE bit) copied over from the IS-IS ASLA sub-TLV. the legacy IS-IS link attributes also get advertised in BGP-LS top-level TLVs per [RFC7752], [RFC8571], and [RFC9104]. same deal for SRLG values from the IS-IS Application-Specific SRLG TLV 🔁

B. when the IS-IS ASLA sub-TLV has the RSVP-TE application bit set, the link attributes from those IS-IS ASLA sub-TLVs MUST be encoded with the matching BGP-LS top-level TLVs per [RFC7752], [RFC8571], and [RFC9104]. and when the IS-IS Application-Specific SRLG TLV has the RSVP-TE bit set, its SRLG values MUST go in the top-level BGP-LS SRLG TLV (1096) per [RFC7752]. ✨

C. SRLGs from one or more IS-IS Application-Specific SRLG TLVs and other link attributes from one or more IS-IS ASLA sub-TLVs REQUIRE collating on a per-application basis, but only for applications that meet all of these:

  • their bit is set in the SABM or UDABM in one of the two IS-IS encoding types (for example, the IS-IS ASLA sub-TLV)
  • the other encoding type (for example, the IS-IS Application Specific SRLG TLV) has an advertisement with zero-length application bit masks
  • there's no matching advertisement of that other encoding type (following the example, the IS-IS Application Specific SRLG TLV) with that specific application bit set

for each of those applications, the collated info MUST go in a BGP-LS ASLA TLV with that application's bit set in the SABM or UDABM. check out the illustration in Section 4.1 🎨

D. if the collated link attributes and SRLG values come out the same across multiple applications, they MAY be advertised in one shared BGP-LS ASLA TLV instance, with the bits for all those applications set in the application bit mask. 🫧

E. both the SRLG values from IS-IS Application-Specific SRLG TLVs and the link attributes from IS-IS ASLA sub-TLVs with a zero-length application bit mask MUST be advertised into a BGP-LS ASLA TLV with a zero-length application bit mask, no matter what the collation above says. 🙌

F. [RFC8919] lets the Maximum Link Bandwidth show up inside an IS-IS ASLA sub-TLV, even though it isn't application-specific. but when it goes into BGP-LS, it MUST be encoded only in the top-level BGP-LS Maximum Link Bandwidth TLV (1089) and MUST NOT appear in the BGP-LS ASLA TLV. 🚫

G. [RFC8919] also lets the Maximum Reservable Link Bandwidth and the Unreserved Bandwidth show up inside an IS-IS ASLA sub-TLV, even though they're specific to RSVP-TE. when they go into BGP-LS, they MUST be encoded only in the top-level BGP-LS Maximum Reservable Link Bandwidth TLV (1090) and Unreserved Bandwidth TLV (1091) respectively, and not inside the BGP-LS ASLA TLV. 🎀

these rules make sure the BGP-LS originator advertises all the application-specific link attributes coming from IGP nodes that support the ASLA extension 🌈. they also make sure the top-level BGP-LS TLVs defined for RSVP-TE and GMPLS keep getting used for their own application-specific attributes 💜.

a BGP-LS speaker would normally advertise all the application-specific link attributes for RSVP-TE and GMPLS as those existing top-level BGP-LS TLVs, while attributes for other applications go into the ASLA TLV(s) with the right applicable bit mask setting. 🦋 and an application-specific attribute value received through a sub-TLV inside the ASLA TLV takes precedence over the value received through a top-level TLV. 👑

4.1. Illustration for IS-IS 🦋

okay so this section is a little walkthrough of how application-specific link attributes get advertised from IS-IS into BGP-LS. bestie, this is the good part 💅

Consider the following advertisements for a link in IS-IS. We start with this set:

  • (a) IS-IS ASLA sub-TLV with the S, F, and X bits set on it that carries certain application-specific link attributes
  • (b) IS-IS Application-Specific SRLG TLV with zero-length bit masks with a set of application-specific SRLGs
  • (c) IS-IS Application-Specific SRLG TLV with the X bit set on it with a set of application-specific SRLGs

The corresponding BGP-LS advertisements for that link are determined as follows. First, based on rule (1), the advertisements get conveyed to BGP-LS, and we end up with this "updated set" ✨

  1. ASLA with the S, F, and X bits set on it that carries link attributes from IS-IS advertisement (a)
  2. ASLA SRLG with zero-length bit masks with a set of SRLGs from IS-IS advertisement (b)
  3. ASLA SRLG with the X bit set on it with a set of SRLGs from IS-IS advertisement (c)

Next, we apply the rules from (2) to this "updated set", because all of them were sourced from IS-IS, to derive a new set. The next rule that applies is (2)(c), and it's determined that collation is required for applications S and F. So we get the following "final set" 🔥

  1. ASLA with the S bit set on it that carries link attributes from IS-IS advertisement (a) and SRLGs from IS-IS advertisement (b) (this is collation for application S based on (2)(c))
  2. ASLA with the F bit set on it that carries link attributes from IS-IS advertisement (a) and SRLGs from IS-IS advertisement (b) (this is collation for application F based on (2)(c))
  3. ASLA with the X bit set on it that carries link attributes from IS-IS advertisement (a) (remaining application not affected by collation based on (2)(c))
  4. ASLA with zero-length bit masks with SRLGs from IS-IS advertisement (b) (not affected by (2)(c) and therefore carried forward unchanged from the "updated set")
  5. ASLA with the X bit set on it with SRLGs from IS-IS advertisement (c) (not affected by (2)(c) and therefore carried forward unchanged from the "updated set")

Implementations may optionally do further consolidation by processing the "final set" above based on (2)(d) to get the following "consolidated final set" 🌸

  1. ASLA with the S and F bits set on it that carries application-specific link attributes from IS-IS advertisement (a) and SRLGs from IS-IS advertisement (b) (this is the consolidation of items 1 and 2 of the "final set" based on (2)(d))
  2. ASLA with the X bit set on it that carries certain application-specific link attributes from IS-IS advertisement (a) (it is unaffected by this consolidation)
  3. ASLA with zero-length bit masks with a set of application-specific SRLGs from IS-IS advertisement (b) (this is retained based on (2)(e) and is unaffected by any further consolidation)
  4. ASLA with the X bit set on it with a set of application-specific SRLGs from IS-IS advertisement (c) (it is unaffected by this consolidation)

Further optimization (for example, combining (2) and (4) from the "consolidated final set" above into a single BGP-LS ASLA TLV) may be possible, as long as the semantics are preserved between the IS-IS and BGP-LS advertisements. Those optimizations are outside the scope of this document 🦋

5. Deployment Considerations 🚀

BGP-LS sources the link-state topology information (including the extensions introduced by this document) from the underlying link-state IGP protocols. The various deployment aspects related to advertising and using application-specific link attributes are discussed in the Deployment Considerations sections of [RFC8920] and [RFC8919]. The IGP backward-compatibility aspects described in those documents, combined with the BGP-LS procedures specified in this document, enable backward compatibility in deployments of existing implementations of [RFC7752], [RFC8571], and [RFC9104] for applications such as RSVP-TE, SR Policy, and LFA.

It's recommended that only nodes supporting this specification get selected as originators of BGP-LS information when advertising the link-state information from the IGPs in deployments that support application-specific link attributes 💜

BGP-LS consumers that don't support this specification can keep using the existing top-level TLVs for link attributes for existing applications, as discussed above. However, they wouldn't be able to support the application-specific link attributes or newer applications that may be encoded only using the ASLA TLV 🥲

6. IANA Considerations 🎀

IANA has assigned a code point from the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry, as shown in the following table. There's no "IS-IS TLV/Sub-TLV" value for this entry ✨

+================+======================================+===========+
| TLV Code Point | Description                          | Reference |
+================+======================================+===========+
| 1122           | Application-Specific                 | RFC 9294  |
|                | Link Attributes                      |           |
+----------------+--------------------------------------+-----------+

                  Table 2: ASLA TLV Code Point Allocation

7. Manageability Considerations 🌈

The protocol extensions introduced in this document augment the existing IGP topology information defined in [RFC7752]. The procedures and protocol extensions defined in this document don't affect BGP protocol operations and management, except as discussed in the Manageability Considerations section of [RFC7752]. Specifically, the malformed NLRI attribute tests in the Fault Management section of [RFC7752] now cover the BGP-LS TLVs defined in this document 🧚

The extensions specified in this document don't specify any new configuration or monitoring aspects in BGP or BGP-LS. The specification of BGP models is ongoing work based on [IDR-BGP-MODEL] 🍓

8. Security Considerations 🔐

Security considerations for acquiring and distributing BGP-LS information are discussed in [RFC7752]. Specifically, the considerations related to topology information, which are related to traffic engineering, apply. bestie, this part is serious 😭

The TLVs introduced in this document are used to propagate the application-specific link attributes IGP extensions defined in [RFC8919] and [RFC8920]. It is assumed that the IGP instances originating these TLVs will support all the required security (as described in [RFC8919] and [RFC8920]) 🛡️

This document defines a new way to advertise link attributes. Tampering with the information defined in this document may affect applications using it, including impacting traffic engineering, which uses various link attributes for its path computation. As the advertisements defined in this document limit the scope to specific applications, the impact of tampering is similarly limited in scope. The advertisement of the link attribute information defined in this document presents no significant additional risk beyond that associated with the existing link attribute information already supported in [RFC7752] 💀

9. References 📚

9.1. Normative References

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

[RFC7752]  Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
           S. Ray, "North-Bound Distribution of Link-State and
           Traffic Engineering (TE) Information Using BGP", RFC 7752,
           DOI 10.17487/RFC7752, March 2016,
           <https://www.rfc-editor.org/info/rfc7752>.

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

[RFC8571]  Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and
           C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of
           IGP Traffic Engineering Performance Metric Extensions",
           RFC 8571, DOI 10.17487/RFC8571, March 2019,
           <https://www.rfc-editor.org/info/rfc8571>.

[RFC8919]  Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and
           J. Drake, "IS-IS Application-Specific Link Attributes",
           RFC 8919, DOI 10.17487/RFC8919, October 2020,
           <https://www.rfc-editor.org/info/rfc8919>.

[RFC8920]  Psenak, P., Ed., Ginsberg, L., Henderickx, W., Tantsura,
           J., and J. Drake, "OSPF Application-Specific Link
           Attributes", RFC 8920, DOI 10.17487/RFC8920, October 2020,
           <https://www.rfc-editor.org/info/rfc8920>.

[RFC9104]  Tantsura, J., Wang, Z., Wu, Q., and K. Talaulikar,
           "Distribution of Traffic Engineering Extended
           Administrative Groups Using the Border Gateway Protocol -
           Link State (BGP-LS)", RFC 9104, DOI 10.17487/RFC9104,
           August 2021, <https://www.rfc-editor.org/info/rfc9104>.

9.2. Informative References

[IDR-BGP-MODEL]
           Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP
           YANG Model for Service Provider Networks", Work in
           Progress, Internet-Draft, draft-ietf-idr-bgp-model-14, 3
           July 2022, <https://datatracker.ietf.org/doc/html/draft-
           ietf-idr-bgp-model-14>.

[RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
           dual environments", RFC 1195, DOI 10.17487/RFC1195,
           December 1990, <https://www.rfc-editor.org/info/rfc1195>.

[RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
           DOI 10.17487/RFC2328, April 1998,
           <https://www.rfc-editor.org/info/rfc2328>.

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

[RFC4202]  Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions
           in Support of Generalized Multi-Protocol Label Switching
           (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005,
           <https://www.rfc-editor.org/info/rfc4202>.

[RFC5286]  Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
           IP Fast Reroute: Loop-Free Alternates", RFC 5286,
           DOI 10.17487/RFC5286, September 2008,
           <https://www.rfc-editor.org/info/rfc5286>.

[RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
           for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
           <https://www.rfc-editor.org/info/rfc5340>.

[RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
           Decraene, B., Litkowski, S., and R. Shakir, "Segment
           Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
           July 2018, <https://www.rfc-editor.org/info/rfc8402>.

Acknowledgements 🫶

Okay, big thank-you energy for everyone who helped make this doc happen! 💖 The authors wanted to shout out Les Ginsberg, Baalajee S., Amalesh Maity, Acee Lindem, Keyur Patel, Paul Wouters, Rudy Selderslaghs, Kristy Paine, and Shraddha Hegde for reviewing it and giving feedback. Literally iconic of them. 👑

Alvaro Retana also gets a huge shoutout 📣 for his very detailed AD review and comments, which made the document so much better ✨ (the glow-up was real).

And John Scudder deserves a standing ovation 👏 for his detailed review and feedback on clarifying the procedures, along with the example in Section 4. Those sections are way clearer because of him 🧚

Authors' Addresses 💅

Ketan Talaulikar (editor) Arrcus Inc. India Email: ketant.ietf@gmail.com

Peter Psenak Cisco Systems Slovakia Email: ppsenak@cisco.com

Jeff Tantsura Microsoft Email: jefftant.ietf@gmail.com

📦 where this page comes from