diff options
Diffstat (limited to 'doc/rfc/rfc9294.txt')
| -rw-r--r-- | doc/rfc/rfc9294.txt | 653 |
1 files changed, 653 insertions, 0 deletions
diff --git a/doc/rfc/rfc9294.txt b/doc/rfc/rfc9294.txt new file mode 100644 index 0000000..b426269 --- /dev/null +++ b/doc/rfc/rfc9294.txt @@ -0,0 +1,653 @@ + + + + +Internet Engineering Task Force (IETF) K. Talaulikar, Ed. +Request for Comments: 9294 Arrcus Inc. +Category: Standards Track P. Psenak +ISSN: 2070-1721 Cisco Systems + J. Tantsura + Microsoft + August 2022 + + + Application-Specific Link Attributes Advertisement Using the Border + Gateway Protocol - Link State (BGP-LS) + +Abstract + + Extensions have been defined for link-state routing protocols that + enable distribution of application-specific link attributes for + existing as well as newer applications such as Segment Routing (SR). + This document defines extensions to the Border Gateway Protocol - + Link State (BGP-LS) to enable the advertisement of these application- + specific attributes as a part of the topology information from the + network. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9294. + +Copyright Notice + + Copyright (c) 2022 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) 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 + 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 + + The Border Gateway Protocol - Link State (BGP-LS) [RFC7752] enables + the distribution of the link-state topology information from link- + state routing protocols (viz., IS-IS [RFC1195], OSPFv2 [RFC2328], and + OSPFv3 [RFC5340]) to an application like a controller or Path + Computation Engine (PCE) via BGP. The controller or PCE gets the + end-to-end topology information across IGP domains so it can perform + path computations for use cases like end-to-end traffic engineering + (TE). + + The link-state topology information distributed via BGP-LS includes + link attributes that were originally defined for MPLS TE (i.e., using + RSVP-TE [RFC3209] or GMPLS [RFC4202] applications). In recent years, + applications, such as Segment Routing (SR) Policy [RFC8402] and Loop- + Free Alternates (LFA) [RFC5286], which also make use of link + attributes, have been introduced. [RFC8919] and [RFC8920] define + extensions for IS-IS and OSPF, respectively, that enable advertising + application-specific link attributes for these and other future + applications. This has resulted in the need for a similar BGP-LS + extension to include this additional link-state topology information + from the link-state routing protocols. + + This document defines the BGP-LS extensions for the advertisement of + application-specific link attributes. It describes the advertisement + of these link attributes as top-level TLVs (i.e., as TLVs of the BGP- + LS Attribute) and as sub-TLVs of the (top-level) Application-Specific + Link Attributes (ASLA) TLV. The document also describes the + procedures for the advertisement of these attributes from the + underlying IGPs and discusses their deployment aspects. + +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. Application-Specific Link Attributes TLV + + BGP-LS [RFC7752] specifies the Link Network Layer Reachability + Information (NLRI) for the advertisement of links and their + attributes using the BGP-LS Attribute. The ASLA TLV is an optional + top-level BGP-LS Attribute TLV that is introduced for Link NLRIs. It + is defined such that it may act as a container for certain existing + and future link attributes that require application-specific + definition. + + The format of this TLV is as follows and is similar to the + corresponding ASLA sub-TLVs defined 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: 1-octet field that carries the Standard Application + Identifier Bit Mask Length in octets as defined in [RFC8920]. + + UDABM Length: 1-octet field that carries the User-Defined + Application Identifier Bit Mask Length in octets as defined in + [RFC8920]. + + Reserved: 2-octet field that MUST be set to zero on transmission and + MUST be ignored on reception. + + Standard Application Identifier Bit Mask: An optional set of bits + (of size 0, 4, or 8 octets as indicated by the SABM Length), where + each bit represents a single standard application as defined in + [RFC8919]. + + User-Defined Application Identifier Bit Mask: An optional set of + bits (of size 0, 4, or 8 octets as indicated by the UDABM Length), + where each bit represents a single user-defined application as + defined in [RFC8919] and [RFC8920]. + + Link Attribute sub-TLVs: BGP-LS Attribute TLVs corresponding to the + Link NLRI that are application-specific (including existing ones + as specified in Section 3) are included as sub-TLVs of the ASLA + TLV. + + The semantics associated with the standard and user-defined bit masks + as well as 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 underlying IGPs + are specified in Section 4. + +3. Application-Specific Link Attributes + + Several BGP-LS Attribute TLVs corresponding to the Link NLRI are + defined in BGP-LS [RFC7752], and more may be added in the future. + Those attributes that have been determined to be, and advertised as, + application-specific in the underlying IGPs are also encoded + similarly in BGP-LS. + + The following table lists the currently defined BGP-LS Attribute TLVs + corresponding to Link NLRI that can have application-specific + semantics based on the underlying IGP specifications [RFC8919] + [RFC8920]. These were originally defined with semantics for RSVP-TE + and GMPLS applications in BGP-LS by the respective reference + documents. + + +================+========================+====================+ + | 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 + + All the BGP-LS Attribute TLVs listed in the table above are REQUIRED + to be advertised as a top-level TLV in the BGP-LS Attribute when used + to carry link attributes specific to RSVP-TE. + + BGP-LS Attribute TLVs corresponding to Link NLRI that are advertised + in the underlying IGP as application-specific are REQUIRED to be + encoded within an ASLA TLV. + + Link attributes that do not have application-specific semantics MUST + NOT be advertised within the ASLA TLV. + + When the same application-specific link attributes are advertised + both within the ASLA TLV and as top-level TLVs in the BGP-LS + Attribute, the attributes advertised within the ASLA TLV take + precedence for the applications indicated in the ASLA TLV encoding. + +4. Procedures + + The BGP-LS originator learns of the association of an application- + specific attribute to one or more applications from the underlying + IGP protocol Link State Advertisements (LSAs) or Link State Packets + (LSPs) from which it is advertising the topology information. + [RFC8920] and [RFC8919] specify the mechanisms for advertising + application-specific link attributes in OSPF and IS-IS, respectively. + + Application-specific link attributes received from an IGP node + without the use of ASLA encodings continue to be encoded using the + respective BGP-LS top-level TLVs listed in Table 1 as specified in + their respective reference documents. + + While the ASLA encoding in OSPF is similar to that of BGP-LS, the + encoding in IS-IS differs and requires additional procedures when + conveying information into BGP-LS. One of these differences arises + from the presence of the L-flag in the IS-IS encoding. Another + difference arises due to the requirement to collate information from + two types of IS-IS encodings for application-specific link + information (i.e., the IS-IS ASLA sub-TLV and the IS-IS Application- + Specific Shared Risk Link Group (SRLG) TLV) [RFC8919] and to carry + them together in the BGP-LS ASLA TLV. + + A BGP-LS originator node that is advertising link-state information + from the underlying IGP using ASLA encodings determines their BGP-LS + encoding based on the following rules: + + 1. Application-specific link attributes received from an OSPF node + using an ASLA sub-TLV or from an IS-IS node using either an ASLA + sub-TLV or an Application-Specific SRLG TLV MUST be encoded in + the BGP-LS ASLA TLV as sub-TLVs. Exceptions to this rule are + specified in (2)(F) and (2)(G) below. + + 2. In the case of IS-IS, the specific procedures below are to be + followed: + + A. When application-specific link attributes are received from a + node with the L-flag set in the IS-IS ASLA sub-TLV and when + application bits (other than RSVP-TE) are set in the + application bit masks, then the application-specific link + attributes advertised in the corresponding legacy IS-IS TLVs + and sub-TLVs MUST be encoded within the BGP-LS ASLA TLV as + sub-TLVs with the application bits (other than the RSVP-TE + bit) copied from the IS-IS ASLA sub-TLV. The link attributes + advertised in the legacy IS-IS TLVs and sub-TLVs are also + advertised in BGP-LS top-level TLVs as per [RFC7752], + [RFC8571], and [RFC9104]. The same procedure also applies + for the advertisement of the 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, then the link attributes for the corresponding IS-IS + ASLA sub-TLVs MUST be encoded using the respective BGP-LS + top-level TLVs as per [RFC7752], [RFC8571], and [RFC9104]. + Similarly, when the IS-IS Application-Specific SRLG TLV has + the RSVP-TE application bit set, then the SRLG values within + it MUST be encoded using the top-level BGP-LS SRLG TLV (1096) + as per [RFC7752]. + + C. The SRLGs advertised in one or more IS-IS Application- + Specific SRLG TLVs and the other link attributes advertised + in one or more IS-IS ASLA sub-TLVs are REQUIRED to be + collated, on a per-application basis, only for those + applications that meet all the following criteria: + + * their bit is set in the SABM or UDABM in one of the two + types of IS-IS encodings (e.g., IS-IS ASLA sub-TLV) + + * the other encoding type (e.g., IS-IS Application Specific + SRLG TLV) has an advertisement with zero-length + application bit masks + + * there is no corresponding advertisement of that other + encoding type (following the example, IS-IS Application + Specific SRLG TLV) with that specific application bit set + + For each such application, its collated information MUST be + carried in a BGP-LS ASLA TLV with that application's bit set + in the SABM or UDABM. See the illustration in Section 4.1. + + D. If the resulting set of collated link attributes and SRLG + values is common across multiple applications, they MAY be + advertised in a common BGP-LS ASLA TLV instance where the + bits for all such applications would be 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 + the zero-length application bit mask, MUST be advertised into + a BGP-LS ASLA TLV with a zero-length application bit mask, + independent of the collation described above. + + F. [RFC8919] allows the advertisement of the Maximum Link + Bandwidth within an IS-IS ASLA sub-TLV even though it is not + an application-specific attribute. However, when originating + the Maximum Link Bandwidth into BGP-LS, the attribute MUST be + encoded only in the top-level BGP-LS Maximum Link Bandwidth + TLV (1089) and MUST NOT be advertised within the BGP-LS ASLA + TLV. + + G. [RFC8919] also allows the advertisement of the Maximum + Reservable Link Bandwidth and the Unreserved Bandwidth within + an IS-IS ASLA sub-TLV even though these attributes are + specific to RSVP-TE application. However, when originating + the Maximum Reservable Link Bandwidth and Unreserved + Bandwidth into BGP-LS, these attributes MUST be encoded only + in the BGP-LS top-level Maximum Reservable Link Bandwidth TLV + (1090) and Unreserved Bandwidth TLV (1091), respectively, and + not within the BGP-LS ASLA TLV. + + These rules ensure that a BGP-LS originator performs the + advertisement for all application-specific link attributes from the + IGP nodes that support the ASLA extension. Furthermore, it also + ensures that the top-level BGP-LS TLVs defined for RSVP-TE and GMPLS + applications continue to be used for advertisement of their + application-specific attributes. + + A BGP-LS speaker would normally advertise all the application- + specific link attributes corresponding to RSVP-TE and GMPLS + applications as existing top-level BGP-LS TLVs while for other + applications they are encoded in the ASLA TLV(s) with appropriate + applicable bit mask setting. An application-specific attribute value + received via a sub-TLV within the ASLA TLV has precedence over the + value received via a top-level TLV. + +4.1. Illustration for IS-IS + + This section illustrates the procedure for the advertisement of + application-specific link attributes from IS-IS into BGP-LS. + + 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 are conveyed to BGP-LS + to get the following "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 is determined that + collation is required for applications S and F; therefore, 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 perform further consolidation by + processing the "final set" above based on (2)(d) to determine 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 (e.g., combining (2) and (4) from the + "consolidated final set" above into a single BGP-LS ASLA TLV) may be + possible while ensuring that the semantics are preserved between the + IS-IS and BGP-LS advertisements. Such 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 the + advertisement and use of application-specific link attributes are + discussed in the Deployment Considerations sections of [RFC8920] and + [RFC8919]. The IGP backward-compatibility aspects described in those + documents associated with application-specific link attributes along + 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 is recommended that only nodes supporting this specification are + selected as originators of BGP-LS information when advertising the + link-state information from the IGPs in deployments supporting + application-specific link attributes. + + BGP-LS consumers that do not support this specification can continue + to use the existing top-level TLVs for link attributes for existing + applications as discussed above. However, they would be able to + support neither the application-specific link attributes nor 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 + described in the following table. There is 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]. Procedures + and protocol extensions defined in this document do not affect the + BGP protocol operations and management other than as discussed in the + Manageability Considerations section of [RFC7752]. Specifically, the + malformed NLRI attribute tests in the Fault Management section of + [RFC7752] now encompass the BGP-LS TLVs defined in this document. + + The extensions specified in this document do not specify any new + configuration or monitoring aspects in BGP or BGP-LS. The + specification of BGP models is an 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. + + 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 + + The authors would like to thank Les Ginsberg, Baalajee S., Amalesh + Maity, Acee Lindem, Keyur Patel, Paul Wouters, Rudy Selderslaghs, + Kristy Paine, and Shraddha Hegde for their review and feedback on + this document. The authors would like to thank Alvaro Retana for his + very detailed AD review and comments that improved this document. + The authors would also like to thank John Scudder for his detailed + review and feedback on clarifying the procedures along with the + example in Section 4. + +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 |