--- 1/draft-ietf-ospf-segment-routing-msd-16.txt 2018-08-23 15:13:08.379022190 -0700 +++ 2/draft-ietf-ospf-segment-routing-msd-17.txt 2018-08-23 15:13:08.403022775 -0700 @@ -1,23 +1,23 @@ OSPF Working Group J. Tantsura Internet-Draft Nuage Networks Intended status: Standards Track U. Chunduri -Expires: February 20, 2019 Huawei Technologies +Expires: February 22, 2019 Huawei Technologies S. Aldrin Google, Inc P. Psenak Cisco Systems - August 19, 2018 + August 21, 2018 Signaling MSD (Maximum SID Depth) using OSPF - draft-ietf-ospf-segment-routing-msd-16 + draft-ietf-ospf-segment-routing-msd-17 Abstract This document defines a way for an Open Shortest Path First (OSPF) Router to advertise multiple types of supported Maximum SID 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 both OSPFv2 @@ -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 February 20, 2019. + This Internet-Draft will expire on February 22, 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 @@ -59,21 +59,21 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Node MSD Advertisement . . . . . . . . . . . . . . . . . . . 4 3. Link MSD sub-TLV . . . . . . . . . . . . . . . . . . . . . . 5 4. Using Node and Link MSD Advertisements . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction When Segment Routing (SR) paths are computed by a centralized controller, it is critical that the controller learns the Maximum SID Depth (MSD) that can be imposed at each node/link on a given SR path @@ -148,29 +148,29 @@ 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Node MSD Advertisement The node MSD TLV within the body of the OSPF RI Opaque LSA [RFC7770] is defined to carry the provisioned SID depth of the router originating the RI LSA. Node MSD is the smallest MSD supported by the node on the set of interfaces configured for use by the advertising IGP instance. MSD values may be learned via a hardware - API or may be provisioned.. + API or may be provisioned. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | MSD-Type | MSD-Value | + | MSD-Type | MSD-Value | MSD-Type... | MSD-Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Node MSD TLV The Type: TBD1 Length: variable (multiple of 2 octets) and represents the total length of value field in octets. Value: consists of one or more pairs of a 1 octet MSD-type and 1 @@ -207,21 +207,21 @@ The link sub-TLV is defined to carry the MSD of the interface associated with the link. MSD values may be learned via a hardware API or may be provisioned. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | MSD-Type | MSD-Value | + | MSD-Type | MSD-Value | MSD-Type... | MSD-Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Link MSD Sub-TLV Type: For OSPFv2, the Link level MSD value is advertised as an optional Sub-TLV of the OSPFv2 Extended Link TLV as defined in [RFC7684], and has a type of TBD2. @@ -272,26 +272,26 @@ 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. 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. + Also, this document requests IANA to allocate a sub-TLV type (TBD2) from the OSPFv2 Extended Link TLV Sub-TLVs registry. IANA has - allocated the the value 6 through the early assignment process. - - Finally, this document requests IANA to allocate a sub-TLV type - (TBD3) from the OSPFv3 Extended-LSA Sub-TLV registry. + allocated the value 6 through the early assignment process. Finally, + this document requests IANA to allocate a sub-TLV type (TBD3) from + the OSPFv3 Extended-LSA Sub-TLV registry. 6. Security Considerations Security concerns for OSPF are addressed in [RFC7474]. Further security analysis for OSPF protocol is done in [RFC6863] Security considerations, as specified by [RFC7770], [RFC7684] and [RFC8362] are applicable to this document. Advertisement of an incorrect MSD value may result: in a path computation failing and the service unavailable or instantiation of a @@ -299,21 +299,21 @@ imposition). 7. Contributors The following people contributed to this document: Les Ginsberg Email: ginsberg@cisco.com -8. Acknowledgements +8. Acknowledgments The authors would like to thank Acee Lindem, Ketan Talaulikar, Tal Mizrahi, Stephane Litkowski and Bruno Decraene for their reviews and valuable comments. 9. References 9.1. Normative References [I-D.ietf-isis-segment-routing-msd]