| < draft-ietf-ospf-segment-routing-msd-04.txt | draft-ietf-ospf-segment-routing-msd-05.txt > | |||
|---|---|---|---|---|
| OSPF Working Group J. Tantsura | OSPF Working Group J. Tantsura | |||
| Internet-Draft Individual | Internet-Draft Individual | |||
| Intended status: Standards Track U. Chunduri | Intended status: Standards Track U. Chunduri | |||
| Expires: September 29, 2017 Huawei Technologies | Expires: December 6, 2017 Huawei Technologies | |||
| S. Aldrin | S. Aldrin | |||
| Google, Inc | Google, Inc | |||
| P. Psenak | P. Psenak | |||
| Cisco Systems | Cisco Systems | |||
| March 28, 2017 | June 04, 2017 | |||
| Signaling MSD (Maximum SID Depth) using OSPF | Signaling MSD (Maximum SID Depth) using OSPF | |||
| draft-ietf-ospf-segment-routing-msd-04 | draft-ietf-ospf-segment-routing-msd-05 | |||
| Abstract | Abstract | |||
| This document proposes a way to signal Maximum SID Depth (MSD) | This document proposes a way to signal Maximum SID Depth (MSD) | |||
| supported by a node at node and/or link granularity by an OSPF | supported by a node at node and/or link granularity by an OSPF | |||
| Router. In a Segment Routing (SR) enabled network a centralized | Router. In a Segment Routing (SR) enabled network a centralized | |||
| controller that programs SR tunnels needs to know the MSD supported | controller that programs SR tunnels needs to know the MSD supported | |||
| by the head-end at node and/or link granularity to push the SID stack | by the head-end at node and/or link granularity to push the SID stack | |||
| of an appropriate depth. MSD is relevant to the head-end of a SR | of an appropriate depth. MSD is relevant to the head-end of a SR | |||
| tunnel or Binding-SID anchor node where Binding-SID expansions might | tunnel or Binding-SID anchor node where Binding-SID expansions might | |||
| skipping to change at page 1, line 43 ¶ | skipping to change at page 1, line 43 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on September 29, 2017. | This Internet-Draft will expire on December 6, 2017. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2017 IETF Trust and the persons identified as the | Copyright (c) 2017 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| skipping to change at page 3, line 18 ¶ | skipping to change at page 3, line 18 ¶ | |||
| [I-D.ietf-ospf-mpls-elc] defines Readable Label Depth Capability | [I-D.ietf-ospf-mpls-elc] defines Readable Label Depth Capability | |||
| (RLDC) that is used by a head-end to insert Entropy Label (EL) at | (RLDC) that is used by a head-end to insert Entropy Label (EL) at | |||
| appropriate depth, so it could be read by transit nodes. MSD in | appropriate depth, so it could be read by transit nodes. MSD in | |||
| contrary signals ability to push SID's stack of a particular depth. | contrary signals ability to push SID's stack of a particular depth. | |||
| MSD of type 1 (IANA Registry), called Base MSD is used to signal the | MSD of type 1 (IANA Registry), called Base MSD is used to signal the | |||
| total number of SIDs a node is capable of imposing, to be used by a | total number of SIDs a node is capable of imposing, to be used by a | |||
| path computation element/controller. In case, there are additional | path computation element/controller. In case, there are additional | |||
| labels (e.g. service) that are to be pushed to the stack - this would | labels (e.g. service) that are to be pushed to the stack - this would | |||
| be signaled with an another MSD type (TBD), MSD SHOULD be adjusted to | be signaled with an another MSD type (TBD), no adjustment to the Base | |||
| reflect that. In the future, new MSD types could be defined to | MSD should be made. In the future, new MSD types could be defined to | |||
| signal additional capabilities: entropy labels, labels that can be | signal additional capabilities: entropy labels, labels that can be | |||
| pushed thru recirculation, or another dataplane e.g IPv6. | pushed thru recirculation, or another dataplane e.g IPv6. | |||
| 1.1. Conventions used in this document | 1.1. Conventions used in this document | |||
| 1.1.1. Terminology | 1.1.1. Terminology | |||
| BGP-LS: Distribution of Link-State and TE Information using Border | BGP-LS: Distribution of Link-State and TE Information using Border | |||
| Gateway Protocol | Gateway Protocol | |||
| skipping to change at page 7, line 25 ¶ | skipping to change at page 7, line 25 ¶ | |||
| 10.2. Informative References | 10.2. Informative References | |||
| [I-D.ietf-ospf-mpls-elc] | [I-D.ietf-ospf-mpls-elc] | |||
| Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. | Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. | |||
| Litkowski, "Signaling Entropy Label Capability Using | Litkowski, "Signaling Entropy Label Capability Using | |||
| OSPF", draft-ietf-ospf-mpls-elc-04 (work in progress), | OSPF", draft-ietf-ospf-mpls-elc-04 (work in progress), | |||
| November 2016. | November 2016. | |||
| [I-D.ietf-ospf-ospfv3-lsa-extend] | [I-D.ietf-ospf-ospfv3-lsa-extend] | |||
| Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 | Lindem, A., Roy, A., Goethals, D., Vallem, V., and F. | |||
| LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-13 | Baker, "OSPFv3 LSA Extendibility", draft-ietf-ospf-ospfv3- | |||
| (work in progress), October 2016. | lsa-extend-14 (work in progress), April 2017. | |||
| [I-D.ietf-pce-segment-routing] | [I-D.ietf-pce-segment-routing] | |||
| Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., | Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., | |||
| Raszuk, R., Lopez, V., Tantsura, J., Henderickx, W., and | and J. Hardwick, "PCEP Extensions for Segment Routing", | |||
| J. Hardwick, "PCEP Extensions for Segment Routing", draft- | draft-ietf-pce-segment-routing-09 (work in progress), | |||
| ietf-pce-segment-routing-08 (work in progress), October | April 2017. | |||
| 2016. | ||||
| [I-D.tantsura-idr-bgp-ls-segment-routing-msd] | [I-D.tantsura-idr-bgp-ls-segment-routing-msd] | |||
| Tantsura, J., Chunduri, U., Mirsky, G., and S. Sivabalan, | Tantsura, J., Chunduri, U., Mirsky, G., and S. Sivabalan, | |||
| "Signaling Maximum SID Depth using Border Gateway Protocol | "Signaling Maximum SID Depth using Border Gateway Protocol | |||
| Link-State", draft-tantsura-idr-bgp-ls-segment-routing- | Link-State", draft-tantsura-idr-bgp-ls-segment-routing- | |||
| msd-03 (work in progress), March 2017. | msd-04 (work in progress), March 2017. | |||
| [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and | [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and | |||
| R. Aggarwal, "Support of Address Families in OSPFv3", | R. Aggarwal, "Support of Address Families in OSPFv3", | |||
| RFC 5838, DOI 10.17487/RFC5838, April 2010, | RFC 5838, DOI 10.17487/RFC5838, April 2010, | |||
| <http://www.rfc-editor.org/info/rfc5838>. | <http://www.rfc-editor.org/info/rfc5838>. | |||
| [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., | [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., | |||
| Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute | Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute | |||
| Advertisement", RFC 7684, DOI 10.17487/RFC7684, November | Advertisement", RFC 7684, DOI 10.17487/RFC7684, November | |||
| 2015, <http://www.rfc-editor.org/info/rfc7684>. | 2015, <http://www.rfc-editor.org/info/rfc7684>. | |||
| End of changes. 8 change blocks. | ||||
| 15 lines changed or deleted | 14 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||