| < draft-ietf-idr-bgp-ls-segment-routing-msd-12.txt | draft-ietf-idr-bgp-ls-segment-routing-msd-13.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: September 2, 2020 Futurewei Technologies | Expires: September 4, 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 | |||
| March 1, 2020 | March 3, 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-12 | draft-ietf-idr-bgp-ls-segment-routing-msd-13 | |||
| 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 September 2, 2020. | This Internet-Draft will expire on September 4, 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 4, line 23 ¶ | skipping to change at page 4, line 23 ¶ | |||
| "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 ([RFC8491] ) of nodes and their links in | signal the MSD capabilities ([RFC8491] ) of nodes and their links in | |||
| a network to a BGP-LS consumer of network topology such as a | a network to a BGP-LS consumer of network topology such as a | |||
| centralized controller. The centralized controller can leverage this | centralized controller. The centralized controller can leverage this | |||
| information in computation of SR paths and their instantiation on | information in computation of SR paths based on their MSD | |||
| network nodes based on their MSD capabilities. When a BGP-LS speaker | capabilities. When a BGP-LS speaker is originating the topology | |||
| is originating the topology learnt via link-state routing protocols | learnt via link-state routing protocols like OSPF or IS-IS, the MSD | |||
| like OSPF or IS-IS, the MSD information for the nodes and their links | information for the nodes and their links is sourced from the | |||
| is sourced from the underlying extensions as defined in [RFC8476] and | underlying extensions as defined in [RFC8476] and [RFC8491] | |||
| [RFC8491] respectively. | 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. | |||
| End of changes. 5 change blocks. | ||||
| 10 lines changed or deleted | 10 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/ | ||||