draft-ietf-idr-bgp-ls-segment-routing-msd-06.txt | draft-ietf-idr-bgp-ls-segment-routing-msd-07.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: March 8, 2020 Futurewei Technologies | Expires: March 14, 2020 Futurewei Technologies | |||
K. Talaulikar | K. Talaulikar | |||
Cisco Systems | Cisco Systems | |||
G. Mirsky | G. Mirsky | |||
ZTE Corp. | ZTE Corp. | |||
N. Triantafillis | N. Triantafillis | |||
Apstra, Inc. | Apstra, Inc. | |||
September 5, 2019 | September 11, 2019 | |||
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-06 | draft-ietf-idr-bgp-ls-segment-routing-msd-07 | |||
Abstract | Abstract | |||
This document defines a way for a Border Gateway Protocol Link-State | This document defines a way for a Border Gateway Protocol Link-State | |||
(BGP-LS) speaker to advertise multiple types of supported Maximum SID | (BGP-LS) speaker to advertise multiple types of supported Maximum SID | |||
Depths (MSDs) at node and/or link granularity. | 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 March 8, 2020. | This Internet-Draft will expire on March 14, 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 32 ¶ | skipping to change at page 2, line 32 ¶ | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | |||
6. Manageability Considerations . . . . . . . . . . . . . . . . 6 | 6. Manageability Considerations . . . . . . . . . . . . . . . . 6 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | |||
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 | 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 8 | 10.2. Informative References . . . . . . . . . . . . . . . . . 8 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 | 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 | |||
centralized controller, it is critical that the controller learns the | centralized controller, it is critical that the controller learns the | |||
Maximum SID Depth (MSD) that can be imposed at each node/link on a | Maximum SID Depth (MSD) that can be imposed at each node/link on a | |||
given SR path. This ensures that the Segment Identifier (SID) stack | given SR path. This ensures that the Segment Identifier (SID) stack | |||
depth of a computed path doesn't exceed the number of SIDs the node | depth of a computed path doesn't exceed the number of SIDs the node | |||
is capable of imposing. | is capable of imposing. | |||
skipping to change at page 4, line 21 ¶ | skipping to change at page 4, line 21 ¶ | |||
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 of nodes and their links in a network to | signal the MSD capabilities (described in [RFC8491] ) of nodes and | |||
a BGP-LS consumer of network topology such as a centralized | their links in a network to a BGP-LS consumer of network topology | |||
controller. The centralized controller can leverage this information | such as a centralized controller. The centralized controller can | |||
in computation of SR paths and their instantiation on network nodes | leverage this information in computation of SR paths and their | |||
based on their MSD capabilities. When a BGP-LS speaker is | instantiation on network nodes based on their MSD capabilities. When | |||
originating the topology learnt via link-state routing protocols like | a BGP-LS speaker is originating the topology learnt via link-state | |||
OSPF or IS-IS, the MSD information for the nodes and their links is | routing protocols like OSPF or IS-IS, the MSD information for the | |||
sourced from the underlying extensions as defined in [RFC8476] and | nodes and their links is sourced from the underlying extensions as | |||
[RFC8491] respectively. The BGP-LS speaker may also advertise the | defined in [RFC8476] and [RFC8491] respectively. The BGP-LS speaker | |||
MSD information for the local node and its links when not running any | may also advertise the MSD information for the local node and its | |||
link-state IGP protocol e.g. when running BGP as the only routing | links when not running any link-state IGP protocol e.g. when running | |||
protocol. | BGP as the only routing protocol. | |||
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. This document does not define these MSD-Types | |||
but leverages the definition, guidelines and the code-point registry | but leverages the definition, guidelines and the code-point registry | |||
specified in [RFC8491]. This enables sharing of MSD-Types that may | specified in [RFC8491]. This enables sharing of MSD-Types that may | |||
be defined 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 | Node MSD is encoded in a new Node Attribute TLV [RFC7752] using the | |||
skipping to change at page 7, line 23 ¶ | skipping to change at page 7, line 23 ¶ | |||
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 introduce any new | The extensions specified in this document, do not specify any new | |||
configuration or monitoring aspects in BGP or BGP-LS other than as | configuration or monitoring aspects in BGP or BGP-LS. The | |||
discussed in [RFC7752]. The manageability aspects of the MSD | specification of BGP models BGP and BGP-LS models is an ongoing work | |||
features are covered by [I-D.ietf-spring-sr-yang]. | based on the [I-D.ietf-idr-bgp-model]. The management of the MSD | |||
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]. | ||||
7. Security Considerations | 7. 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. | |||
This document does not introduce security issues beyond those | The document does not introduce additional security issues beyond | |||
discussed in [RFC7752], [RFC8476] and [RFC8491] | discussed in [RFC7752], [RFC8476] and [RFC8491]. However, [RFC7752] | |||
is being revised in [I-D.ietf-idr-rfc7752bis] to provide additional | ||||
clarification in several portions of the specification after | ||||
receiving feedback from implementers. One of the places that is | ||||
being clarified is the error handling and security. It is expected | ||||
that after [I-D.ietf-idr-rfc7752bis] is released that implementers | ||||
will update all BGP-LS base implementations improving the error | ||||
handling for protocol work (including this document) that depend on | ||||
this function. | ||||
8. Contributors | 8. Contributors | |||
Siva Sivabalan | Siva Sivabalan | |||
Cisco Systems Inc. | Cisco Systems Inc. | |||
Canada | Canada | |||
Email: msiva@cisco.com | Email: msiva@cisco.com | |||
9. Acknowledgements | 9. Acknowledgements | |||
skipping to change at page 8, line 41 ¶ | skipping to change at page 8, line 49 ¶ | |||
DOI 10.17487/RFC8476, December 2018, | DOI 10.17487/RFC8476, December 2018, | |||
<https://www.rfc-editor.org/info/rfc8476>. | <https://www.rfc-editor.org/info/rfc8476>. | |||
[RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, | [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, | |||
"Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, | "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, | |||
DOI 10.17487/RFC8491, November 2018, | DOI 10.17487/RFC8491, November 2018, | |||
<https://www.rfc-editor.org/info/rfc8491>. | <https://www.rfc-editor.org/info/rfc8491>. | |||
10.2. Informative References | 10.2. Informative References | |||
[I-D.ietf-idr-bgp-model] | ||||
Jethanandani, M., Patel, K., and S. Hares, "BGP YANG Model | ||||
for Service Provider Networks", draft-ietf-idr-bgp- | ||||
model-06 (work in progress), June 2019. | ||||
[I-D.ietf-idr-rfc7752bis] | ||||
Talaulikar, K., Gredler, H., Medved, J., Previdi, S., | ||||
Farrel, A., and S. Ray, "Distribution of Link-State and | ||||
Traffic Engineering Information Using BGP", draft-ietf- | ||||
idr-rfc7752bis-00 (work in progress), September 2019. | ||||
[I-D.ietf-isis-mpls-elc] | [I-D.ietf-isis-mpls-elc] | |||
Xu, X., Kini, S., Psenak, P., Filsfils, C., and S. | Xu, X., Kini, S., Psenak, P., Filsfils, C., and S. | |||
Litkowski, "Signaling Entropy Label Capability and Entropy | Litkowski, "Signaling Entropy Label Capability and Entropy | |||
Readable Label Depth Using IS-IS", draft-ietf-isis-mpls- | Readable Label Depth Using IS-IS", draft-ietf-isis-mpls- | |||
elc-08 (work in progress), September 2019. | elc-08 (work in progress), September 2019. | |||
[I-D.ietf-isis-sr-yang] | ||||
Litkowski, S., Qu, Y., Sarkar, P., Chen, I., and J. | ||||
Tantsura, "YANG Data Model for IS-IS Segment Routing", | ||||
draft-ietf-isis-sr-yang-06 (work in progress), July 2019. | ||||
[I-D.ietf-ospf-mpls-elc] | [I-D.ietf-ospf-mpls-elc] | |||
Xu, X., Kini, S., Psenak, P., Filsfils, C., and S. | Xu, X., Kini, S., Psenak, P., Filsfils, C., and S. | |||
Litkowski, "Signaling Entropy Label Capability and Entropy | Litkowski, "Signaling Entropy Label Capability and Entropy | |||
Readable Label-stack Depth Using OSPF", draft-ietf-ospf- | Readable Label-stack Depth Using OSPF", draft-ietf-ospf- | |||
mpls-elc-08 (work in progress), May 2019. | mpls-elc-09 (work in progress), September 2019. | |||
[I-D.ietf-ospf-sr-yang] | ||||
Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, | ||||
"YANG Data Model for OSPF SR (Segment Routing) Protocol", | ||||
draft-ietf-ospf-sr-yang-10 (work in progress), August | ||||
2019. | ||||
[I-D.ietf-pce-segment-routing] | [I-D.ietf-pce-segment-routing] | |||
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., | Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., | |||
and J. Hardwick, "PCEP Extensions for Segment Routing", | and J. Hardwick, "PCEP Extensions for Segment Routing", | |||
draft-ietf-pce-segment-routing-16 (work in progress), | draft-ietf-pce-segment-routing-16 (work in progress), | |||
March 2019. | March 2019. | |||
[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- | |||
End of changes. 12 change blocks. | ||||
25 lines changed or deleted | 59 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/ |