draft-ietf-idr-bgp-ls-app-specific-attr-02.txt   draft-ietf-idr-bgp-ls-app-specific-attr-03.txt 
Inter-Domain Routing K. Talaulikar Inter-Domain Routing K. Talaulikar
Internet-Draft P. Psenak Internet-Draft P. Psenak
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: November 19, 2020 J. Tantsura Expires: January 26, 2021 J. Tantsura
Apstra Apstra
May 18, 2020 July 25, 2020
Application Specific Attributes Advertisement with BGP Link-State Application-Specific Attributes Advertisement with BGP Link-State
draft-ietf-idr-bgp-ls-app-specific-attr-02 draft-ietf-idr-bgp-ls-app-specific-attr-03
Abstract Abstract
Various link attributes have been defined in link-state routing Various link attributes have been defined in link-state routing
protocols like OSPF and IS-IS in the context of the MPLS Traffic protocols like OSPF and IS-IS in the context of the MPLS Traffic
Engineering (TE) and GMPLS. BGP Link-State (BGP-LS) extensions have Engineering (TE) and GMPLS. BGP Link-State (BGP-LS) extensions have
been defined to distribute these attributes along with other topology been defined to distribute these attributes along with other topology
information from these link-state routing protocols. Many of these information from these link-state routing protocols. Many of these
link attributes can be used for applications other than MPLS TE or link attributes can be used for applications other than MPLS-TE or
GMPLS. GMPLS.
Extensions to link-state routing protocols have been defined for such Extensions to link-state routing protocols have been defined for such
link attributes which enable distribution of their application link attributes that enable distribution of their application-
specific values. This document defines extensions to BGP-LS address- specific values. This document defines extensions to BGP-LS address-
family to enable advertisement of these application specific family to enable advertisement of these application-specific
attributes as a part of the topology information from the network. 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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 19, 2020. This Internet-Draft will expire on January 26, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
skipping to change at page 2, line 43 skipping to change at page 2, line 43
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
Various link attributes have been defined in link-state routing Various link attributes have been defined in link-state routing
protocols (viz. IS-IS [RFC1195], OSPFv2 [RFC2328] and OSPFv3 protocols (viz., IS-IS [RFC1195], OSPFv2 [RFC2328] and OSPFv3
[RFC5340] ) in the context of the MPLS traffic engineering and GMPLS. [RFC5340] ) in the context of the MPLS traffic engineering and GMPLS.
All these attributes are distributed by these protocols using TLVs All these attributes are distributed by these protocols using TLVs
that were originally defined for traditional MPLS Traffic Engineering that were originally defined for traditional MPLS Traffic Engineering
(i.e. using RSVP-TE [RFC3209]) or GMPLS [RFC4202] applications. (i.e., using RSVP-TE [RFC3209]) or GMPLS [RFC4202] applications.
In recent years new applications have been introduced which have use In recent years new applications have been introduced that have use
cases for many of the link attributes historically used by RSVP-TE cases for many of the link attributes historically used by RSVP-TE
and GMPLS. Such applications include Segment Routing (SR) [RFC8402] and GMPLS. Such applications include Segment Routing (SR) [RFC8402]
and Loop Free Alternates (LFA) [RFC5286]. This has introduced and Loop Free Alternates (LFA) [RFC5286]. This has introduced
ambiguity in that if a deployment includes a mix of RSVP-TE support ambiguity in that if a deployment includes a mix of RSVP-TE support
and SR support (for example) it is not possible to unambiguously and SR support (for example) it is not possible to unambiguously
indicate which advertisements are to be used by RSVP-TE and which indicate which advertisements are to be used by RSVP-TE and which
advertisements are to be used by SR. If the topologies are fully advertisements are to be used by SR. If the topologies are fully
congruent this may not be an issue, but any incongruence leads to congruent this may not be an issue, but any incongruence leads to
ambiguity. An additional issue arises in cases where both ambiguity. An additional issue arises in cases where both
applications are supported on a link but the link attribute values applications are supported on a link but the link attribute values
associated with each application differ. Current advertisements do associated with each application differ. Current advertisements do
not support advertising application specific values for the same not support advertising application-specific values for the same
attribute on a specific link. IGP Flexible Algorithm attribute on a specific link. IGP Flexible Algorithm
[I-D.ietf-lsr-flex-algo] is one such application use-case that MAY [I-D.ietf-lsr-flex-algo] is one such application use case that MAY
use application specific link attributes. use application-specific link attributes.
[I-D.ietf-ospf-te-link-attr-reuse] and [I-D.ietf-isis-te-app] define [I-D.ietf-ospf-te-link-attr-reuse] and [I-D.ietf-isis-te-app] define
extensions for OSPF and IS-IS respectively which address these extensions for OSPF and IS-IS respectively that address these issues.
issues. Also, as evolution of use cases for link attributes can be Also, as evolution of use cases for link attributes can be expected
expected to continue in the years to come, these documents define a to continue in the years to come, these documents define a solution
solution which is easily extensible to the introduction of new that is easily extensible to the introduction of new applications and
applications and new use cases. new use cases.
BGP Link-State extensions [RFC7752] have been specified to enable BGP Link-State extensions [RFC7752] have been specified to enable
distribution of the link-state topology information from the IGPs to distribution of the link-state topology information from the IGPs to
an application like a controller or Path Computation Engine (PCE) via an application like a controller or Path Computation Engine (PCE) via
BGP. The controller/PCE gets the end to end topology information BGP. The controller/PCE gets the end-to-end topology information
across IGP domains so it can perform path computations for use-cases across IGP domains so it can perform path computations for use cases
like end to end traffic engineering (TE) using RSVP-TE or SR based like end-to-end traffic engineering (TE) using RSVP-TE or SR-based
mechanisms. A similar challenge to what was describe above is hence mechanisms. A similar challenge to what was described above is hence
also faced by such centralized computation entities. also faced by such centralized computation entities.
There is thus a need for BGP-LS extensions to also report link There is thus a need for BGP-LS extensions to also report link
attributes on a per application basis on the same lines as introduced attributes on a per-application basis on the same lines as introduced
in the link-state routing protocols. This document defines these in the link-state routing protocols. This document defines these
BGP-LS extensions and also covers the backward compatibility issues BGP-LS extensions and also covers the backward compatibility issues
related to existing BGP-LS deployments. related to existing BGP-LS deployments.
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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 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 NLRI for advertisement of The BGP-LS [RFC7752] specifies the Link NLRI for advertisement of
links and their attributes using the BGP-LS Attribute. The links and their attributes using the BGP-LS Attribute. The
Application Specific Link Attributes (ASLA) TLV is a new optional Application-Specific Link Attributes (ASLA) TLV is a new optional
top-level BGP-LS Attribute TLV that is introduced for Link NLRIs. It 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 is defined such that it may act as a container for certain existing
and future link attributes that require to be defined in an and future link attributes that require application-specific
application specific scope. 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 corresponding ASLA sub-TLVs defined for OSPF and IS-IS in
[I-D.ietf-ospf-te-link-attr-reuse] and [I-D.ietf-isis-te-app] [I-D.ietf-ospf-te-link-attr-reuse] and [I-D.ietf-isis-te-app]
respectively. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SABML | UDABML | Reserved | | SABML | UDABML | 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 o Type: 1122
o Length: variable. o Length: variable.
o SABML : Standard Application Identifier Bit Mask Length in octets. o SABML : Standard Application Identifier Bit Mask Length in octets.
The values MUST be 0, 4 or 8. If the Standard Application The values MUST be 0, 4, or 8. If the Standard Application
Identifier Bit Mask is not present, the SABML MUST be set to 0. Identifier Bit Mask is not present, the SABML MUST be set to 0.
o UDABML : User Defined Application Identifier Bit Mask Length in o UDABML : User-Defined Application Identifier Bit Mask Length in
octets. The values MUST be 0, 4 or 8. If the User Defined octets. The values MUST be 0, 4, or 8. If the User-Defined
Application Identifier Bit-Mask is not present, the UDABML MUST be Application Identifier Bit Mask is not present, the UDABML MUST be
set to 0. set to 0.
o Standard Application Identifier Bit-Mask : of size 0, 4 or 8 o Standard Application Identifier Bit Mask : of size 0, 4, or 8
octets as indicated by SABML. Optional set of bits, where each octets as indicated by the SABML. Optional set of bits, where
bit represents a single standard application. The bits are each bit represents a single standard application. The bits are
defined in the IANA "IGP Parameters" registries under the "Link defined in the IANA "IGP Parameters" registries under the "Link
Attribute Applications" registry [I-D.ietf-isis-te-app]. Attribute Applications" registry [I-D.ietf-isis-te-app].
o User Defined Application Identifier Bit-Mask : of size 0, 4 or 8 o User-Defined Application Identifier Bit Mask : of size 0, 4, or 8
octets as indicated by UDABML. Optional set of bits, where each octets as indicated by the UDABML. Optional set of bits, where
bit represents a single user defined application. The bits are each bit represents a single user-defined application. The bits
not managed or assigned by IANA or any other standards body and are not managed or assigned by IANA or any other standards body
are left to implementation specifics. and definition is left to the implementation.
o sub-TLVs : BGP-LS Attribute TLVs corresponding to the Link NLRI o sub-TLVs : BGP-LS Attribute TLVs corresponding to the Link NLRI
that are application specific (as specified in Section 3) are that are application-specific (as specified in Section 3) are
included as sub-TLVs of the ASLA TLV included as sub-TLVs of the ASLA TLV.
An ASLA TLV with both the SABML and UDABML set to 0 (i.e. without any An ASLA TLV with both the SABML and UDABML set to 0 (i.e. without any
application identifier bitmasks) indicates that the link attribute application identifier bit masks) indicates that the link attribute
sub-TLVs that it encloses are applicable for all applications. sub-TLVs that it encloses are applicable for all applications.
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/sub-TLVs. The procedures for
originating link attributes in the ASLA TLV from underlying IGPs is originating link attributes in the ASLA TLV from underlying IGPs are
specified in Section 4. specified in Section 4.
When the node is not running any of the IGPs but running a protocol When the node is not running any of the IGPs but running a protocol
like BGP, then the link attributes for the node's local links MAY be like BGP, then the link attributes for the node's local links MAY be
originated as part of the BGP-LS Attribute using the ASLA TLV and its originated as part of the BGP-LS Attribute using the ASLA TLV and its
sub-TLVs within the Link NLRI corresponding to the local node. sub-TLVs within the Link NLRI corresponding to the local node.
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. The following defined in BGP-LS and more may be added in the future. The following
types of link attributes are required to be considered as application types of link attributes are required to be considered as application
specific. specific.
o those that have different values for different applications (e.g. o those that have different values for different applications (e.g.,
a different TE metric value used for RSVP-TE than for SR TE) a different TE metric value used for RSVP-TE than for SR TE)
o those that are applicable to multiple applications but need to be o those that are applicable to multiple applications but need to be
used only by specific application (e.g. certain SRLG values are used only by specific application (e.g., certain SRLG values are
configured on a node for LFA but the same do not need to be used configured on a node for LFA but the same do not need to be used
for RSVP-TE) for RSVP-TE)
The following table lists the currently defined BGP-LS Attributes The following table lists the currently defined BGP-LS Attributes
TLVs corresponding to Link NLRI which have application specific TLVs corresponding to Link NLRI that have application-specific
semantics. They were originally defined with semantics for RSVP-TE semantics. They were originally defined with semantics for RSVP-TE
and GMPLS applications. and GMPLS applications.
+----------+----------------------+---------------------------------+ +----------+----------------------+---------------------------------+
| TLV Code | Description | Reference Document | | TLV Code | Description | Reference Document |
| Point | | | | Point | | |
+----------+----------------------+---------------------------------+ +----------+----------------------+---------------------------------+
| 1088 | Administrative group | [RFC7752] | | 1088 | Administrative group | [RFC7752] |
| | (color) | | | | (color) | |
| 1092 | TE Metric | [RFC7752] | | 1092 | TE Metric | [RFC7752] |
skipping to change at page 6, line 37 skipping to change at page 6, line 37
| | bandwidth | | | | bandwidth | |
| | utilization | | | | utilization | |
| 1173 | Extended | [I-D.ietf-idr-eag-distribution] | | 1173 | Extended | [I-D.ietf-idr-eag-distribution] |
| | Administrative group | | | | Administrative group | |
| | (color) | | | | (color) | |
+----------+----------------------+---------------------------------+ +----------+----------------------+---------------------------------+
Table 1: BGP-LS Attribute TLVs also used as sub-TLVs of ASLA TLV Table 1: BGP-LS Attribute TLVs also used as sub-TLVs of ASLA TLV
All the BGP-LS Attribute TLVs defined in the table above are All the BGP-LS Attribute TLVs defined in the table above are
RECOMMENDED to be continued to be used at the top-level in the BGP-LS RECOMMENDED to continue to be advertised at the top-level in the BGP-
Attribute for carrying attributes specific to RSVP-TE without the use LS Attribute for carrying attributes specific to RSVP-TE without the
of the ASLA TLV. use of the ASLA TLV.
When a new link attribute is introduced, it may be thought of as When a new link attribute is introduced, it may be thought of as
being specific to only a single application. However, down the line, being specific to only a single application. However, subsequently,
it may be also shared by other applications and/or require it may be also shared by other applications and/or require
application specific values. In such cases, it is RECOMMENDED to err application-specific values. In such cases, it is RECOMMENDED to err
on the side of caution and define such attributes as application on the side of caution and define such attributes as application-
specific to ensure flexibility in the future. specific to ensure flexibility in the future.
BGP-LS Attribute TLVs corresponding to Link NLRI that are defined in BGP-LS Attribute TLVs corresponding to Link NLRI that are defined in
the future MUST specify if they are application specific and hence the future MUST specify if they are application-specific and hence
are REQUIRED to be encoded within an ASLA TLV. are REQUIRED to be encoded within an ASLA TLV.
Only application specific link attributes need to be advertised Only application-specific link attributes need to be advertised
within the ASLA TLV. Link attributes which do not have application within the ASLA TLV. Link attributes that do not have application-
specific semantics SHOULD NOT be advertised within the ASLA TLV. specific semantics SHOULD NOT be advertised within the ASLA TLV.
Receivers SHOULD ignore any non-application specific attribute sub- Receivers SHOULD ignore any non-application-specific attribute sub-
TLVs within the ASLA TLV. TLVs within the ASLA TLV.
4. Procedures 4. Procedures
The procedures described in this section apply to networks where all The procedures described in this section apply to networks where all
BGP-LS originators and consumers support this specification. The BGP-LS originators and consumers support this specification. The
backward compatibility aspects and operations in deployments where backward compatibility aspects and operations in deployments where
there are some BGP-LS originators or consumers that do not support there are some BGP-LS originators or consumers that do not support
this specification is described further in Section 6. this specification are described further in Section 6.
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 set of applications from either the specific attribute to one or more applications from either the
underlying IGP protocol LSA/LSPs from which it is sourcing the underlying IGP protocol LSA/LSPs from which it is advertising the
topology information or from the local node configuration when topology information or from the local node configuration when
advertising attributes for the local node only. advertising attributes for the local node only.
The association of an application specific link attribute with a The association of an application-specific link attribute with a
specific application context when advertising attributes for the specific application context when advertising attributes for the
local node only (e.g. when running BGP as the only routing protocol) local node only (e.g., when running BGP as the only routing protocol)
is an implementation specific matter and outside the scope of this is an implementation specific matter and outside the scope of this
document. document.
[I-D.ietf-ospf-te-link-attr-reuse] and [I-D.ietf-isis-te-app] specify [I-D.ietf-ospf-te-link-attr-reuse] and [I-D.ietf-isis-te-app] specify
the mechanisms for flooding of application specific link attributes the mechanisms for advertising application-specific link attributes
in OSPFv2/v3 and IS-IS respectively. These IGP specifications also in OSPFv2/v3 and IS-IS respectively. These IGP specifications also
describe the backward compatibility aspects and the existing RSVP-TE/ describe the backward compatibility aspects and the existing RSVP-TE/
GMPLS specific TLV encoding mechanisms in respective protocols. GMPLS specific TLV encoding mechanisms in the respective protocols.
A BGP-LS originator node which is sourcing link-state information A BGP-LS originator node that is advertising link-state information
from the underlying IGP determines the mechanism of flooding from the underlying IGP determines the protocol encoding of
application specific link attributes based on the following rules: application-specific link attributes based on the following rules:
1. Application specific link attributes received from an IGP node 1. Application-specific link attributes received from an IGP node
using existing RSVP-TE/GMPLS encodings MUST be encoded using the using existing RSVP-TE/GMPLS encodings MUST be encoded using the
respective BGP-LS top-level TLVs listed in Table 1. respective BGP-LS top-level TLVs listed in Table 1.
2. Application specific link attributes received from an IGP node 2. Application-specific link attributes received from an IGP node
using ASLA sub-TLV MUST be encoded in the BGP-LS ASLA TLV as sub- using ASLA sub-TLV MUST be encoded in the BGP-LS ASLA TLV as sub-
TLVs. TLVs.
3. In case of IS-IS, the following specific procedures are to be 3. In case of IS-IS, the following specific procedures are to be
followed: followed:
* When application specific link attributes are received from a * When application-specific link attributes are received from a
node with the L bit set in the ASLA sub-TLV AND application node with the L bit set in the ASLA sub-TLV AND application
bits other than RSVP-TE are set in the application bitmasks bits other than RSVP-TE are set in the application bit masks
then the application specific link attributes advertised in then the application-specific link attributes advertised in
the corresponding legacy IS-IS TLVs/sub-TLVs MUST be encoded the corresponding legacy IS-IS TLVs/sub-TLVs MUST be encoded
within the BGP-LS ASLA TLV as sub-TLVs with the application 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 bits, other than the RSVP-TE bit, copied from the IS-IS ASLA
sub-TLV. The link attributes advertised in the legacy IS-IS sub-TLV. The link attributes advertised in the legacy IS-IS
TLVs/sub-TLVs are also advertised in BGP-LS top-level TLVs TLVs/sub-TLVs are also advertised in BGP-LS top-level TLVs
listed in Table 1. Note this is true regardless of whether listed in Table 1. Note that this is true regardless of
the RSVP-TE bit was set in the IS-IS ASLA TLV/sub-TLV. whether the RSVP-TE bit was set in the IS-IS ASLA TLV/sub-TLV.
* When the ASLA sub-TLV has the RSVP-TE application bit set then * When the ASLA sub-TLV has the RSVP-TE application bit set,
the link attributes from such an ASLA sub-TLV MUST be encoded then the link attributes for the corresponding ASLA sub-TLV
using the respective BGP-LS top-level TLVs listed in Table 1. MUST be encoded using the respective BGP-LS top-level TLVs
listed in Table 1.
* [I-D.ietf-isis-te-app] allows the advertisement of the Maximum * [I-D.ietf-isis-te-app] allows the advertisement of the Maximum
Link Bandwidth within an ASLA sub-TLV even though it is not an Link Bandwidth within an ASLA sub-TLV even though it is not an
application specific attribute. However, when originating the application-specific attribute. However, when originating the
Maximum Link Bandwidth into BGP-LS, the attribute MUST be Maximum Link Bandwidth into BGP-LS, the attribute MUST be
encoded only in the top-level Maximum Link Bandwidth TLV 1089 encoded only in the top-level BGP-LS Maximum Link Bandwidth
of BGP-LS and not within the BGP-LS ASLA TLV. TLV (1089) and not within the BGP-LS ASLA TLV.
* [I-D.ietf-isis-te-app] also allows the advertisement of the * [I-D.ietf-isis-te-app] also allows the advertisement of the
Maximum Reservable Link Bandwidth and the Unreserved Bandwidth Maximum Reservable Link Bandwidth and the Unreserved Bandwidth
within an ASLA sub-TLV even though these attributes are within an 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 Bandwidth the Maximum Reservable Link Bandwidth and Unreserved Bandwidth
into BGP-LS, these attribute MUST be encoded only in the top- into BGP-LS, these attributes MUST be encoded only in the BGP-
level Maximum Reservable Link Bandwidth TLV 1090 and LS top-level Maximum Reservable Link Bandwidth TLV (1090) and
Unreserved Bandwidth TLV 1091 respectively of BGP-LS and not Unreserved Bandwidth TLV (1091) respectively and not within
within the BGP-LS ASLA TLV. 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 or do not support the ASLA extension. IGP nodes that support or do not support the ASLA extension.
Furthermore, it also ensures that the top-level BGP-LS TLVs defined Furthermore, it also ensures that the top-level BGP-LS TLVs defined
for RSVP-TE and GMPLS applications continue to be used for for RSVP-TE and GMPLS applications continue to be used for
advertisement of their application specific attributes. advertisement of their application-specific attributes.
A BGP-LS consumer node would normally get all application specific A BGP-LS consumer node would normally receive all the application-
link attributes corresponding to RSVP-TE and GMPLS applications as specific link attributes corresponding to RSVP-TE and GMPLS
existing top-level BGP-LS TLVs while for other applications they are applications as existing top-level BGP-LS TLVs while for other
encoded in ASLA TLV(s) with appropriate applicable bit mask setting. applications they are encoded in ASLA TLV(s) with appropriate
A BGP-LS consumer which implements this specification SHOULD prefer applicable bit mask setting. A BGP-LS consumer that implements this
the application specific attribute value received via sub-TLVs within specification SHOULD prefer the application-specific attribute value
the ASLA TLV over the value received via the top level TLVs. received via sub-TLVs within the ASLA TLV over the value received via
the top level TLVs.
5. Deployment Considerations 5. Deployment Considerations
SR-TE and LFA applications have been deployed in some networks using SR-TE and LFA applications have been deployed in some networks using
the IGP link attributes defined originally for RSVP-TE as discussed the IGP link attributes defined originally for RSVP-TE as discussed
in [I-D.ietf-ospf-te-link-attr-reuse] and [I-D.ietf-isis-te-app]. in [I-D.ietf-ospf-te-link-attr-reuse] and [I-D.ietf-isis-te-app].
The corresponding BGP-LS top-level link attribute TLVs originally The corresponding BGP-LS top-level link attribute TLVs originally
defined for RSVP-TE have also been similarly used for SR-TE and LFA defined for RSVP-TE have also been similarly used for SR-TE and LFA
applications by BGP-LS consumers. Such usage MAY continue without applications by BGP-LS consumers. Such usage MAY continue without
requiring the support of the application specific link attribute requiring the support of the application-specific link attribute
encoding mechanism described in this document as long as the encodings described in this document as long as the following
following conditions are met: conditions are met:
o The application is SRTE or LFA and RSVP-TE is not deployed o The application is SRTE or LFA and RSVP-TE is not deployed
anywhere in the network anywhere in the network
o The application is SRTE or LFA, RSVP-TE is deployed in the o The application is SRTE or LFA, RSVP-TE is deployed in the
network, and both the set of links on which SRTE and/or LFA network, and both the set of links on which SRTE and/or LFA
advertisements are required and the attribute values used by SRTE advertisements are required and the attribute values used by SRTE
and/or LFA on all such links is fully congruent with the links and and/or LFA on all such links is fully congruent with the links and
attribute values used by RSVP-TE attribute values used by RSVP-TE
6. Backward Compatibility 6. Backward Compatibility
The backward compatibility aspects for BGP-LS are associated with the The backward compatibility aspects for BGP-LS are associated with the
originators (i.e. nodes) and consumers (e.g. PCE, controllers, originators (i.e., nodes) and consumers (e.g., PCE, controllers,
applications, etc.) of the topology information. BGP-LS applications, etc.) of the topology information. BGP-LS
implementations have been originating link attributes and consuming implementations have been originating link attributes and consuming
them without any application specific scoping prior to the extensions them without any application-specific scoping prior to the extensions
specified in this document. specified in this document.
IGP backwards compatibility aspects associated with application IGP backwards compatibility aspects associated with application-
specific link attributes for RSVP-TE, SRTE and LFA applications are specific link attributes for RSVP-TE, SRTE and LFA applications are
discussed in the Backward Compatibility sections of discussed in the Backward Compatibility sections of
[I-D.ietf-ospf-te-link-attr-reuse] and [I-D.ietf-isis-te-app]. [I-D.ietf-ospf-te-link-attr-reuse] and [I-D.ietf-isis-te-app]. While
Although the backwards compatibility aspects ensure compatibility of the backwards compatibility aspects ensure compatibility of IGP
IGP advertisements they also serve to ensure the backward advertisements, they also serve to ensure the backward compatibility
compatibility of the BGP-LS advertisements used by BGP-LS consumers. of the BGP-LS advertisements used by BGP-LS consumers. In
In deployments where the BGP-LS originators or consumers do not deployments where the BGP-LS originators or consumers do not support
support the extensions specified in this document, the IGPs need to the extensions specified in this document, the IGPs need to continue
continue to advertise link attributes intended for use by SRTE and to advertise link attributes intended for use by SRTE and LFA
LFA applications using the RSVP-TE/GMPLS encodings. This allows BGP- applications using the RSVP-TE/GMPLS encodings. This allows BGP-LS
LS advertisements to be consistent with the behaviour prior to the advertisements to be consistent with the behavior prior to the
extensions defined in this document extensions defined in this document
It is RECOMMENDED that nodes that support this specification are
It is RECOMMENDED that the nodes which support this specification are selected as originators of BGP-LS information when advertising the
selected as originators of BGP-LS information when sourcing the link- link-state information from the IGPs.
state information from the IGPs.
7. IANA Considerations 7. IANA Considerations
This document requests assigning code-points from the registry "BGP- This document requests assignment of code-points from the registry
LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and
TLVs" based on table below which reflects the values assigned via the Attribute TLVs" based on table below which reflects the values
early allocation process. The column "IS-IS TLV/Sub-TLV" defined in assigned via the early allocation process. The column "IS-IS TLV/
the registry does not require any value and should be left empty. Sub-TLV" defined in the registry does not require any value and
should be left empty.
+------------+------------------------------------------+----------+ +------------+------------------------------------------+----------+
| Code Point | Description | Length | | Code Point | Description | Length |
+------------+------------------------------------------+----------+ +------------+------------------------------------------+----------+
| 1122 | Application Specific Link Attributes TLV | variable | | 1122 | Application-Specific Link Attributes TLV | variable |
+------------+------------------------------------------+----------+ +------------+------------------------------------------+----------+
8. Manageability Considerations 8. Manageability Considerations
This section is structured as recommended in [RFC5706]. This section is structured as recommended in [RFC5706].
The new protocol extensions introduced in this document augment the The new protocol extensions introduced in this document augment the
existing IGP topology information that was distributed via [RFC7752]. existing IGP topology information defined in [RFC7752]. Procedures
Procedures and protocol extensions defined in this document do not and protocol extensions defined in this document do not affect the
affect the BGP protocol operations and management other than as BGP protocol operations and management other than as discussed in the
discussed in the Manageability Considerations section of [RFC7752]. Manageability Considerations section of [RFC7752]. Specifically, the
Specifically, the malformed NLRIs attribute tests in the Fault malformed NLRIs attribute tests in the Fault Management section of
Management section of [RFC7752] now encompass the new TLVs for the [RFC7752] now encompass the BGP-LS TLVs defined in this document.
BGP-LS NLRI in this document.
8.1. Operational Considerations 8.1. Operational Considerations
No additional operation considerations are defined in this document. No additional operation considerations are defined in this document.
8.2. Management Considerations 8.2. Management Considerations
No additional management considerations are defined in this document. No additional management considerations are defined in this document.
9. Security Considerations 9. Security Considerations
The new protocol extensions introduced in this document augment the The new protocol extensions introduced in this document augment the
existing IGP topology information that was distributed via [RFC7752]. existing IGP topology information defined in [RFC7752]. Procedures
Procedures and protocol extensions defined in this document do not and protocol extensions defined in this document do not affect the
affect the BGP security model other than as discussed in the Security BGP security model other than as discussed in the Security
Considerations section of [RFC7752]. Considerations section of [RFC7752].
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Les Ginsberg, Baalajee S and Amalesh The authors would like to thank Les Ginsberg, Baalajee S, Amalesh
Maity for their review and feedback on this document. Maity, and Acee Lindem for their review and feedback on this
document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-isis-te-app] [I-D.ietf-isis-te-app]
Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and
J. Drake, "IS-IS TE Attributes per application", draft- J. Drake, "IS-IS Application-Specific Link Attributes",
ietf-isis-te-app-12 (work in progress), March 2020. draft-ietf-isis-te-app-19 (work in progress), June 2020.
[I-D.ietf-ospf-te-link-attr-reuse] [I-D.ietf-ospf-te-link-attr-reuse]
Psenak, P., Ginsberg, L., Henderickx, W., Tantsura, J., Psenak, P., Ginsberg, L., Henderickx, W., Tantsura, J.,
and J. Drake, "OSPF Link Traffic Engineering Attribute and J. Drake, "OSPF Application-Specific Link Attributes",
Reuse", draft-ietf-ospf-te-link-attr-reuse-11 (work in draft-ietf-ospf-te-link-attr-reuse-16 (work in progress),
progress), May 2020. June 2020.
[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 11, line 51 skipping to change at page 11, line 52
[I-D.ietf-idr-eag-distribution] [I-D.ietf-idr-eag-distribution]
Wang, Z., WU, Q., Tantsura, J., and K. Talaulikar, Wang, Z., WU, Q., Tantsura, J., and K. Talaulikar,
"Distribution of Traffic Engineering Extended Admin Groups "Distribution of Traffic Engineering Extended Admin Groups
using BGP-LS", draft-ietf-idr-eag-distribution-12 (work in using BGP-LS", draft-ietf-idr-eag-distribution-12 (work in
progress), May 2020. progress), May 2020.
[I-D.ietf-lsr-flex-algo] [I-D.ietf-lsr-flex-algo]
Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex-
algo-07 (work in progress), April 2020. algo-08 (work in progress), July 2020.
[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 13, line 6 skipping to change at page 13, line 6
[RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and
C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of
IGP Traffic Engineering Performance Metric Extensions", IGP Traffic Engineering Performance Metric Extensions",
RFC 8571, DOI 10.17487/RFC8571, March 2019, RFC 8571, DOI 10.17487/RFC8571, March 2019,
<https://www.rfc-editor.org/info/rfc8571>. <https://www.rfc-editor.org/info/rfc8571>.
Authors' Addresses Authors' Addresses
Ketan Talaulikar Ketan Talaulikar
Cisco Systems Cisco Systems
India
Email: ketant@cisco.com Email: ketant@cisco.com
Peter Psenak Peter Psenak
Cisco Systems Cisco Systems
Slovakia Slovakia
Email: ppsenak@cisco.com Email: ppsenak@cisco.com
Jeff Tantsura Jeff Tantsura
 End of changes. 69 change blocks. 
138 lines changed or deleted 141 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/