< draft-ietf-idr-bgp-ls-segment-routing-msd-11.txt   draft-ietf-idr-bgp-ls-segment-routing-msd-12.txt >
IDR Working Group J. Tantsura IDR Working Group J. Tantsura
Internet-Draft Apstra, Inc. Internet-Draft Apstra, Inc.
Intended status: Standards Track U. Chunduri Intended status: Standards Track U. Chunduri
Expires: August 31, 2020 Futurewei Technologies Expires: September 2, 2020 Futurewei Technologies
K. Talaulikar K. Talaulikar
Cisco Systems Cisco Systems
G. Mirsky G. Mirsky
ZTE Corp. ZTE Corp.
N. Triantafillis N. Triantafillis
Amazon Web Services Amazon Web Services
February 28, 2020 March 1, 2020
Signaling MSD (Maximum SID Depth) using Border Gateway Protocol - Link Signaling MSD (Maximum SID Depth) using Border Gateway Protocol - Link
State State
draft-ietf-idr-bgp-ls-segment-routing-msd-11 draft-ietf-idr-bgp-ls-segment-routing-msd-12
Abstract Abstract
This document defines a way for a Border Gateway Protocol - Link This document defines a way for a Border Gateway Protocol - Link
State (BGP-LS) speaker to advertise multiple types of supported State (BGP-LS) speaker to advertise multiple types of supported
Maximum SID Depths (MSDs) at node and/or link granularity. Maximum SID Depths (MSDs) at node and/or link granularity.
Such advertisements allow entities (e.g., centralized controllers) to Such advertisements allow entities (e.g., centralized controllers) to
determine whether a particular Segment Identifier (SID) stack can be determine whether a particular Segment Identifier (SID) stack can be
supported in a given network. supported in a given network.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 August 31, 2020. This Internet-Draft will expire on September 2, 2020.
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 33 skipping to change at page 2, line 33
1.1. Conventions used in this document . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . 3
1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3
1.1.2. Requirements Language . . . . . . . . . . . . . . . . 4 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 4
2. Advertisement of MSD via BGP-LS . . . . . . . . . . . . . . . 4 2. Advertisement of MSD via BGP-LS . . . . . . . . . . . . . . . 4
3. Node MSD TLV . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Node MSD TLV . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Link MSD TLV . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Link MSD TLV . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Procedures for Defining and Using Node and Link MSD 5. Procedures for Defining and Using Node and Link MSD
Advertisements . . . . . . . . . . . . . . . . . . . . . . . 6 Advertisements . . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Manageability Considerations . . . . . . . . . . . . . . . . 7 7. Manageability Considerations . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
When Segment Routing (SR) [RFC8402] paths are computed by a When Segment Routing (SR) [RFC8402] paths are computed by a
skipping to change at page 3, line 22 skipping to change at page 3, line 22
This document defines extensions to BGP-LS to advertise one or more This document defines extensions to BGP-LS to advertise one or more
types of MSDs at node and/or link granularity. Other types of MSD types of MSDs at node and/or link granularity. Other types of MSD
are known to be useful. For example, [I-D.ietf-ospf-mpls-elc] and are known to be useful. For example, [I-D.ietf-ospf-mpls-elc] and
[I-D.ietf-isis-mpls-elc] define Readable Label Depth Capability [I-D.ietf-isis-mpls-elc] define Readable Label Depth Capability
(RLDC) that is used by a head-end to insert an Entropy Label (EL) at (RLDC) that is used by a head-end to insert an Entropy Label (EL) at
a depth that can be read by transit nodes. a depth that can be read by transit nodes.
In the future, it is expected that new MSD-Types will be defined to In the future, it is expected that new MSD-Types will be defined to
signal additional capabilities, e.g., ELs, SIDs that can be imposed signal additional capabilities, e.g., ELs, SIDs that can be imposed
through recirculation, or SIDs associated with another data plane through recirculation, or SIDs associated with another data plane
such as IPv6. MSD advertisements MAY be useful even if SR itself is such as IPv6. MSD advertisements may be useful even if SR itself is
not enabled. For example, in a non-SR MPLS network, MSD defines the not enabled. For example, in a non-SR MPLS network, MSD defines the
maximum label depth. maximum label depth.
1.1. Conventions used in this document 1.1. Conventions used in this document
1.1.1. Terminology 1.1.1. Terminology
BGP-LS: Distribution of Link-State and TE Information using Border MSD: Maximum SID Depth - the number of SIDs supported by a node or a
Gateway Protocol link on a node
MSD: Maximum SID Depth
PCC: Path Computation Client PCC: Path Computation Client
PCE: Path Computation Element PCE: Path Computation Element
PCEP: Path Computation Element Protocol PCEP: Path Computation Element Protocol
SID: Segment Identifier SID: Segment Identifier as defined in [RFC8402]
SR: Segment routing SR: Segment routing
Label Imposition: Imposition is the act of modifying and/or adding Label Imposition: Imposition is the act of modifying and/or adding
labels to the outgoing label stack associated with a packet. This labels to the outgoing label stack associated with a packet. This
includes: includes:
o replacing the label at the top of the label stack with a new o replacing the label at the top of the label stack with a new
label. label.
o pushing one or more new labels onto the label stack. The number o pushing one or more new labels onto the label stack.
of labels imposed is then the sum of the number of labels that are
replaced and the number of labels that are pushed. See [RFC3031] o The number of labels imposed is then the sum of the number of
for further details. labels that are replaced and the number of labels that are pushed.
See [RFC3031] for further details.
1.1.2. Requirements Language 1.1.2. 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. Advertisement of MSD via BGP-LS 2. Advertisement of MSD via BGP-LS
This document describes extensions that enable BGP-LS speakers to This document describes extensions that enable BGP-LS speakers to
signal the MSD capabilities (described in [RFC8491] ) of nodes and signal the MSD capabilities ([RFC8491] ) of nodes and their links in
their links in a network to a BGP-LS consumer of network topology a network to a BGP-LS consumer of network topology such as a
such as a centralized controller. The centralized controller can centralized controller. The centralized controller can leverage this
leverage this information in computation of SR paths and their information in computation of SR paths and their instantiation on
instantiation on network nodes based on their MSD capabilities. When network nodes based on their MSD capabilities. When a BGP-LS speaker
a BGP-LS speaker is originating the topology learnt via link-state is originating the topology learnt via link-state routing protocols
routing protocols like OSPF or IS-IS, the MSD information for the like OSPF or IS-IS, the MSD information for the nodes and their links
nodes and their links is sourced from the underlying extensions as is sourced from the underlying extensions as defined in [RFC8476] and
defined in [RFC8476] and [RFC8491] respectively. [RFC8491] respectively.
The BGP-LS speaker may also advertise the MSD information for the The BGP-LS speaker may also advertise the MSD information for the
local node and its links when not running any link-state IGP protocol local node and its links when not running any link-state IGP protocol
e.g. when running BGP as the only routing protocol. The Protocol-ID e.g. when running BGP as the only routing protocol. The Protocol-ID
field should be set to BGP since the link and node attributes have field should be set to BGP since the link and node attributes have
BGP based identifiers. Deployment model for such case would be: a BGP based identifiers. Deployment model for such case would be: a
limited number (meeting resiliecy requirements) of BGP-LS speakers limited number (meeting resiliecy requirements) of BGP-LS speakers
exposing the topology to the controller, full-mesh/RouteReflectors exposing the topology to the controller, full-mesh/RouteReflectors
for iBGP(Internal Border Gateway Protocol) or regular eBGP(External for iBGP(Internal Border Gateway Protocol) or regular eBGP(External
Border Gateway Protocol) connectivity between nodes in the topology. Border Gateway Protocol) connectivity between nodes in the topology.
The extensions introduced in this document allow for advertisement of The extensions introduced in this document allow for advertisement of
different MSD-Types. This document does not define these MSD-Types different MSD-Types, which are defined elsewhere and were introduced
but leverages the definition, guidelines and the code-point registry in [RFC8491]. This enables sharing of MSD-Types that may be defined
specified in [RFC8491]. This enables sharing of MSD-Types that may in the future by the IGPs in BGP-LS.
be defined in the future by the IGPs in BGP-LS.
3. Node MSD TLV 3. Node MSD TLV
Node MSD is encoded in a new Node Attribute TLV [RFC7752] using the The Node MSD ([RFC8476] [RFC8491]) is encoded in a new Node Attribute
following format: TLV [RFC7752] to carry the provisioned SID depth of the router
identified by the corresponding Router-ID. Node MSD is the smallest
MSD supported by the node on the set of interfaces configured for
use. MSD values may be learned via a hardware API or may be
provisioned. The following format is used:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSD-Type | MSD-Value | MSD-Type... | MSD-Value... | | MSD-Type | MSD-Value | MSD-Type... | MSD-Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Node MSD TLV Format Figure 1: Node MSD TLV Format
skipping to change at page 5, line 25 skipping to change at page 5, line 25
Where: Where:
o Type: 266 o Type: 266
o Length: variable (multiple of 2); represents the total length of o Length: variable (multiple of 2); represents the total length of
the value field in octets. the value field in octets.
o Value : consists of one or more pairs of a 1-octet MSD-Type and o Value : consists of one or more pairs of a 1-octet MSD-Type and
1-octet MSD-Value. 1-octet MSD-Value.
* MSD-Type : one of the values defined in the IANA registry * MSD-Type : one of the values defined in the "IGP MSD-Types"
titled "IGP MSD-Types" under the "Interior Gateway Protocol registry defined in [RFC8491].
(IGP) Parameters" registry created by [RFC8491].
* MSD-Value : a number in the range of 0-255. For all MSD-Types, * MSD-Value : a number in the range of 0-255. For all MSD-Types,
0 represents the lack of ability to impose an MSD stack of any 0 represents the lack of ability to impose an MSD stack of any
depth; any other value represents that of the node. This value depth; any other value represents that of the node. This value
MUST represent the lowest value supported by any link MUST represent the lowest value supported by any link
configured for use by the advertising protocol instance. configured for use by the advertising protocol instance.
4. Link MSD TLV 4. Link MSD TLV
Link MSD is encoded in a new Link Attribute TLV [RFC7752] using the The Link MSD ([RFC8476] [RFC8491]) is defined to carry the MSD of the
following format: interface associated with the link. It is encoded in a new Link
Attribute TLV [RFC7752] using the following format:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSD-Type | MSD-Value | MSD-Type... | MSD-Value... | | MSD-Type | MSD-Value | MSD-Type... | MSD-Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Link MSD TLV Format Figure 2: Link MSD TLV Format
Where: Where:
o Type: 267 o Type: 267
o Length: variable (multiple of 2); represents the total length of o Length: variable (multiple of 2); represents the total length of
the value field in octets. the value field in octets.
o Value : consists of one or more pairs of a 1-octet MSD-Type and o Value : consists of one or more pairs of a 1-octet MSD-Type and
1-octet MSD-Value. 1-octet MSD-Value.
* MSD-Type : one of the values defined in the IANA registry * MSD-Type : MSD-Type : one of the values defined in the "IGP
titled "IGP MSD-Types" under the "Interior Gateway Protocol MSD-Types" registry defined in [RFC8491].
(IGP) Parameters" registry created by [RFC8491].
* MSD-Value : a number in the range of 0-255. For all MSD-Types, * MSD-Value : a number in the range of 0-255. For all MSD-Types,
0 represents the lack of ability to impose an MSD stack of any 0 represents the lack of ability to impose an MSD stack of any
depth; any other value represents that of the link when used as depth; any other value represents that of the link when used as
an outgoing interface. an outgoing interface.
5. Procedures for Defining and Using Node and Link MSD Advertisements 5. Procedures for Defining and Using Node and Link MSD Advertisements
When Link MSD is present for a given MSD-type, the value of the Link When Link MSD is present for a given MSD-type, the value of the Link
MSD MUST take precedence over the Node MSD. When a Link MSD-type is MSD MUST take precedence over the Node MSD. When a Link MSD-type is
skipping to change at page 6, line 45 skipping to change at page 6, line 44
MSD-type is not supported. The correct interpretation MUST be MSD-type is not supported. The correct interpretation MUST be
specified when an MSD-type is defined in [RFC8491]. specified when an MSD-type is defined in [RFC8491].
6. IANA Considerations 6. 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. Early allocation for these code-points TLVs" based on table below. Early allocation for these code-points
have been done by IANA. have been done by IANA.
+------------+-----------------+---------------------------+ +------------+-----------------+---------------------------+-------------------+
| Code Point | Description | IS-IS TLV/Sub-TLV | | Code Point | Description | IS-IS TLV/Sub-TLV | Reference |
+------------+-----------------+---------------------------+ +------------+-----------------+---------------------------+-------------------+
| 266 | Node MSD | 242/23 | | 266 | Node MSD | 242/23 | This document |
| 267 | Link MSD | (22,23,25,141,222,223)/15 | | 267 | Link MSD | (22,23,25,141,222,223)/15 | This document |
+------------+-----------------+---------------------------+ +------------+-----------------+---------------------------+-------------------+
7. Manageability Considerations 7. Manageability 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 is distributed via [RFC7752]. existing IGP topology information that is 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 attribute tests for syntactic checks in Specifically, the malformed attribute tests for syntactic checks in
the Fault Management section of [RFC7752] now encompass the new BGP- the Fault Management section of [RFC7752] now encompass the new BGP-
LS Attribute TLVs defined in this document. The semantic or content LS Attribute TLVs defined in this document. The semantic or content
checking for the TLVs specified in this document and their checking for the TLVs specified in this document and their
association with the BGP-LS NLRI types or their BGP-LS Attribute is association with the BGP-LS NLRI types or their BGP-LS Attribute is
left to the consumer of the BGP-LS information (e.g. an application left to the consumer of the BGP-LS information (e.g. an application
or a controller) and not the BGP protocol. or a controller) and not the BGP protocol.
A consumer of the BGP-LS information retrieves this information over A consumer of the BGP-LS information retrieves this information over
a BGP-LS session (refer Section 1 and 2 of [RFC7752]). The handling a BGP-LS session (refer Section 1 and 2 of [RFC7752]).
of semantic or content errors by the consumer would be dictated by
the nature of its application usage and hence is beyond the scope of
this document.
This document only introduces new Attribute TLVs and any syntactic This document only introduces new Attribute TLVs and any syntactic
error in them would result in the BGP-LS Attribute being discarded error in them would result in the BGP-LS Attribute being discarded
with an error log. The MSD information introduced in BGP-LS by this [RFC7752]. The MSD information introduced in BGP-LS by this
specification, may be used by BGP-LS consumer applications like a SR specification, may be used by BGP-LS consumer applications like a SR
path computation engine (PCE) to learn the SR SID-stack handling path computation engine (PCE) to learn the SR SID-stack handling
capabilities of the nodes in the topology. This can enable the SR capabilities of the nodes in the topology. This can enable the SR
PCE to perform path computations taking into consideration the size PCE to perform path computations taking into consideration the size
of SID Stack that the specific headend node may be able to impose. of SID Stack that the specific headend node may be able to impose.
Errors in the encoding or decoding of the MSD information may result Errors in the encoding or decoding of the MSD information may result
in the unavailability of such information to the SR PCE or incorrect in the unavailability of such information to the SR PCE or incorrect
information being made available to it. This may result in the information being made available to it. This may result in the
headend node not being able to instantiate the desired SR path in its headend node not being able to instantiate the desired SR path in its
forwarding and provide the SR based optimization functionality. The forwarding and provide the SR based optimization functionality. The
handling of such errors by applications like SR PCE may be handling of such errors by applications like SR PCE may be
implementation specific and out of scope of this document. implementation specific and out of scope of 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 BGP and BGP-LS models is an ongoing work specification of BGP models is an ongoing work based on the
based on the [I-D.ietf-idr-bgp-model]. The management of the MSD [I-D.ietf-idr-bgp-model].
features within an ietf segment-routing stack is also an ongoing work
based on the [I-D.ietf-spring-sr-yang]. Management of the segment
routing in IGPs is ongoing work for ISIS [I-D.ietf-isis-sr-yang] ,
and OSPF [I-D.ietf-ospf-sr-yang].
8. Security Considerations 8. Security Considerations
The advertisement of an incorrect MSD value may have negative The advertisement of an incorrect MSD value may have negative
consequences. If the value is smaller than supported, path consequences. If the value is smaller than supported, path
computation may fail to compute a viable path. If the value is computation may fail to compute a viable path. If the value is
larger than supported, an attempt to instantiate a path that can't be larger than supported, an attempt to instantiate a path that can't be
supported by the head-end (the node performing the SID imposition) supported by the head-end (the node performing the SID imposition)
may occur. The presence of this information may also inform an may occur. The presence of this information may also inform an
attacker of how to induce any of the aforementioned conditions. attacker of how to induce any of the aforementioned conditions.
The document does not introduce additional security issues beyond The procedures and protocol extensions defined in this document do
discussed in [RFC7752], [RFC8476] and [RFC8491]. However, [RFC7752] not affect the BGP security model. See the "Security Considerations"
is being revised in [I-D.ietf-idr-rfc7752bis] to provide additional section of [RFC4271] for a discussion of BGP security. Also, refer
clarification in several portions of the specification after to [RFC4272] and [RFC6952] for analyses of security issues for BGP.
receiving feedback from implementers. One of the places that is Security considerations for acquiring and distributing BGP-LS
being clarified is the error handling and security. It is expected information are discussed in [RFC7752]. The TLVs introduced in this
that after [I-D.ietf-idr-rfc7752bis] is released that implementers document are used to propagate the MSD IGP extensions defined in
will update all BGP-LS base implementations improving the error [RFC8476] [RFC8491]. It is assumed that the IGP instances
handling for protocol work (including this document) that depend on originating these TLVs will support all the required security (as
this function. described in [RFC8476] [RFC8491]) in order to prevent any security
issues when propagating the TLVs into BGP-LS. The advertisement of
the node and link attribute information defined in this document
presents no additional risk beyond that associated with the existing
node and link attribute information already supported in [RFC7752].
9. Contributors 9. Contributors
Siva Sivabalan Siva Sivabalan
Cisco Systems Inc. Cisco Systems Inc.
Canada Canada
Email: msiva@cisco.com Email: msiva@cisco.com
10. Acknowledgements 10. Acknowledgements
skipping to change at page 10, line 21 skipping to change at page 10, line 15
[I-D.ietf-spring-sr-yang] [I-D.ietf-spring-sr-yang]
Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J. Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J.
Tantsura, "YANG Data Model for Segment Routing", draft- Tantsura, "YANG Data Model for Segment Routing", draft-
ietf-spring-sr-yang-15 (work in progress), January 2020. ietf-spring-sr-yang-15 (work in progress), January 2020.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001, DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>. <https://www.rfc-editor.org/info/rfc3031>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006,
<https://www.rfc-editor.org/info/rfc4272>.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
<https://www.rfc-editor.org/info/rfc6952>.
[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>.
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "Path Computation Element Communication and J. Hardwick, "Path Computation Element Communication
Protocol (PCEP) Extensions for Segment Routing", RFC 8664, Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
DOI 10.17487/RFC8664, December 2019, DOI 10.17487/RFC8664, December 2019,
<https://www.rfc-editor.org/info/rfc8664>. <https://www.rfc-editor.org/info/rfc8664>.
 End of changes. 21 change blocks. 
66 lines changed or deleted 78 lines changed or added

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