idnits 2.17.1 draft-tantsura-ospf-segment-routing-msd-01.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 (September 26, 2016) is 2768 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-02 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-lsa-extend-10 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-07 -- 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: March 30, 2017 September 26, 2016 7 Signaling MSD (Maximum SID Depth) using OSPF 8 draft-tantsura-ospf-segment-routing-msd-01 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 March 30, 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. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 66 8.2. Informative References . . . . . . . . . . . . . . . . . 5 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 When Segment Routing tunnels are computed by a centralized 72 controller, it is crucial that the controller knows the MSD "Maximum 73 SID Depth" of the node or link SR tunnel exits over, so it doesn't 74 download a path with SID (label stack) of a depth more than the node 75 or link used is capable of imposing. This document describes how to 76 use OSPF to expose the MSD of the node or link to a centralized 77 controller. 79 PCEP SR extensions [I-D.ietf-pce-segment-routing] has defined MSD, to 80 signal in SR PCE Capability TLV, METRIC Object. However, If PCEP is 81 not supported by a node (head-end of the SR tunnel) and controller 82 does not participate in IGP routing it has no way to learn the MSD of 83 the node or link configured. BGP-LS [RFC7752] defines a way to 84 expose topology and associated different attributes, capabilities of 85 the nodes in that topology to a centralized controller and MSD has 86 been defined in [I-D.tantsura-bgp-ls-segment-routing-msd]. For this 87 information to be advertised by BGP for the all nodes and links of 88 the network, where this is provisioned, OSPF module should have this 89 information in the LSDB. 91 [I-D.ietf-ospf-mpls-elc] defines, RLSDC which indicates how many 92 labels a node can read to take a decision to insert an Entropy Label 93 (EL) and is different than how many labels a node can push as defined 94 by MSD in this draft. 96 1.1. Conventions used in this document 98 1.1.1. Terminology 100 BGP-LS: Distribution of Link-State and TE Information using Border 101 Gateway Protocol 103 OSPF: Open Shortest Path First 105 MSD: Maximum SID Depth 107 PCC: Path Computation Client 109 PCE: Path Computation Element 111 PCEP: Path Computation Element Protocol 113 SID: Segment Identifier 115 SR: Segment routing 117 1.2. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 2. Terminology 125 This memo makes use of the terms defined in [RFC4970]. 127 3. Node MSD TLV 129 A new TLV within the body of the OSPF RI Opaque LSA, called Node MSD 130 TLV is defined to carry the provisioned SID depth of the router 131 originating the RI LSA. Node MSD is the lowest MSD supported by the 132 node. 134 The Type (2 bytes) of this TLV is TBD. 136 Length is 2 bytes, and 138 the Value field contains MSD of the router originating the RI LSA. 139 Node MSD is a number in the range of 0-254. 0 represents lack of the 140 ability to push MSD of any depth; any other value represents that of 141 the node. This value SHOULD represent the lowest value supported by 142 node. 144 This TLV is applicable to OSPFv2 and to OSPFv3 [RFC5838] and is 145 optional. The scope of the advertisement is specific to the 146 deployment. 148 4. LINK MSD sub-TLV 150 A new sub-TLV called Link MSD sub-TLV is defined to carry the 151 provisioned SID depth of the interface associated with the link. 153 The Type (2 bytes) of this TLV is TBD. 155 Length is 2 bytes, and 157 the Value field contains Link MSD of the router originating the 158 corresponding LSA as specified for OSPFv3 and OSPFv3. Link MSD is a 159 number in the range of 0-254. 0 represents lack of the ability to 160 push MSD of any depth; any other value represents that of the 161 particular link MSD value. 163 For OSPFv2, the Link level MSD value is advertised as an optional 164 Sub-TLV of OSPFv2 Extended Link TLV as defined in [RFC7684]. 166 For OSPFv3, the Link level MSD value is advertised as an optional 167 Sub-TLV of the Router-Link TLV as defined in 168 [I-D.ietf-ospf-ospfv3-lsa-extend]. 170 5. Acknowledgements 172 TBD 174 6. IANA Considerations 176 This document includes a request to IANA to allocate TLV type codes 177 for the new TLV proposed in Section 3 of this document from OSPF 178 Router Information (RI) TLVs Registry as defined by [RFC4970]. Also 179 for link MSD, we request IANA to allocate new sub-TLV codes as 180 proposed in Section 4 from OSPFv2 Extended Link Opaque LSAs Extended 181 Link TLV registry and from Router-Link TLV defined in OSPFv3 Extend- 182 LSA Sub-TLV registry. 184 7. Security Considerations 186 This document describes a mechanism for advertising Segment Routing 187 SID depth supported at node and link level information through OSPF 188 LSAs and does not introduce any new security issues. 190 8. References 192 8.1. Normative References 194 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 195 Requirement Levels", BCP 14, RFC 2119, 196 DOI 10.17487/RFC2119, March 1997, 197 . 199 [RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 200 S. Shaffer, "Extensions to OSPF for Advertising Optional 201 Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July 202 2007, . 204 8.2. Informative References 206 [I-D.ietf-ospf-mpls-elc] 207 Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. 208 Litkowski, "Signaling Entropy Label Capability Using 209 OSPF", draft-ietf-ospf-mpls-elc-02 (work in progress), May 210 2016. 212 [I-D.ietf-ospf-ospfv3-lsa-extend] 213 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 214 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-10 215 (work in progress), May 2016. 217 [I-D.ietf-pce-segment-routing] 218 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., 219 Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick, 220 "PCEP Extensions for Segment Routing", draft-ietf-pce- 221 segment-routing-07 (work in progress), March 2016. 223 [I-D.tantsura-bgp-ls-segment-routing-msd] 224 Tantsura, J., Mirsky, G., Sivabalan, S., and U. Chunduri, 225 "Signaling Maximum SID Depth using Border Gateway Protocol 226 Link-State", draft-tantsura-bgp-ls-segment-routing-msd-02 227 (work in progress), January 2016. 229 [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and 230 R. Aggarwal, "Support of Address Families in OSPFv3", 231 RFC 5838, DOI 10.17487/RFC5838, April 2010, 232 . 234 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 235 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 236 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 237 2015, . 239 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 240 S. Ray, "North-Bound Distribution of Link-State and 241 Traffic Engineering (TE) Information Using BGP", RFC 7752, 242 DOI 10.17487/RFC7752, March 2016, 243 . 245 Authors' Addresses 247 Jeff Tantsura 248 Individual 250 Email: jefftant.ietf@gmail.com 252 Uma Chunduri 253 Individual 255 Email: uma.chunduri@gmail.com