| < draft-ietf-ospf-segment-routing-msd-01.txt | draft-ietf-ospf-segment-routing-msd-02.txt > | |||
|---|---|---|---|---|
| skipping to change at page 1, line 14 ¶ | skipping to change at page 1, line 14 ¶ | |||
| Internet-Draft Individual | Internet-Draft Individual | |||
| Intended status: Standards Track U. Chunduri | Intended status: Standards Track U. Chunduri | |||
| Expires: September 9, 2017 Huawei Technologies | Expires: September 9, 2017 Huawei Technologies | |||
| S. Aldrin | S. Aldrin | |||
| Google, Inc | Google, Inc | |||
| P. Psenak | P. Psenak | |||
| Cisco Systems | Cisco Systems | |||
| March 8, 2017 | March 8, 2017 | |||
| Signaling MSD (Maximum SID Depth) using OSPF | Signaling MSD (Maximum SID Depth) using OSPF | |||
| draft-ietf-ospf-segment-routing-msd-01 | draft-ietf-ospf-segment-routing-msd-02 | |||
| 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 2, line 20 ¶ | skipping to change at page 2, line 20 ¶ | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | described in the Simplified BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 1.1. Conventions used in this document . . . . . . . . . . . . 3 | 1.1. Conventions used in this document . . . . . . . . . . . . 3 | |||
| 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 | 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 | 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 3. Node MSD TLV . . . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Node MSD TLV . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 4. LINK MSD sub-TLV . . . . . . . . . . . . . . . . . . . . . . 5 | 4. LINK MSD sub-TLV . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 5. Node MSD vs Link MSD conflict resolution . . . . . . . . . . 6 | 5. Node MSD vs Link MSD conflict resolution . . . . . . . . . . 5 | |||
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 | |||
| 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 | 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 | |||
| 10.2. Informative References . . . . . . . . . . . . . . . . . 7 | 10.2. Informative References . . . . . . . . . . . . . . . . . 7 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 1. Introduction | 1. Introduction | |||
| When Segment Routing tunnels are computed by a centralized | When Segment Routing tunnels are computed by a centralized | |||
| controller, it is critical that the controller learns the MSD | controller, it is critical that the controller learns the MSD | |||
| "Maximum SID Depth" of the node or link SR tunnel exits over, so the | "Maximum SID Depth" of the node or link SR tunnel exits over, so the | |||
| SID stack depth of a path computed doesn't exceed the number of SIDs | SID stack depth of a path computed doesn't exceed the number of SIDs | |||
| skipping to change at page 3, line 24 ¶ | skipping to change at page 3, line 24 ¶ | |||
| MSD of type 1 (IANA Registry) is used to signal the number of SIDs a | MSD of type 1 (IANA Registry) is used to signal the number of SIDs a | |||
| node is capable of imposing, to be used by a path computation | node is capable of imposing, to be used by a path computation | |||
| element/controller and is only relevant to the part of the stack | element/controller and is only relevant to the part of the stack | |||
| created as the result of the computation. In case, there are | created as the result of the computation. In case, there are | |||
| additional labels (e.g. service) that are to be pushed to the stack - | additional labels (e.g. service) that are to be pushed to the stack - | |||
| MSD SHOULD be adjusted to reflect that. In the future, new MSD types | MSD SHOULD be adjusted to reflect that. In the future, new MSD types | |||
| could be defined to signal additional capabilities: entropy labels, | could be defined to signal additional capabilities: entropy labels, | |||
| labels that can be pushed thru recirculation, or another dataplane | labels that can be pushed thru recirculation, or another dataplane | |||
| e.g IPv6. | e.g IPv6. | |||
| [I-D.ietf-ospf-mpls-elc] defines, RLDC which indicates how many | ||||
| labels a node can read to take a decision to insert an Entropy Label | ||||
| (EL) and is different than how many labels a node can push as defined | ||||
| by MSD in this draft. | ||||
| 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 | |||
| OSPF: Open Shortest Path First | OSPF: Open Shortest Path First | |||
| MSD: Maximum SID Depth | MSD: Maximum SID Depth | |||
| End of changes. 5 change blocks. | ||||
| 9 lines changed or deleted | 4 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/ | ||||