--- 1/draft-ietf-ospf-segment-routing-msd-22.txt 2018-10-12 16:13:13.218185320 -0700 +++ 2/draft-ietf-ospf-segment-routing-msd-23.txt 2018-10-12 16:13:13.242185906 -0700 @@ -1,23 +1,23 @@ OSPF Working Group J. Tantsura Internet-Draft Apstra, Inc. Intended status: Standards Track U. Chunduri -Expires: April 14, 2019 Huawei Technologies +Expires: April 15, 2019 Huawei Technologies S. Aldrin Google, Inc P. Psenak Cisco Systems - October 11, 2018 + October 12, 2018 Signaling MSD (Maximum SID Depth) using OSPF - draft-ietf-ospf-segment-routing-msd-22 + draft-ietf-ospf-segment-routing-msd-23 Abstract This document defines a way for an Open Shortest Path First (OSPF) Router to advertise multiple types of supported Maximum SID(Segment Identifier) Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular SID stack can be supported in a given network. This document defines only one type of MSD, but defines an encoding that can support other MSD types. Here the term OSPF means @@ -31,21 +31,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -58,27 +58,27 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Node MSD Advertisement . . . . . . . . . . . . . . . . . . . 4 3. Link MSD sub-TLV . . . . . . . . . . . . . . . . . . . . . . 5 4. Procedures for Defining and Using Node and Link MSD Advertisements . . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction When Segment Routing (SR) paths are computed by a centralized controller, it is critical that the controller learns the Maximum SID (Segment Identifier) Depth (MSD) that can be imposed at each node/ 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 node is capable of imposing. @@ -277,21 +277,22 @@ In order to increase flooding efficiency, it is RECOMMENDED that routers with homogenous link MSD values advertise just the Node MSD value. 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 only be inferred that the advertising node does not support advertisement of that MSD-type. However, in some cases the lack of advertisement might imply that the functionality associated with the 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 This document requests IANA to allocate TLV type (TBD1) from the OSPF Router Information (RI) TLVs Registry as defined by [RFC7770]. IANA has allocated the value 12 through the early assignment process. Value Description Reference ----- --------------- ------------- 12 Node MSD This document