rfc9294.original   rfc9294.txt 
Inter-Domain Routing K. Talaulikar, Ed. Internet Engineering Task Force (IETF) K. Talaulikar, Ed.
Internet-Draft Arrcus Inc Request for Comments: 9294 Arrcus Inc.
Intended status: Standards Track P. Psenak Category: Standards Track P. Psenak
Expires: January 8, 2023 Cisco Systems ISSN: 2070-1721 Cisco Systems
J. Tantsura J. Tantsura
Microsoft Microsoft
July 7, 2022 August 2022
Application-Specific Attributes Advertisement with BGP Link-State Application-Specific Link Attributes Advertisement Using the Border
draft-ietf-idr-bgp-ls-app-specific-attr-16 Gateway Protocol - Link State (BGP-LS)
Abstract Abstract
Extensions have been defined for link-state routing protocols that Extensions have been defined for link-state routing protocols that
enable distribution of application-specific link attributes for enable distribution of application-specific link attributes for
existing as well as newer applications such as Segment Routing. This existing as well as newer applications such as Segment Routing (SR).
document defines extensions to BGP-LS to enable the advertisement of This document defines extensions to the Border Gateway Protocol -
these application-specific attributes as a part of the topology Link State (BGP-LS) to enable the advertisement of these application-
information from the network. specific attributes as a part of the topology information from the
network.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on January 8, 2023. 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 Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Revised BSD License text as described in Section 4.e of the
the Trust Legal Provisions and are provided without warranty as Trust Legal Provisions and are provided without warranty as described
described in the Simplified BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language
2. Application Specific Link Attributes TLV . . . . . . . . . . 3 2. Application-Specific Link Attributes TLV
3. Application-Specific Link Attributes . . . . . . . . . . . . 4 3. Application-Specific Link Attributes
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Procedures
4.1. Illustration for IS-IS . . . . . . . . . . . . . . . . . 8 4.1. Illustration for IS-IS
5. Deployment Considerations . . . . . . . . . . . . . . . . . . 10 5. Deployment Considerations
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations
7. Manageability Considerations . . . . . . . . . . . . . . . . 11 7. Manageability Considerations
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 9. References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References
10.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References
10.2. Informative References . . . . . . . . . . . . . . . . . 13 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses
1. Introduction 1. Introduction
BGP Link-State [RFC7752] enables the distribution of the link-state The Border Gateway Protocol - Link State (BGP-LS) [RFC7752] enables
topology information from link-state routing protocols (viz., IS-IS the distribution of the link-state topology information from link-
[RFC1195], OSPFv2 [RFC2328] and OSPFv3 [RFC5340]) to an application state routing protocols (viz., IS-IS [RFC1195], OSPFv2 [RFC2328], and
like a controller or Path Computation Engine (PCE) via BGP. The OSPFv3 [RFC5340]) to an application like a controller or Path
controller/PCE gets the end-to-end topology information across IGP Computation Engine (PCE) via BGP. The controller or PCE gets the
domains so it can perform path computations for use cases like end- end-to-end topology information across IGP domains so it can perform
to-end traffic engineering (TE). path computations for use cases like end-to-end traffic engineering
(TE).
The link-state topology information distributed via BGP-LS includes The link-state topology information distributed via BGP-LS includes
link attributes that were originally defined for MPLS Traffic link attributes that were originally defined for MPLS TE (i.e., using
Engineering (i.e., using RSVP-TE [RFC3209]) or GMPLS [RFC4202]) RSVP-TE [RFC3209] or GMPLS [RFC4202] applications). In recent years,
applications. In recent years applications, such as Segment Routing applications, such as Segment Routing (SR) Policy [RFC8402] and Loop-
(SR) Policy [RFC8402] and Loop-Free Alternates (LFA) [RFC5286], which Free Alternates (LFA) [RFC5286], which also make use of link
also make use of link attributes have been introduced. [RFC8919] and attributes, have been introduced. [RFC8919] and [RFC8920] define
[RFC8920] define extensions for IS-IS and OSPF respectively that extensions for IS-IS and OSPF, respectively, that enable advertising
enable advertising application-specific link attributes for these and application-specific link attributes for these and other future
other future applications. This has resulted in the need for a applications. This has resulted in the need for a similar BGP-LS
similar BGP-LS extension to include this additional link-state extension to include this additional link-state topology information
topology information from the link-state routing protocols. from the link-state routing protocols.
This document defines the BGP-LS extensions for the advertisement of This document defines the BGP-LS extensions for the advertisement of
application-specific link attributes. It describes the advertisement application-specific link attributes. It describes the advertisement
of these link attributes as top-level TLVs (i.e., as TLVs of the BGP- 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 LS Attribute) and as sub-TLVs of the (top-level) Application-Specific
Link Attributes TLV. The document also describes the procedures for Link Attributes (ASLA) TLV. The document also describes the
the advertisement of these attributes from the underlying IGPs and procedures for the advertisement of these attributes from the
discusses their deployment aspects. underlying IGPs and discusses their deployment aspects.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Application Specific Link Attributes TLV 2. Application-Specific Link Attributes TLV
The BGP-LS [RFC7752] specifies the Link Network Layer Reachability BGP-LS [RFC7752] specifies the Link Network Layer Reachability
Information (NLRI) for the advertisement of links and their Information (NLRI) for the advertisement of links and their
attributes using the BGP-LS Attribute. The Application-Specific Link attributes using the BGP-LS Attribute. The ASLA TLV is an optional
Attributes (ASLA) TLV is an optional top-level BGP-LS Attribute TLV top-level BGP-LS Attribute TLV that is introduced for Link NLRIs. It
that is introduced for Link NLRIs. It is defined such that it may is defined such that it may act as a container for certain existing
act as a container for certain existing and future link attributes and future link attributes that require application-specific
that require application-specific definition. definition.
The format of this TLV is as follows and is similar to the 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] corresponding ASLA sub-TLVs defined for OSPF and IS-IS in [RFC8920]
and [RFC8919] respectively. and [RFC8919], respectively.
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SABM Length | UDABM Length | Reserved | | SABM Length | UDABM Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Standard Application Identifier Bit Mask (variable) // | Standard Application Identifier Bit Mask (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-Defined Application Identifier Bit Mask (variable) // | User-Defined Application Identifier Bit Mask (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Attribute sub-TLVs // | Link Attribute sub-TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Application-Specific Link Attributes TLV Figure 1: Application-Specific Link Attributes TLV
where: where:
o Type: 1122 Type: 1122
o Length: variable. Length: variable
o SABM Length : 1 octet field carrying the Standard Application SABM Length: 1-octet field that carries the Standard Application
Identifier Bit Mask Length in octets as defined in [RFC8920]. Identifier Bit Mask Length in octets as defined in [RFC8920].
o UDABM Length : 1 octet field carrying the User-Defined Application UDABM Length: 1-octet field that carries the User-Defined
Identifier Bit Mask Length in octets as defined in [RFC8920]. Application Identifier Bit Mask Length in octets as defined in
[RFC8920].
o Reserved: 2 octet field that MUST be set to zero on transmission Reserved: 2-octet field that MUST be set to zero on transmission and
and MUST be ignored on reception. MUST be ignored on reception.
o Standard Application Identifier Bit Mask : An optional set of bits Standard Application Identifier Bit Mask: An optional set of bits
(of size 0, 4, or 8 octets as indicated by the SABM Length), where (of size 0, 4, or 8 octets as indicated by the SABM Length), where
each bit represents a single standard application as defined in each bit represents a single standard application as defined in
[RFC8919]. [RFC8919].
o User-Defined Application Identifier Bit Mask : An optional set of User-Defined Application Identifier Bit Mask: An optional set of
bits (of size 0, 4, or 8 octets as indicated by the UDABM Length), bits (of size 0, 4, or 8 octets as indicated by the UDABM Length),
where each bit represents a single user-defined application as where each bit represents a single user-defined application as
defined in [RFC8919] [RFC8920].. defined in [RFC8919] and [RFC8920].
o Link Attribute sub-TLVs : BGP-LS Attribute TLVs corresponding to Link Attribute sub-TLVs: BGP-LS Attribute TLVs corresponding to the
the Link NLRI that are application-specific (including existing Link NLRI that are application-specific (including existing ones
ones as specified in Section 3) are included as sub-TLVs of the as specified in Section 3) are included as sub-TLVs of the ASLA
ASLA TLV. TLV.
The semantics associated with the standard and user-defined bit masks The semantics associated with the standard and user-defined bit masks
as well as the encoding scheme for application-specific attributes as well as the encoding scheme for application-specific attributes
are as specified in [RFC8920]. are as specified in [RFC8920].
The ASLA TLV and its sub-TLVs can only be added to the BGP-LS 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 Attribute associated with the Link NLRI of the node that originates
the underlying IGP link attribute TLVs/sub-TLVs. The procedures for the underlying IGP link attribute TLVs and sub-TLVs. The procedures
originating link attributes in the ASLA TLV from underlying IGPs are for originating link attributes in the ASLA TLV from underlying IGPs
specified in Section 4. are specified in Section 4.
3. Application-Specific Link Attributes 3. Application-Specific Link Attributes
Several BGP-LS Attribute TLVs corresponding to the Link NLRI are Several BGP-LS Attribute TLVs corresponding to the Link NLRI are
defined in BGP-LS and more may be added in the future. Those defined in BGP-LS [RFC7752], and more may be added in the future.
attributes that have been determined to be, and advertised as Those attributes that have been determined to be, and advertised as,
application-specific in the underlying IGPs are also encoded application-specific in the underlying IGPs are also encoded
similarly in BGP-LS. similarly in BGP-LS.
The following table lists the currently defined BGP-LS Attributes The following table lists the currently defined BGP-LS Attribute TLVs
TLVs corresponding to Link NLRI that can have application-specific corresponding to Link NLRI that can have application-specific
semantics based on the underlying IGP specifications [RFC8919] semantics based on the underlying IGP specifications [RFC8919]
[RFC8920]. These were originally defined with semantics for RSVP-TE [RFC8920]. These were originally defined with semantics for RSVP-TE
and GMPLS applications in BGP-LS by the respective reference and GMPLS applications in BGP-LS by the respective reference
documents. documents.
+---------------+-------------------------------+-------------------+ +================+========================+====================+
| TLV Code | Description | Reference | | TLV Code Point | Description | Reference Document |
| Point | | Document | +================+========================+====================+
+---------------+-------------------------------+-------------------+ | 1088 | Administrative group | [RFC7752] |
| 1088 | Administrative group (color) | [RFC7752] | | | (color) | |
| 1092 | TE Default Metric | [RFC7752] | +----------------+------------------------+--------------------+
| 1096 | Shared Risk Link Group | [RFC7752] | | 1092 | TE Default Metric | [RFC7752] |
| 1114 | Unidirectional Link Delay | [RFC8571] | +----------------+------------------------+--------------------+
| 1115 | Min/Max Unidirectional Link | [RFC8571] | | 1096 | Shared Risk Link Group | [RFC7752] |
| | Delay | | +----------------+------------------------+--------------------+
| 1116 | Unidirectional Delay | [RFC8571] | | 1114 | Unidirectional Link | [RFC8571] |
| | Variation | | | | Delay | |
| 1117 | Unidirectional Link Loss | [RFC8571] | +----------------+------------------------+--------------------+
| 1118 | Unidirectional Residual | [RFC8571] | | 1115 | Min/Max Unidirectional | [RFC8571] |
| | Bandwidth | | | | Link Delay | |
| 1119 | Unidirectional Available | [RFC8571] | +----------------+------------------------+--------------------+
| | Bandwidth | | | 1116 | Unidirectional Delay | [RFC8571] |
| 1120 | Unidirectional Utilized | [RFC8571] | | | Variation | |
| | Bandwidth | | +----------------+------------------------+--------------------+
| 1173 | Extended Administrative Group | [RFC9104] | | 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 Table 1: Existing BGP-LS TLVs Identified as Application-Specific
All the BGP-LS Attribute TLVs listed in the table above are REQUIRED 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 be advertised as a top-level TLV in the BGP-LS Attribute when used
to carry link attributes specific to RSVP-TE. to carry link attributes specific to RSVP-TE.
BGP-LS Attribute TLVs corresponding to Link NLRI that are advertised BGP-LS Attribute TLVs corresponding to Link NLRI that are advertised
in the underlying IGP as application-specific are REQUIRED to be in the underlying IGP as application-specific are REQUIRED to be
encoded within an ASLA TLV. encoded within an ASLA TLV.
Link attributes that do not have application-specific semantics MUST Link attributes that do not have application-specific semantics MUST
skipping to change at page 5, line 49 skipping to change at line 252
When the same application-specific link attributes are advertised When the same application-specific link attributes are advertised
both within the ASLA TLV and as top-level TLVs in the BGP-LS both within the ASLA TLV and as top-level TLVs in the BGP-LS
Attribute, the attributes advertised within the ASLA TLV take Attribute, the attributes advertised within the ASLA TLV take
precedence for the applications indicated in the ASLA TLV encoding. precedence for the applications indicated in the ASLA TLV encoding.
4. Procedures 4. Procedures
The BGP-LS originator learns of the association of an application- The BGP-LS originator learns of the association of an application-
specific attribute to one or more applications from the underlying specific attribute to one or more applications from the underlying
IGP protocol LSA/LSPs from which it is advertising the topology IGP protocol Link State Advertisements (LSAs) or Link State Packets
information. [RFC8920] and [RFC8919] specify the mechanisms for (LSPs) from which it is advertising the topology information.
advertising application-specific link attributes in OSPF and IS-IS [RFC8920] and [RFC8919] specify the mechanisms for advertising
respectively. application-specific link attributes in OSPF and IS-IS, respectively.
Application-specific link attributes received from an IGP node Application-specific link attributes received from an IGP node
without the use of ASLA encodings continue to be encoded using the 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 respective BGP-LS top-level TLVs listed in Table 1 as specified in
their respective reference documents. their respective reference documents.
While the ASLA encoding in OSPF is similar to that of BGP-LS, the While the ASLA encoding in OSPF is similar to that of BGP-LS, the
encoding in IS-IS differs and requires additional procedures when encoding in IS-IS differs and requires additional procedures when
conveying information into BGP-LS. One of these differences arises conveying information into BGP-LS. One of these differences arises
from the presence of the L-flag in the IS-IS encoding. Another from the presence of the L-flag in the IS-IS encoding. Another
difference arises due to the requirement to collate information from difference arises due to the requirement to collate information from
two types of IS-IS encodings for application-specific link two types of IS-IS encodings for application-specific link
information (i.e., the IS-IS ASLA sub-TLV and the IS-IS Application- information (i.e., the IS-IS ASLA sub-TLV and the IS-IS Application-
Specific SRLG TLV) [RFC8919] and to carry them together in the BGP-LS Specific Shared Risk Link Group (SRLG) TLV) [RFC8919] and to carry
ASLA TLV. them together in the BGP-LS ASLA TLV.
A BGP-LS originator node that is advertising link-state information A BGP-LS originator node that is advertising link-state information
from the underlying IGP using ASLA encodings determines their BGP-LS from the underlying IGP using ASLA encodings determines their BGP-LS
encoding based on the following rules: encoding based on the following rules:
1. Application-specific link attributes received from an OSPF node 1. Application-specific link attributes received from an OSPF node
using ASLA sub-TLV or from an IS-IS node using either ASLA sub- using an ASLA sub-TLV or from an IS-IS node using either an ASLA
TLV or Application-Specific SRLG TLV MUST be encoded in the BGP- sub-TLV or an Application-Specific SRLG TLV MUST be encoded in
LS ASLA TLV as sub-TLVs. Exceptions to this rule are specified the BGP-LS ASLA TLV as sub-TLVs. Exceptions to this rule are
in (2)(F) and (2)(G) below. specified in (2)(F) and (2)(G) below.
2. In the case of IS-IS, the following specific procedures are to be 2. In the case of IS-IS, the specific procedures below are to be
followed: followed:
A. When application-specific link attributes are received from a A. When application-specific link attributes are received from a
node with the L-flag set in the IS-IS ASLA sub-TLV and 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 bits (other than RSVP-TE) are set in the
application bit masks then the application-specific link application bit masks, then the application-specific link
attributes advertised in the corresponding legacy IS-IS TLVs/ attributes advertised in the corresponding legacy IS-IS TLVs
sub-TLVs MUST be encoded within the BGP-LS ASLA TLV as sub- and sub-TLVs MUST be encoded within the BGP-LS ASLA TLV as
TLVs with the application bits, other than the RSVP-TE bit, sub-TLVs with the application bits (other than the RSVP-TE
copied from the IS-IS ASLA sub-TLV. The link attributes bit) copied from the IS-IS ASLA sub-TLV. The link attributes
advertised in the legacy IS-IS TLVs/sub-TLVs are also advertised in the legacy IS-IS TLVs and sub-TLVs are also
advertised in BGP-LS top-level TLVs as per [RFC7752] advertised in BGP-LS top-level TLVs as per [RFC7752],
[RFC8571] [RFC9104]. The same procedure also applies for the [RFC8571], and [RFC9104]. The same procedure also applies
advertisement of the SRLG values from the IS-IS Application- for the advertisement of the SRLG values from the IS-IS
Specific SRLG TLV. Application-Specific SRLG TLV.
B. When the IS-IS ASLA sub-TLV has the RSVP-TE application bit B. When the IS-IS ASLA sub-TLV has the RSVP-TE application bit
set, then the link attributes for the corresponding IS-IS set, then the link attributes for the corresponding IS-IS
ASLA sub-TLVs MUST be encoded using the respective BGP-LS ASLA sub-TLVs MUST be encoded using the respective BGP-LS
top-level TLVs as per [RFC7752] [RFC8571] [RFC9104]. top-level TLVs as per [RFC7752], [RFC8571], and [RFC9104].
Similarly, when the IS-IS Application-Specific SRLG TLV has Similarly, when the IS-IS Application-Specific SRLG TLV has
the RSVP-TE application bit set, then the SRLG values within the RSVP-TE application bit set, then the SRLG values within
it MUST be encoded using the top-level BGP-LS SRLG TLV (1096) it MUST be encoded using the top-level BGP-LS SRLG TLV (1096)
as per [RFC7752]. as per [RFC7752].
C. The SRLGs advertised in IS-IS Application-Specific SRLG C. The SRLGs advertised in one or more IS-IS Application-
TLV(s) and the other link attributes advertised in IS-IS ASLA Specific SRLG TLVs and the other link attributes advertised
sub-TLV(s) are REQUIRED to be collated, on a per-application in one or more IS-IS ASLA sub-TLVs are REQUIRED to be
basis, only for those applications that meet all the collated, on a per-application basis, only for those
following criteria: applications that meet all the following criteria:
+ their bit is set in the SABM/UDABM in one of the two types * their bit is set in the SABM or UDABM in one of the two
of IS-IS encodings (e.g., IS-IS ASLA sub-TLV) types of IS-IS encodings (e.g., IS-IS ASLA sub-TLV)
+ the other encoding type (e.g., IS-IS Application Specific * the other encoding type (e.g., IS-IS Application Specific
SRLG TLV) has an advertisement with zero-length SRLG TLV) has an advertisement with zero-length
application bit masks application bit masks
+ there is no corresponding advertisement of that other * there is no corresponding advertisement of that other
encoding type (following the example, IS-IS Application encoding type (following the example, IS-IS Application
Specific SRLG TLV) with that specific application bit set Specific SRLG TLV) with that specific application bit set
For each such application, its collated information MUST be For each such application, its collated information MUST be
carried in a BGP-LS ASLA TLV with that application's bit set carried in a BGP-LS ASLA TLV with that application's bit set
in the SABM/UDABM. See illustration in Section 4.1. in the SABM or UDABM. See the illustration in Section 4.1.
D. If the resulting set of collated link attributes and SRLG D. If the resulting set of collated link attributes and SRLG
values is common across multiple applications, they MAY be values is common across multiple applications, they MAY be
advertised in a common BGP-LS ASLA TLV instance where the advertised in a common BGP-LS ASLA TLV instance where the
bits for all such applications would be set in the bits for all such applications would be set in the
application bit mask. application bit mask.
E. Both the SRLG values from IS-IS Application-Specific SRLG E. Both the SRLG values from IS-IS Application-Specific SRLG
TLVs and the link attributes from IS-IS ASLA sub-TLVs, with TLVs and the link attributes from IS-IS ASLA sub-TLVs, with
the zero-length application bit mask, MUST be advertised into the zero-length application bit mask, MUST be advertised into
skipping to change at page 8, line 7 skipping to change at line 356
TLV (1089) and MUST NOT be advertised within the BGP-LS ASLA TLV (1089) and MUST NOT be advertised within the BGP-LS ASLA
TLV. TLV.
G. [RFC8919] also allows the advertisement of the Maximum G. [RFC8919] also allows the advertisement of the Maximum
Reservable Link Bandwidth and the Unreserved Bandwidth within Reservable Link Bandwidth and the Unreserved Bandwidth within
an IS-IS ASLA sub-TLV even though these attributes are an IS-IS ASLA sub-TLV even though these attributes are
specific to RSVP-TE application. However, when originating specific to RSVP-TE application. However, when originating
the Maximum Reservable Link Bandwidth and Unreserved the Maximum Reservable Link Bandwidth and Unreserved
Bandwidth into BGP-LS, these attributes MUST be encoded only Bandwidth into BGP-LS, these attributes MUST be encoded only
in the BGP-LS top-level Maximum Reservable Link Bandwidth TLV in the BGP-LS top-level Maximum Reservable Link Bandwidth TLV
(1090) and Unreserved Bandwidth TLV (1091) respectively and (1090) and Unreserved Bandwidth TLV (1091), respectively, and
not within the BGP-LS ASLA TLV. not within the BGP-LS ASLA TLV.
These rules ensure that a BGP-LS originator performs the These rules ensure that a BGP-LS originator performs the
advertisement for all application-specific link attributes from the advertisement for all application-specific link attributes from the
IGP nodes that support the ASLA extension. Furthermore, it also IGP nodes that support the ASLA extension. Furthermore, it also
ensures that the top-level BGP-LS TLVs defined for RSVP-TE and GMPLS ensures that the top-level BGP-LS TLVs defined for RSVP-TE and GMPLS
applications continue to be used for advertisement of their applications continue to be used for advertisement of their
application-specific attributes. application-specific attributes.
A BGP-LS speaker would normally advertise all the application- A BGP-LS speaker would normally advertise all the application-
specific link attributes corresponding to RSVP-TE and GMPLS specific link attributes corresponding to RSVP-TE and GMPLS
applications as existing top-level BGP-LS TLVs while for other applications as existing top-level BGP-LS TLVs while for other
applications they are encoded in ASLA TLV(s) with appropriate applications they are encoded in the ASLA TLV(s) with appropriate
applicable bit mask setting. An application-specific attribute value applicable bit mask setting. An application-specific attribute value
received via a sub-TLV within the ASLA TLV has precedence over the received via a sub-TLV within the ASLA TLV has precedence over the
value received via a top-level TLV. value received via a top-level TLV.
4.1. Illustration for IS-IS 4.1. Illustration for IS-IS
This section illustrates the procedure for the advertisement of This section illustrates the procedure for the advertisement of
application-specific link attributes from IS-IS into BGP-LS. application-specific link attributes from IS-IS into BGP-LS.
Consider the following advertisements for a link in IS-IS. We start Consider the following advertisements for a link in IS-IS. We start
with this set: with this set:
a. An IS-IS ASLA sub-TLV with S, F, and X bits set on it carrying a. IS-IS ASLA sub-TLV with the S, F, and X bits set on it that
certain application-specific link attributes carries certain application-specific link attributes
b. An IS-IS Application-Specific SRLG TLV with zero-length bit masks b. IS-IS Application-Specific SRLG TLV with zero-length bit masks
with a set of application-specific SRLGs with a set of application-specific SRLGs
c. An IS-IS Application-Specific SRLG TLV with the X bit set on it c. IS-IS Application-Specific SRLG TLV with the X bit set on it with
with a set of application-specific SRLGs a set of application-specific SRLGs
The corresponding BGP-LS advertisements for that link are determined The corresponding BGP-LS advertisements for that link are determined
as follows: as follows:
First, based on rule (1), the advertisements are conveyed to BGP-LS First, based on rule (1), the advertisements are conveyed to BGP-LS
to get the following "updated set": to get the following "updated set":
1. ASLA with S, F, and X bits set on it carrying link attributes 1. ASLA with the S, F, and X bits set on it that carries link
from IS-IS advertisement (a) attributes from IS-IS advertisement (a)
2. ASLA SRLG with zero-length bit masks with a set of SRLGs from IS- 2. ASLA SRLG with zero-length bit masks with a set of SRLGs from IS-
IS advertisement (b) IS advertisement (b)
3. ASLA SRLG with the X bit set on it with a set of SRLGs from IS-IS 3. ASLA SRLG with the X bit set on it with a set of SRLGs from IS-IS
advertisement (c) advertisement (c)
Next, we apply the rules from (2) to this "updated set", because all 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. 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 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 collation is required for applications S and F; therefore, we get the
following "final set": following "final set":
1. ASLA with the S bit set on it carrying link attributes from IS-IS 1. ASLA with the S bit set on it that carries link attributes from
advertisement (a) and SRLGs from IS-IS advertisement (b) (this is IS-IS advertisement (a) and SRLGs from IS-IS advertisement (b)
collation for application S based on (2)(c)) (this is collation for application S based on (2)(c))
2. ASLA with the F bit set on it carrying link attributes from IS-IS 2. ASLA with the F bit set on it that carries link attributes from
advertisement (a) and SRLGs from IS-IS advertisement (b) (this is IS-IS advertisement (a) and SRLGs from IS-IS advertisement (b)
collation for application F based on (2)(c)) (this is collation for application F based on (2)(c))
3. ASLA with the X bit set on it carrying link attributes from IS-IS 3. ASLA with the X bit set on it that carries link attributes from
advertisement (a) (remaining application not affected by IS-IS advertisement (a) (remaining application not affected by
collation based on (2)(c)) collation based on (2)(c))
4. ASLA with zero-length bit masks with SRLGs from IS-IS 4. ASLA with zero-length bit masks with SRLGs from IS-IS
advertisement (b) (not affected by (2)(c) and therefore carried advertisement (b) (not affected by (2)(c) and therefore carried
forward unchanged from the "updated set") forward unchanged from the "updated set")
5. ASLA with the X bit set on it with SRLGs from IS-IS advertisement 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 (c) (not affected by (2)(c) and therefore carried forward
unchanged from the "updated set") unchanged from the "updated set")
Implementations may optionally perform further consolidation by Implementations may optionally perform further consolidation by
processing the "final set" above based on (2)(d) to determine the processing the "final set" above based on (2)(d) to determine the
following "consolidated final set": following "consolidated final set":
1. ASLA with S and F bits set on it carrying application-specific 1. ASLA with the S and F bits set on it that carries application-
link attributes from IS-IS advertisement (a) and SRLGs from IS-IS specific link attributes from IS-IS advertisement (a) and SRLGs
advertisement (b) (this is the consolidation of items 1 and 2 of from IS-IS advertisement (b) (this is the consolidation of items
the "final set" based on (2)(d)) 1 and 2 of the "final set" based on (2)(d))
2. ASLA with the X bit set on it carrying certain application- 2. ASLA with the X bit set on it that carries certain application-
specific link attributes from IS-IS advertisement (a) (it is specific link attributes from IS-IS advertisement (a) (it is
unaffected by this consolidation) unaffected by this consolidation)
3. ASLA with zero-length bit masks with a set of application- 3. ASLA with zero-length bit masks with a set of application-
specific SRLGs from IS-IS advertisement (b) (this is retained specific SRLGs from IS-IS advertisement (b) (this is retained
based on (2)(e) and is unaffected by any further consolidation) 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 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 SRLGs from IS-IS advertisement (c) (it is unaffected by this
consolidation) consolidation)
skipping to change at page 10, line 26 skipping to change at line 467
IS-IS and BGP-LS advertisements. Such optimizations are outside the IS-IS and BGP-LS advertisements. Such optimizations are outside the
scope of this document. scope of this document.
5. Deployment Considerations 5. Deployment Considerations
BGP-LS sources the link-state topology information (including the BGP-LS sources the link-state topology information (including the
extensions introduced by this document) from the underlying link- extensions introduced by this document) from the underlying link-
state IGP protocols. The various deployment aspects related to the state IGP protocols. The various deployment aspects related to the
advertisement and use of application-specific link attributes are advertisement and use of application-specific link attributes are
discussed in the Deployment Considerations sections of [RFC8920] and discussed in the Deployment Considerations sections of [RFC8920] and
[RFC8919]. The IGP backward compatibility aspects described in those [RFC8919]. The IGP backward-compatibility aspects described in those
documents associated with application-specific link attributes along documents associated with application-specific link attributes along
with the BGP-LS procedures specified in this document enable backward with the BGP-LS procedures specified in this document enable backward
compatibility in deployments of existing implementations of [RFC7752] compatibility in deployments of existing implementations of
[RFC8571] [RFC9104] for applications such as RSVP-TE, SR Policy, and [RFC7752], [RFC8571], and [RFC9104] for applications such as RSVP-TE,
LFA. SR Policy, and LFA.
It is recommended that only nodes supporting this specification are It is recommended that only nodes supporting this specification are
selected as originators of BGP-LS information when advertising the selected as originators of BGP-LS information when advertising the
link-state information from the IGPs in deployments supporting link-state information from the IGPs in deployments supporting
application-specific link attributes. application-specific link attributes.
BGP-LS consumers that do not support this specification can continue BGP-LS consumers that do not support this specification can continue
to use the existing top-level TLVs for link attributes for existing to use the existing top-level TLVs for link attributes for existing
applications as discussed above. They would, however, be able to applications as discussed above. However, they would be able to
support neither the application-specific link attributes nor newer support neither the application-specific link attributes nor newer
applications that may be encoded only using the ASLA TLV. applications that may be encoded only using the ASLA TLV.
6. IANA Considerations 6. IANA Considerations
IANA has assigned, through the early allocation process, the IANA has assigned a code point from the "BGP-LS Node Descriptor, Link
following code-point from the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry as
Descriptor, Prefix Descriptor, and Attribute TLVs" registry. This described in the following table. There is no "IS-IS TLV/Sub-TLV"
document requests that the allocation be made permanent. The column value for this entry.
"IS-IS TLV/Sub-TLV" defined in the registry does not require any
value and should be left empty.
+------------+--------------------------------------+---------------+ +================+======================================+===========+
| Code Point | Description | Reference | | TLV Code Point | Description | Reference |
+------------+--------------------------------------+---------------+ +================+======================================+===========+
| 1122 | Application-Specific Link Attributes | this document | | 1122 | Application-Specific | RFC 9294 |
+------------+--------------------------------------+---------------+ | | Link Attributes | |
+----------------+--------------------------------------+-----------+
Table 2: ASLA TLV Code-Point Allocation Table 2: ASLA TLV Code Point Allocation
7. Manageability Considerations 7. Manageability Considerations
The protocol extensions introduced in this document augment the The protocol extensions introduced in this document augment the
existing IGP topology information defined in [RFC7752]. Procedures existing IGP topology information defined in [RFC7752]. Procedures
and protocol extensions defined in this document do not affect the and protocol extensions defined in this document do not affect the
BGP protocol operations and management other than as discussed in the BGP protocol operations and management other than as discussed in the
Manageability Considerations section of [RFC7752]. Specifically, the Manageability Considerations section of [RFC7752]. Specifically, the
malformed NLRIs attribute tests in the Fault Management section of malformed NLRI attribute tests in the Fault Management section of
[RFC7752] now encompasses the BGP-LS TLVs defined in this document. [RFC7752] now encompass the BGP-LS TLVs defined in this document.
The extensions specified in this document do not specify any new The extensions specified in this document do not specify any new
configuration or monitoring aspects in BGP or BGP-LS. The configuration or monitoring aspects in BGP or BGP-LS. The
specification of BGP models is an ongoing work based on specification of BGP models is an ongoing work based on
[I-D.ietf-idr-bgp-model]. [IDR-BGP-MODEL].
8. Security Considerations 8. Security Considerations
Security considerations for acquiring and distributing BGP-LS Security considerations for acquiring and distributing BGP-LS
information are discussed in [RFC7752]. Specifically, the information are discussed in [RFC7752]. Specifically, the
considerations related to topology information related to traffic considerations related to topology information, which are related to
engineering apply. traffic engineering, apply.
The TLVs introduced in this document are used to propagate the The TLVs introduced in this document are used to propagate the
application-specific link attributes IGP extensions defined in application-specific link attributes IGP extensions defined in
[RFC8919] and [RFC8920]. It is assumed that the IGP instances [RFC8919] and [RFC8920]. It is assumed that the IGP instances
originating these TLVs will support all the required security (as originating these TLVs will support all the required security (as
described in [RFC8919] and [RFC8920]). described in [RFC8919] and [RFC8920]).
This document defines a new way to advertise link attributes. This document defines a new way to advertise link attributes.
Tampering with the information defined in this document may affect Tampering with the information defined in this document may affect
applications using it, including impacting traffic engineering, which applications using it, including impacting traffic engineering, which
uses various link attributes for its path computation. As the uses various link attributes for its path computation. As the
advertisements defined in this document limit the scope to specific advertisements defined in this document limit the scope to specific
applications, the impact of tampering is similarly limited in scope. applications, the impact of tampering is similarly limited in scope.
The advertisement of the link attribute information defined in this The advertisement of the link attribute information defined in this
document presents no significant additional risk beyond that document presents no significant additional risk beyond that
associated with the existing link attribute information already associated with the existing link attribute information already
supported in [RFC7752]. supported in [RFC7752].
9. Acknowledgements 9. References
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 for improving 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.
10. References
10.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752, Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016, DOI 10.17487/RFC7752, March 2016,
skipping to change at page 13, line 11 skipping to change at line 581
J., and J. Drake, "OSPF Application-Specific Link J., and J. Drake, "OSPF Application-Specific Link
Attributes", RFC 8920, DOI 10.17487/RFC8920, October 2020, Attributes", RFC 8920, DOI 10.17487/RFC8920, October 2020,
<https://www.rfc-editor.org/info/rfc8920>. <https://www.rfc-editor.org/info/rfc8920>.
[RFC9104] Tantsura, J., Wang, Z., Wu, Q., and K. Talaulikar, [RFC9104] Tantsura, J., Wang, Z., Wu, Q., and K. Talaulikar,
"Distribution of Traffic Engineering Extended "Distribution of Traffic Engineering Extended
Administrative Groups Using the Border Gateway Protocol - Administrative Groups Using the Border Gateway Protocol -
Link State (BGP-LS)", RFC 9104, DOI 10.17487/RFC9104, Link State (BGP-LS)", RFC 9104, DOI 10.17487/RFC9104,
August 2021, <https://www.rfc-editor.org/info/rfc9104>. August 2021, <https://www.rfc-editor.org/info/rfc9104>.
10.2. Informative References 9.2. Informative References
[I-D.ietf-idr-bgp-model] [IDR-BGP-MODEL]
Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP
YANG Model for Service Provider Networks", draft-ietf-idr- YANG Model for Service Provider Networks", Work in
bgp-model-14 (work in progress), July 2022. 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 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, DOI 10.17487/RFC1195, dual environments", RFC 1195, DOI 10.17487/RFC1195,
December 1990, <https://www.rfc-editor.org/info/rfc1195>. December 1990, <https://www.rfc-editor.org/info/rfc1195>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998, DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>. <https://www.rfc-editor.org/info/rfc2328>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
skipping to change at page 14, line 5 skipping to change at line 622
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>. <https://www.rfc-editor.org/info/rfc5340>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/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 Authors' Addresses
Ketan Talaulikar (editor) Ketan Talaulikar (editor)
Arrcus Inc Arrcus Inc.
India India
Email: ketant.ietf@gmail.com Email: ketant.ietf@gmail.com
Peter Psenak Peter Psenak
Cisco Systems Cisco Systems
Slovakia Slovakia
Email: ppsenak@cisco.com Email: ppsenak@cisco.com
Jeff Tantsura Jeff Tantsura
Microsoft Microsoft
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
 End of changes. 74 change blocks. 
216 lines changed or deleted 227 lines changed or added

This html diff was produced by rfcdiff 1.48.