idnits 2.17.1 draft-tantsura-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 (March 8, 2016) is 2970 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-01 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-lsa-extend-09 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-06 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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 Ericsson 5 Expires: September 9, 2016 March 8, 2016 7 Signaling MSD (Maximum SID Depth) using OSPF 8 draft-tantsura-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 September 9, 2016. 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 [I-D.ietf-idr-ls-distribution] 84 defines a way to expose topology and associated different attributes, 85 capabilities of the nodes in that topology to a centralized 86 controller and MSD has been defined in 87 [I-D.tantsura-bgp-ls-segment-routing-msd]. For this information to 88 be advertised by BGP for the all nodes and links of the network, 89 where this is provisioned, OSPF module should have this information 90 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. Acknowledgements 173 TBD 175 6. IANA Considerations 177 This document includes a request to IANA to allocate TLV type codes 178 for the new TLV proposed in Section 3 of this document from OSPF 179 Router Information (RI) TLVs Registry as defined by [RFC4970]. Also 180 for link MSD, we request IANA to allocate new sub-TLV codes as 181 proposed in Section 4 from OSPFv2 Extended Link Opaque LSAs Extended 182 Link TLV registry and from Router-Link TLV defined in OSPFv3 Extend- 183 LSA Sub-TLV registry. 185 7. Security Considerations 187 This document describes a mechanism for advertising Segment Routing 188 SID depth supported at node and link level information through OSPF 189 LSAs and does not introduce any new security issues. 191 8. References 193 8.1. Normative References 195 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 196 Requirement Levels", BCP 14, RFC 2119, 197 DOI 10.17487/RFC2119, March 1997, 198 . 200 [RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 201 S. Shaffer, "Extensions to OSPF for Advertising Optional 202 Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July 203 2007, . 205 8.2. Informative References 207 [I-D.ietf-idr-ls-distribution] 208 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 209 Ray, "North-Bound Distribution of Link-State and TE 210 Information using BGP", draft-ietf-idr-ls-distribution-13 211 (work in progress), October 2015. 213 [I-D.ietf-ospf-mpls-elc] 214 Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. 215 Litkowski, "Signaling Entropy Label Capability Using 216 OSPF", draft-ietf-ospf-mpls-elc-01 (work in progress), 217 November 2015. 219 [I-D.ietf-ospf-ospfv3-lsa-extend] 220 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 221 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-09 222 (work in progress), November 2015. 224 [I-D.ietf-pce-segment-routing] 225 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., 226 Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick, 227 "PCEP Extensions for Segment Routing", draft-ietf-pce- 228 segment-routing-06 (work in progress), August 2015. 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 Authors' Addresses 248 Jeff Tantsura 249 Ericsson 251 Email: jeff.tantsura@ericsson.com 253 Uma Chunduri 254 Ericsson 256 Email: uma.chunduri@ericsson.com