| < draft-ietf-ospf-segment-routing-msd-22.txt | draft-ietf-ospf-segment-routing-msd-23.txt > | |||
|---|---|---|---|---|
| OSPF Working Group J. Tantsura | OSPF 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: April 14, 2019 Huawei Technologies | Expires: April 15, 2019 Huawei Technologies | |||
| S. Aldrin | S. Aldrin | |||
| Google, Inc | Google, Inc | |||
| P. Psenak | P. Psenak | |||
| Cisco Systems | Cisco Systems | |||
| October 11, 2018 | October 12, 2018 | |||
| Signaling MSD (Maximum SID Depth) using OSPF | Signaling MSD (Maximum SID Depth) using OSPF | |||
| draft-ietf-ospf-segment-routing-msd-22 | draft-ietf-ospf-segment-routing-msd-23 | |||
| Abstract | Abstract | |||
| This document defines a way for an Open Shortest Path First (OSPF) | This document defines a way for an Open Shortest Path First (OSPF) | |||
| Router to advertise multiple types of supported Maximum SID(Segment | Router to advertise multiple types of supported Maximum SID(Segment | |||
| Identifier) Depths (MSDs) at node and/or link granularity. Such | Identifier) Depths (MSDs) at node and/or link granularity. Such | |||
| advertisements allow entities (e.g., centralized controllers) to | advertisements allow entities (e.g., centralized controllers) to | |||
| determine whether a particular SID stack can be supported in a given | determine whether a particular SID stack can be supported in a given | |||
| network. This document defines only one type of MSD, but defines an | network. This document defines only one type of MSD, but defines an | |||
| encoding that can support other MSD types. Here the term OSPF means | encoding that can support other MSD types. Here the term OSPF means | |||
| skipping to change at page 1, line 42 ¶ | skipping to change at page 1, line 42 ¶ | |||
| 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 April 14, 2019. | This Internet-Draft will expire on April 15, 2019. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 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 25 ¶ | skipping to change at page 2, line 25 ¶ | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 | 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 | |||
| 2. Node MSD Advertisement . . . . . . . . . . . . . . . . . . . 4 | 2. Node MSD Advertisement . . . . . . . . . . . . . . . . . . . 4 | |||
| 3. Link MSD sub-TLV . . . . . . . . . . . . . . . . . . . . . . 5 | 3. Link MSD sub-TLV . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 4. Procedures for Defining and Using Node and Link MSD | 4. Procedures for Defining and Using Node and Link MSD | |||
| Advertisements . . . . . . . . . . . . . . . . . . . . . . . 6 | Advertisements . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | |||
| 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 | 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 | |||
| 9.2. Informative References . . . . . . . . . . . . . . . . . 9 | 9.2. Informative References . . . . . . . . . . . . . . . . . 9 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 1. Introduction | 1. Introduction | |||
| When Segment Routing (SR) paths are computed by a centralized | When Segment Routing (SR) paths are computed by a centralized | |||
| controller, it is critical that the controller learns the Maximum SID | controller, it is critical that the controller learns the Maximum SID | |||
| (Segment Identifier) Depth (MSD) that can be imposed at each node/ | (Segment Identifier) Depth (MSD) that can be imposed at each node/ | |||
| link on a given SR path to ensure that the Segment Identifier (SID) | link on a given SR path to ensure that the Segment Identifier (SID) | |||
| stack depth of a computed path doesn't exceed the number of SIDs the | stack depth of a computed path doesn't exceed the number of SIDs the | |||
| node is capable of imposing. | node is capable of imposing. | |||
| skipping to change at page 7, line 8 ¶ | skipping to change at page 7, line 8 ¶ | |||
| In order to increase flooding efficiency, it is RECOMMENDED that | In order to increase flooding efficiency, it is RECOMMENDED that | |||
| routers with homogenous link MSD values advertise just the Node MSD | routers with homogenous link MSD values advertise just the Node MSD | |||
| value. | value. | |||
| The meaning of the absence of both Node and Link MSD advertisements | The meaning of the absence of both Node and Link MSD advertisements | |||
| for a given MSD-type is specific to the MSD-type. Generally it can | for a given MSD-type is specific to the MSD-type. Generally it can | |||
| only be inferred that the advertising node does not support | only be inferred that the advertising node does not support | |||
| advertisement of that MSD-type. However, in some cases the lack of | advertisement of that MSD-type. However, in some cases the lack of | |||
| advertisement might imply that the functionality associated with the | advertisement might imply that the functionality associated with the | |||
| 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. | specified when an MSD-type is defined in | |||
| [I-D.ietf-isis-segment-routing-msd]. | ||||
| 5. IANA Considerations | 5. IANA Considerations | |||
| This document requests IANA to allocate TLV type (TBD1) from the OSPF | This document requests IANA to allocate TLV type (TBD1) from the OSPF | |||
| Router Information (RI) TLVs Registry as defined by [RFC7770]. IANA | Router Information (RI) TLVs Registry as defined by [RFC7770]. IANA | |||
| has allocated the value 12 through the early assignment process. | has allocated the value 12 through the early assignment process. | |||
| Value Description Reference | Value Description Reference | |||
| ----- --------------- ------------- | ----- --------------- ------------- | |||
| 12 Node MSD This document | 12 Node MSD This document | |||
| End of changes. 8 change blocks. | ||||
| 8 lines changed or deleted | 9 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/ | ||||