draft-ietf-idr-bgp-ls-app-specific-attr-00.txt   draft-ietf-idr-bgp-ls-app-specific-attr-01.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: December 1, 2019 J. Tantsura Expires: May 19, 2020 J. Tantsura
Apstra Apstra
May 30, 2019 November 16, 2019
Application Specific Attributes Advertisement with BGP Link-State Application Specific Attributes Advertisement with BGP Link-State
draft-ietf-idr-bgp-ls-app-specific-attr-00 draft-ietf-idr-bgp-ls-app-specific-attr-01
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.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 December 1, 2019. This Internet-Draft will expire on May 19, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 30 skipping to change at page 2, line 30
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Application Specific Link Attributes TLV . . . . . . . . . . 3 2. Application Specific Link Attributes TLV . . . . . . . . . . 3
3. Application Specific Link Attributes . . . . . . . . . . . . 5 3. Application Specific Link Attributes . . . . . . . . . . . . 5
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 8 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 9
7. Manageability Considerations . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7.1. Operational Considerations . . . . . . . . . . . . . . . 10 8. Manageability Considerations . . . . . . . . . . . . . . . . 10
7.2. Management Considerations . . . . . . . . . . . . . . . . 10 8.1. Operational Considerations . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8.2. Management Considerations . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 11 11.1. Normative 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.
skipping to change at page 4, line 28 skipping to change at page 4, line 28
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User Defined Application Bit-Mask (variable) // | User Defined Application 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: TBD (see IANA Considerations Section 6) o Type: 1122
o Length: variable. o Length: variable.
o SABML : 1 octet value carrying the Standard Application Bit-Mask o SABML : 1 octet value carrying the Standard Application Bit-Mask
Length in multiples of 4 octets. If the Standard Application Bit- Length in multiples of 4 octets. If the Standard Application Bit-
Mask is not present, the SABML MUST be set to 0. Mask is not present, the SABML MUST be set to 0.
o UDABML : 1 octet value carrying the User Defined Application Bit- o UDABML : 1 octet value carrying the User Defined Application Bit-
Mask Length in multiples of 4 octets. If the User Defined Mask Length in multiples of 4 octets. If the User Defined
Application Bit-Mask is not present, the UDABML MUST be set to 0. Application Bit-Mask is not present, the UDABML MUST be set to 0.
skipping to change at page 6, line 11 skipping to change at page 6, line 11
TLVs corresponding to Link NLRI which have application specific TLVs corresponding to Link NLRI which 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) | |
| 1090 | Max Reservable | [RFC7752] |
| | Bandwidth | |
| 1091 | Unreserved Bandwidth | [RFC7752] |
| 1092 | TE Metric | [RFC7752] | | 1092 | TE Metric | [RFC7752] |
| 1096 | SRLG | [RFC7752] | | 1096 | SRLG | [RFC7752] |
| 1114 | Unidirectional link | [I-D.ietf-idr-te-pm-bgp] | | 1114 | Unidirectional link | [RFC8571] |
| | delay | | | | delay | |
| 1115 | Min/Max | [I-D.ietf-idr-te-pm-bgp] | | 1115 | Min/Max | [RFC8571] |
| | Unidirectional link | | | | Unidirectional link | |
| | delay | | | | delay | |
| 1116 | Unidirectional link | [I-D.ietf-idr-te-pm-bgp] | | 1116 | Unidirectional link | [RFC8571] |
| | delay variation | | | | delay variation | |
| 1117 | Unidirectional | [I-D.ietf-idr-te-pm-bgp] | | 1117 | Unidirectional | [RFC8571] |
| | packet loss | | | | packet loss | |
| 1118 | Unidirectional | [I-D.ietf-idr-te-pm-bgp] | | 1118 | Unidirectional | [RFC8571] |
| | residual bandwidth | | | | residual bandwidth | |
| 1119 | Unidirectional | [I-D.ietf-idr-te-pm-bgp] | | 1119 | Unidirectional | [RFC8571] |
| | available bandwidth | | | | available bandwidth | |
| 1120 | Unidirectional | [I-D.ietf-idr-te-pm-bgp] | | 1120 | Unidirectional | [RFC8571] |
| | 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 be continued to be used at the top-level in the BGP-LS
Attribute for carrying attributes specific to RSVP-TE/GMPLS Attribute for carrying attributes specific to RSVP-TE without the use
application without the use of the ASLA TLV. 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, down the line,
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
skipping to change at page 7, line 21 skipping to change at page 7, line 17
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 5. this specification is 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 set of applications from either the
underlying IGP protocol LSA/LSPs from which it is sourcing the underlying IGP protocol LSA/LSPs from which it is sourcing 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)
skipping to change at page 7, line 46 skipping to change at page 7, line 42
the mechanisms for flooding of application specific link attributes the mechanisms for flooding of 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 respective protocols.
A BGP-LS originator node which is sourcing link-state information A BGP-LS originator node which is sourcing link-state information
from the underlying IGP determines the mechanism of flooding from the underlying IGP determines the mechanism of flooding
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 only (i.e. without any using existing RSVP-TE/GMPLS encodings MUST be encoded using the
ASLA sub-TLV) MUST be encoded using the respective BGP-LS top- respective BGP-LS top-level TLVs listed in Table 1.
level TLVs listed in Table 1 (i.e. not within ASLA TLV). When
the IGP node is also SR enabled then another copy of application
specific link attributes SHOULD be also encoded as ASLA sub-TLVs
with the SR application bit for them. Further rules do not apply
for such IGP nodes that do not use ASLA sub-TLVs in their
advertisements.
2. In case of IS-IS, when application specific link attributes are 2. Application specific link attributes received from an IGP node
received from a node with the L bit set in the ASLA sub-TLV then using ASLA sub-TLV MUST be encoded in the BGP-LS ASLA TLV as sub-
the application specific link attributes are picked up from the TLVs.
legacy ISIS TLVs/sub-TLVs and MUST be encoded within the BGP-LS
ASLA TLV as sub-TLVs with the application bitmask set as per the
IGP ASLA sub-TLV. When the ASLA sub-TLV with the L bit set also
has the RSVP-TE application bit set then the link attributes from
such an ASLA sub-TLV MUST be also encoded using the respective
BGP-LS top-level TLVs listed in Table 1 (i.e. not within ASLA
TLV).
3. In case of OSPFv2/v3, when application specific link attributes 3. In case of IS-IS, the following specific procedures are to be
are received from a node via TE LSAs then the application followed:
specific link attributes from those LSAs MUST be encoded using
the respective BGP-LS TLVs listed in Table 1 (i.e. not within
ASLA TLV).
4. Application specific link attributes received from an IGP node * When application specific link attributes are received from a
within its ASLA sub-TLV MUST be encoded in the BGP-LS ASLA TLV as node with the L bit set in the ASLA sub-TLV AND application
sub-TLVs with the application bitmask set as per the IGP bits other than RSVP-TE are set in the application bitmasks
advertisement. then the application specific link attributes advertised in
the corresponding legacy IS-IS TLVs/sub-TLVs MUST be encoded
within the BGP-LS ASLA TLV as sub-TLVs with the application
bits, other than the RSVP-TE bit, copied from the IS-IS ASLA
sub-TLV. The link attributes advertised in the legacy IS-IS
TLVs/sub-TLVs are also advertised in BGP-LS top-level TLVs
listed in Table 1. Note this is true regardless of whether
the RSVP-TE bit was set in the IS-IS ASLA TLV/sub-TLV.
These rules ensure that a BGP-LS originator performs the translation * When the ASLA sub-TLV has the RSVP-TE application bit set then
for all application specific link attributes from the IGP nodes into the link attributes from such an ASLA sub-TLV MUST be encoded
the new BGP-LS ASLA TLVs irrespective of the IGP node supporting the using the respective BGP-LS top-level TLVs listed in Table 1.
ASLA extension. Furthermore, it also ensures that BGP-LS TLVs
defined for RSVP-TE and GMPLS applications continue to be used for
those respective applications.
A BGP-LS consumer node always gets all application specific link * [I-D.ietf-isis-te-app] allows the advertisement of the Maximum
attributes corresponding to RSVP-TE and GMPLS applications as Link Bandwidth within an ASLA sub-TLV even though it is not an
application specific attribute. However, when originating the
Maximum Link Bandwidth into BGP-LS, the attribute MUST be
encoded only in the top-level Maximum Link Bandwidth TLV 1089
of BGP-LS and not within the BGP-LS ASLA TLV.
* [I-D.ietf-isis-te-app] also allows the advertisement of the
Maximum Reservable Link Bandwidth and the Unreserved Bandwidth
within an ASLA sub-TLV even though these attributes are
specific to RSVP-TE application. However, when originating
the Maximum Reservable Link Bandwidth and Unreserved Bandwidth
into BGP-LS, these attribute MUST be encoded only in the top-
level Maximum Reservable Link Bandwidth TLV 1090 and
Unreserved Bandwidth TLV 1091 respectively of BGP-LS and not
within the BGP-LS ASLA TLV.
These rules ensure that a BGP-LS originator performs the
advertisement for all application specific link attributes from the
IGP nodes that support or do not support the ASLA extension.
Furthermore, it also ensures that the top-level BGP-LS TLVs defined
for RSVP-TE and GMPLS applications continue to be used for
advertisement of their application specific attributes.
A BGP-LS consumer node would normally get all application specific
link attributes corresponding to RSVP-TE and GMPLS applications as
existing top-level BGP-LS TLVs while for other applications they are existing top-level BGP-LS TLVs while for other applications they are
encoded in ASLA TLV(s) with appropriate applicable bit mask setting. encoded in ASLA TLV(s) with appropriate applicable bit mask setting.
A BGP-LS consumer which implements this specification SHOULD prefer
the application specific attribute value received via sub-TLVs within
the ASLA TLV over the value received via the top level TLVs.
5. Backward Compatibility 5. Deployment Considerations
When it comes to BGP-LS, the backward compatibility aspects are SR-TE and LFA applications have been deployed in some networks using
associated with the originators (i.e. nodes) and consumers (e.g. the IGP link attributes defined originally for RSVP-TE as discussed
PCE, controllers, applications, etc.) of the topology information. in [I-D.ietf-ospf-te-link-attr-reuse] and [I-D.ietf-isis-te-app].
The originators of BGP-LS information need to ensure that their The corresponding BGP-LS top-level link attribute TLVs originally
encoding of application specific link attributes is done such that defined for RSVP-TE have also been similarly used for SR-TE and LFA
consumers running BGP-LS implementations without this specification applications by BGP-LS consumers. Such usage MAY continue without
support can still support existing applications like RSVP-TE and SR. requiring the support of the application specific link attribute
The consumers running BGP-LS implementations that support this encoding mechanism described in this document as long as the
specification should also be able to work with BGP-LS originators following conditions are met:
that do not support this specification and vice versa.
BGP-LS implementations have been originating link attributes and o The application is SRTE or LFA and RSVP-TE is not deployed
consuming them without any application specific scoping. While the anywhere in the network
ASLA TLV can be used without any backward compatibility
considerations for any new application (e.g. IGP Flexible Algorithm)
specific attribute advertisements, for existing applications like
RSVP-TE and SR some backward compatibility aspects need to be taken
care of.
This requires the introduction of a "compatibility mode" of o The application is SRTE or LFA, RSVP-TE is deployed in the
operations at originators of BGP-LS information for encoding of network, and both the set of links on which SRTE and/or LFA
information such that older implementations of BGP-LS consumers can advertisements are required and the attribute values used by SRTE
still support applications like RSVP-TE and SR. In addition to the and/or LFA on all such links is fully congruent with the links and
rules specified in Section 4, the following rules are to be followed attribute values used by RSVP-TE
when operating in "compatibility mode" :
o Application specific link attribute received in IGP ASLA sub-TLVs, 6. Backward Compatibility
corresponding to RSVP-TE or SR applications, MUST be also encoded
in their existing top level TLVs (as listed in Table 1) outside of
the ASLA TLV in addition to them being also advertised within the
ASLA TLV
o When the same application specific attribute, received in IGP ASLA The backward compatibility aspects for BGP-LS are associated with the
sub-TLVs, has different values for RSVP-TE and SR applications originators (i.e. nodes) and consumers (e.g. PCE, controllers,
then the value for RSVP-TE application SHOULD be preferred over applications, etc.) of the topology information. BGP-LS
the value for SR application for advertisement as the top level implementations have been originating link attributes and consuming
TLV (as listed in Table 1). An implementation MAY provide a knob them without any application specific scoping prior to the extensions
to reverse this preference. specified in this document.
It is RECOMMENDED that implementations operate in "compatibility IGP backwards compatibility aspects associated with application
mode" by default. Implementations SHOULD have a knob for turning the specific link attributes for RSVP-TE, SRTE and LFA applications are
"compatibility mode" on or off. Operators MAY turn the discussed in the Backward Compatibility sections of
"compatibility mode" off when they are assured that all BGP-LS [I-D.ietf-ospf-te-link-attr-reuse] and [I-D.ietf-isis-te-app].
consumers have been upgraded to support the extensions in this Although the backwards compatibility aspects ensure compatibility of
document. IGP advertisements they also serve to ensure the backward
compatibility of the BGP-LS advertisements used by BGP-LS consumers.
In deployments where the BGP-LS originators or consumers do not
support the extensions specified in this document, the IGPs need to
continue to advertise link attributes intended for use by SRTE and
LFA applications using the RSVP-TE/GMPLS encodings. This allows BGP-
LS advertisements to be consistent with the behaviour prior to the
extensions defined in this document
It is RECOMMENDED that the nodes which support this specification are It is RECOMMENDED that the nodes which support this specification are
selected as originators of BGP-LS information when sourced from the selected as originators of BGP-LS information when sourcing the link-
IGPs. state information from the IGPs.
A BGP-LS consumer which does not implement this specification will
ignore the ASLA TLV and instead continue to use the attributes from
the existing top level TLVs.
A BGP-LS consumer which implements this specification SHOULD prefer
the application specific attribute value received via sub-TLVs within
the ASLA TLV over the value received via the top level TLVs.
6. IANA Considerations 7. IANA Considerations
This document requests assigning code-points from the registry "BGP- This document requests assigning code-points from the registry "BGP-
LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute
TLVs" based on table below. The column "IS-IS TLV/Sub-TLV" defined TLVs" based on table below which reflects the values assigned via the
in the registry does not require any value and should be left empty. early allocation process. The column "IS-IS TLV/Sub-TLV" defined in
the registry does not require any value and should be left empty.
+------------+------------------------------------------+----------+ +------------+------------------------------------------+----------+
| Code Point | Description | Length | | Code Point | Description | Length |
+------------+------------------------------------------+----------+ +------------+------------------------------------------+----------+
| TBD | Application Specific Link Attributes TLV | variable | | 1122 | Application Specific Link Attributes TLV | variable |
+------------+------------------------------------------+----------+ +------------+------------------------------------------+----------+
7. 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 that was distributed via [RFC7752].
Procedures and protocol extensions defined in this document do not Procedures and protocol extensions defined in this document do not
affect the BGP protocol operations and management other than as affect the BGP protocol operations and management other than as
discussed in the Manageability Considerations section of [RFC7752]. discussed in the Manageability Considerations section of [RFC7752].
Specifically, the malformed NLRIs attribute tests in the Fault Specifically, the malformed NLRIs attribute tests in the Fault
Management section of [RFC7752] now encompass the new TLVs for the Management section of [RFC7752] now encompass the new TLVs for the
BGP-LS NLRI in this document. BGP-LS NLRI in this document.
7.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.
7.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.
8. 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 that was distributed via [RFC7752].
Procedures and protocol extensions defined in this document do not Procedures and protocol extensions defined in this document do not
affect the BGP security model other than as discussed in the Security affect the BGP security model other than as discussed in the Security
Considerations section of [RFC7752]. Considerations section of [RFC7752].
9. Acknowledgements 10. Acknowledgements
The authors would like to thank Les Ginsberg for his review and The authors would like to thank Les Ginsberg, Baalajee S and Amalesh
contributions to this work. Maity for their review and feedback on this document.
10. References 11. References
10.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 TE Attributes per application", draft-
ietf-isis-te-app-06 (work in progress), April 2019. ietf-isis-te-app-09 (work in progress), October 2019.
[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 (TE) and J. Drake, "OSPF Link Traffic Engineering Attribute
Attribute Reuse", draft-ietf-ospf-te-link-attr-reuse-07 Reuse", draft-ietf-ospf-te-link-attr-reuse-10 (work in
(work in progress), April 2019. progress), October 2019.
[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,
<https://www.rfc-editor.org/info/rfc7752>. <https://www.rfc-editor.org/info/rfc7752>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References 11.2. Informative References
[I-D.ietf-idr-eag-distribution] [I-D.ietf-idr-eag-distribution]
Wang, Z., Wu, Q., and J. Tantsura, "Distribution of MPLS- Wang, Z., WU, Q., and J. Tantsura, "Distribution of MPLS-
TE Extended admin Group Using BGP", draft-ietf-idr-eag- TE Extended admin Group Using BGP", draft-ietf-idr-eag-
distribution-08 (work in progress), October 2018. distribution-09 (work in progress), October 2019.
[I-D.ietf-idr-te-pm-bgp]
Ginsberg, L., Previdi, S., Wu, Q., Tantsura, J., and C.
Filsfils, "BGP-LS Advertisement of IGP Traffic Engineering
Performance Metric Extensions", draft-ietf-idr-te-pm-
bgp-18 (work in progress), December 2018.
[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-02 (work in progress), May 2019. algo-04 (work in progress), September 2019.
[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 12, line 47 skipping to change at page 12, line 42
[RFC5706] Harrington, D., "Guidelines for Considering Operations and [RFC5706] Harrington, D., "Guidelines for Considering Operations and
Management of New Protocols and Protocol Extensions", Management of New Protocols and Protocol Extensions",
RFC 5706, DOI 10.17487/RFC5706, November 2009, RFC 5706, DOI 10.17487/RFC5706, November 2009,
<https://www.rfc-editor.org/info/rfc5706>. <https://www.rfc-editor.org/info/rfc5706>.
[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>.
Authors' Addresses [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and
C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of
IGP Traffic Engineering Performance Metric Extensions",
RFC 8571, DOI 10.17487/RFC8571, March 2019,
<https://www.rfc-editor.org/info/rfc8571>.
Authors' Addresses
Ketan Talaulikar Ketan Talaulikar
Cisco Systems Cisco Systems
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
Apstra Apstra
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
 End of changes. 51 change blocks. 
142 lines changed or deleted 144 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/