Arrcus Inc.

India ketant.ietf@gmail.com

Cisco Systems

Slovakia ppsenak@cisco.com

Microsoft

jefftant.ietf@gmail.com

rtg idr BGP-LS Segment Routing IS-IS OSPF OSPFv3 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 .

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 () 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

• .  Introduction
  • .  Requirements Language
• .  Application-Specific Link Attributes TLV
• .  Application-Specific Link Attributes
• .  Procedures
  • .  Illustration for IS-IS
• .  Deployment Considerations
• .  IANA Considerations
• .  Manageability Considerations
• .  Security Considerations
• .  References
  • .  Normative References
  • .  Informative References
• Acknowledgements
• Authors' Addresses

Introduction The Border Gateway Protocol - Link State (BGP-LS) enables the distribution of the link-state topology information from link-state routing protocols (viz., IS-IS , OSPFv2 , and OSPFv3 ) 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 or GMPLS applications). In recent years, applications, such as Segment Routing (SR) Policy and Loop-Free Alternates (LFA) , which also make use of link attributes, have been introduced. and 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.

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 when, and only when, they appear in all capitals, as shown here.

Application-Specific Link Attributes TLV BGP-LS 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 and , respectively.

Application-Specific Link Attributes TLV 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 // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:

Type:

1122

Length:

variable

SABM Length:

1-octet field that carries the Standard Application Identifier Bit Mask Length in octets as defined in .

UDABM Length:

1-octet field that carries the User-Defined Application Identifier Bit Mask Length in octets as defined in .

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 .

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

Link Attribute sub-TLVs:

BGP-LS Attribute TLVs corresponding to the Link NLRI that are application-specific (including existing ones as specified in ) 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 . 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 .

Application-Specific Link Attributes Several BGP-LS Attribute TLVs corresponding to the Link NLRI are defined in BGP-LS , 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 . These were originally defined with semantics for RSVP-TE and GMPLS applications in BGP-LS by the respective reference documents. Existing BGP-LS TLVs Identified as Application-Specific

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

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.

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. and 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 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) 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:
   1. 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 , , and . The same procedure also applies for the advertisement of the SRLG values from the IS-IS Application-Specific SRLG TLV.
   2. 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 , , and . 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 .
   3. 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 .
   4. 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.
   5. 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.
   6. 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.
   7. 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.

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:

1. IS-IS ASLA sub-TLV with the S, F, and X bits set on it that carries certain application-specific link attributes
2. IS-IS Application-Specific SRLG TLV with zero-length bit masks with a set of application-specific SRLGs
3. 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.

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 and . 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 , , and 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.

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. ASLA TLV Code Point Allocation

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

Manageability Considerations The protocol extensions introduced in this document augment the existing IGP topology information defined in . 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 . Specifically, the malformed NLRI attribute tests in the Fault Management section of 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 .

Security Considerations Security considerations for acquiring and distributing BGP-LS information are discussed in . 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 and . It is assumed that the IGP instances originating these TLVs will support all the required security (as described in and ). 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 .

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control. Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs). RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document defines new BGP - Link State (BGP-LS) TLVs in order to carry the IGP Traffic Engineering Metric Extensions defined in the IS-IS and OSPF protocols. Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application-specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements that address both of these shortcomings. Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application-specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements in OSPFv2 and OSPFv3 that address both of these shortcomings. Administrative groups are link attributes used for traffic engineering. This document defines an extension to the Border Gateway Protocol - Link State (BGP-LS) for advertisement of extended administrative groups (EAGs). Informative References Kloud Services Arrcus Huawei Juniper Networks This document defines a YANG data model for configuring and managing BGP, including protocol, policy, and operational aspects, such as RIB, based on data center, carrier, and content provider operational requirements. Work in Progress This memo specifies an integrated routing protocol, based on the OSI Intra-Domain IS-IS Routing Protocol, which may be used as an interior gateway protocol (IGP) to support TCP/IP as well as OSI. This allows a single routing protocol to be used to support pure IP environments, pure OSI environments, and dual environments. This specification was developed by the IS-IS working group of the Internet Engineering Task Force. [STANDARDS-TRACK] This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK] This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK] This document specifies routing extensions in support of carrying link state information for Generalized Multi-Protocol Label Switching (GMPLS). This document enhances the routing extensions required to support MPLS Traffic Engineering (TE). [STANDARDS-TRACK] This document describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS/LDP networks in the event of a single failure, whether link, node, or shared risk link group (SRLG). The goal of this technology is to reduce the packet loss that happens while routers converge after a topology change due to a failure. Rapid failure repair is achieved through use of precalculated backup next-hops that are loop-free and safe to use until the distributed network convergence process completes. This simple approach does not require any support from other routers. The extent to which this goal can be met by this specification is dependent on the topology of the network. [STANDARDS-TRACK] This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3). Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link State Advertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP). Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible. All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6. [STANDARDS-TRACK] Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.

Acknowledgements The authors would like to thank , , , , , , , , and for their review and feedback on this document. The authors would like to thank for his very detailed AD review and comments that improved this document. The authors would also like to thank for his detailed review and feedback on clarifying the procedures along with the example in .

Authors' Addresses Arrcus Inc.

India ketant.ietf@gmail.com

Cisco Systems

Slovakia ppsenak@cisco.com

Microsoft

jefftant.ietf@gmail.com