idnits 2.17.1 draft-ietf-ospf-segment-routing-msd-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 16, 2016) is 2710 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) == Outdated reference: A later version (-15) exists of draft-ietf-ospf-mpls-elc-03 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-lsa-extend-13 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-08 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OSPF Working Group J. Tantsura 3 Internet-Draft U. Chunduri 4 Intended status: Standards Track Individual 5 Expires: May 20, 2017 November 16, 2016 7 Signaling MSD (Maximum SID Depth) using OSPF 8 draft-ietf-ospf-segment-routing-msd-00 10 Abstract 12 This document proposes a way to expose Maximum SID Depth (MSD) 13 supported by a node at node and/or link level by an OSPF Router. In 14 a Segment Routing (SR) enabled network a centralized controller that 15 programs SR tunnels at the head-end node needs to know the MSD 16 information at node level and/or link level to push the label stack 17 of an appropriate depth . Here the term OSPF means both OSPFv2 and 18 OSPFv3. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 20, 2017. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Conventions used in this document . . . . . . . . . . . . 3 56 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Node MSD TLV . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. LINK MSD sub-TLV . . . . . . . . . . . . . . . . . . . . . . 4 61 5. Node MSD vs Link MSD conflict resolution . . . . . . . . . . 4 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 67 9.2. Informative References . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Introduction 72 When Segment Routing tunnels are computed by a centralized 73 controller, it is crucial that the controller knows the MSD "Maximum 74 SID Depth" of the node or link SR tunnel exits over, so it doesn't 75 download a path with SID (label stack) of a depth more than the node 76 or link used is capable of imposing. This document describes how to 77 use OSPF to expose the MSD of the node or link to a centralized 78 controller. 80 PCEP SR extensions [I-D.ietf-pce-segment-routing] has defined MSD, to 81 signal in SR PCE Capability TLV, METRIC Object. However, If PCEP is 82 not supported by a node (head-end of the SR tunnel) and controller 83 does not participate in IGP routing it has no way to learn the MSD of 84 the node or link configured. BGP-LS [RFC7752] defines a way to 85 expose topology and associated different attributes, capabilities of 86 the nodes in that topology to a centralized controller and MSD has 87 been defined in [I-D.tantsura-bgp-ls-segment-routing-msd]. For this 88 information to be advertised by BGP for the all nodes and links of 89 the network, where this is provisioned, OSPF module should have this 90 information in the LSDB. 92 [I-D.ietf-ospf-mpls-elc] defines, RLSDC which indicates how many 93 labels a node can read to take a decision to insert an Entropy Label 94 (EL) and is different than how many labels a node can push as defined 95 by MSD in this draft. 97 1.1. Conventions used in this document 99 1.1.1. Terminology 101 BGP-LS: Distribution of Link-State and TE Information using Border 102 Gateway Protocol 104 OSPF: Open Shortest Path First 106 MSD: Maximum SID Depth 108 PCC: Path Computation Client 110 PCE: Path Computation Element 112 PCEP: Path Computation Element Protocol 114 SID: Segment Identifier 116 SR: Segment routing 118 1.2. Requirements Language 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 2. Terminology 126 This memo makes use of the terms defined in [RFC4970]. 128 3. Node MSD TLV 130 A new TLV within the body of the OSPF RI Opaque LSA, called Node MSD 131 TLV is defined to carry the provisioned SID depth of the router 132 originating the RI LSA. Node MSD is the lowest MSD supported by the 133 node. 135 The Type (2 bytes) of this TLV is TBD. 137 Length is 2 bytes, and 139 the Value field contains MSD of the router originating the RI LSA. 140 Node MSD is a number in the range of 0-254. 0 represents lack of the 141 ability to push MSD of any depth; any other value represents that of 142 the node. This value SHOULD represent the lowest value supported by 143 node. 145 This TLV is applicable to OSPFv2 and to OSPFv3 [RFC5838] and is 146 optional. The scope of the advertisement is specific to the 147 deployment. 149 4. LINK MSD sub-TLV 151 A new sub-TLV called Link MSD sub-TLV is defined to carry the 152 provisioned SID depth of the interface associated with the link. 154 The Type (2 bytes) of this TLV is TBD. 156 Length is 2 bytes, and 158 the Value field contains Link MSD of the router originating the 159 corresponding LSA as specified for OSPFv3 and OSPFv3. Link MSD is a 160 number in the range of 0-254. 0 represents lack of the ability to 161 push MSD of any depth; any other value represents that of the 162 particular link MSD value. 164 For OSPFv2, the Link level MSD value is advertised as an optional 165 Sub-TLV of OSPFv2 Extended Link TLV as defined in [RFC7684]. 167 For OSPFv3, the Link level MSD value is advertised as an optional 168 Sub-TLV of the Router-Link TLV as defined in 169 [I-D.ietf-ospf-ospfv3-lsa-extend]. 171 5. Node MSD vs Link MSD conflict resolution 173 When both Node MSD and Link MSD are present, the value in the Link 174 MSD MUST be used. 176 6. Acknowledgements 178 TBD 180 7. IANA Considerations 182 This document includes a request to IANA to allocate TLV type codes 183 for the new TLV proposed in Section 3 of this document from OSPF 184 Router Information (RI) TLVs Registry as defined by [RFC4970]. Also 185 for link MSD, we request IANA to allocate new sub-TLV codes as 186 proposed in Section 4 from OSPFv2 Extended Link Opaque LSAs Extended 187 Link TLV registry and from Router-Link TLV defined in OSPFv3 Extend- 188 LSA Sub-TLV registry. 190 8. Security Considerations 192 This document describes a mechanism for advertising Segment Routing 193 SID depth supported at node and link level information through OSPF 194 LSAs and does not introduce any new security issues. 196 9. References 198 9.1. Normative References 200 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 201 Requirement Levels", BCP 14, RFC 2119, 202 DOI 10.17487/RFC2119, March 1997, 203 . 205 [RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 206 S. Shaffer, "Extensions to OSPF for Advertising Optional 207 Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July 208 2007, . 210 9.2. Informative References 212 [I-D.ietf-ospf-mpls-elc] 213 Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. 214 Litkowski, "Signaling Entropy Label Capability Using 215 OSPF", draft-ietf-ospf-mpls-elc-03 (work in progress), 216 October 2016. 218 [I-D.ietf-ospf-ospfv3-lsa-extend] 219 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 220 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-13 221 (work in progress), October 2016. 223 [I-D.ietf-pce-segment-routing] 224 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., 225 Raszuk, R., Lopez, V., Tantsura, J., Henderickx, W., and 226 J. Hardwick, "PCEP Extensions for Segment Routing", draft- 227 ietf-pce-segment-routing-08 (work in progress), October 228 2016. 230 [I-D.tantsura-bgp-ls-segment-routing-msd] 231 Tantsura, J., Mirsky, G., Sivabalan, S., and U. Chunduri, 232 "Signaling Maximum SID Depth using Border Gateway Protocol 233 Link-State", draft-tantsura-bgp-ls-segment-routing-msd-02 234 (work in progress), January 2016. 236 [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and 237 R. Aggarwal, "Support of Address Families in OSPFv3", 238 RFC 5838, DOI 10.17487/RFC5838, April 2010, 239 . 241 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 242 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 243 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 244 2015, . 246 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 247 S. Ray, "North-Bound Distribution of Link-State and 248 Traffic Engineering (TE) Information Using BGP", RFC 7752, 249 DOI 10.17487/RFC7752, March 2016, 250 . 252 Authors' Addresses 254 Jeff Tantsura 255 Individual 257 Email: jefftant.ietf@gmail.com 259 Uma Chunduri 260 Individual 262 Email: uma.chunduri@gmail.com