| < draft-ietf-ospf-segment-routing-extensions-00.txt | draft-ietf-ospf-segment-routing-extensions-01.txt > | |||
|---|---|---|---|---|
| Open Shortest Path First IGP P. Psenak, Ed. | Open Shortest Path First IGP P. Psenak, Ed. | |||
| Internet-Draft S. Previdi, Ed. | Internet-Draft S. Previdi, Ed. | |||
| Intended status: Standards Track C. Filsfils | Intended status: Standards Track C. Filsfils | |||
| Expires: December 21, 2014 Cisco Systems, Inc. | Expires: January 4, 2015 Cisco Systems, Inc. | |||
| H. Gredler | H. Gredler | |||
| Juniper Networks, Inc. | Juniper Networks, Inc. | |||
| R. Shakir | R. Shakir | |||
| British Telecom | British Telecom | |||
| W. Henderickx | W. Henderickx | |||
| Alcatel-Lucent | Alcatel-Lucent | |||
| J. Tantsura | J. Tantsura | |||
| Ericsson | Ericsson | |||
| June 19, 2014 | July 3, 2014 | |||
| OSPF Extensions for Segment Routing | OSPF Extensions for Segment Routing | |||
| draft-ietf-ospf-segment-routing-extensions-00 | draft-ietf-ospf-segment-routing-extensions-01 | |||
| Abstract | Abstract | |||
| Segment Routing (SR) allows for a flexible definition of end-to-end | Segment Routing (SR) allows for a flexible definition of end-to-end | |||
| paths within IGP topologies by encoding paths as sequences of | paths within IGP topologies by encoding paths as sequences of | |||
| topological sub-paths, called "segments". These segments are | topological sub-paths, called "segments". These segments are | |||
| advertised by the link-state routing protocols (IS-IS and OSPF). | advertised by the link-state routing protocols (IS-IS and OSPF). | |||
| This draft describes the necessary OSPF extensions that need to be | This draft describes the OSPF extensions required for Segment | |||
| introduced for Segment Routing. | Routing. | |||
| Requirements Language | Requirements Language | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in RFC 2119 [RFC2119]. | document are to be interpreted as described in RFC 2119 [RFC2119]. | |||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| skipping to change at page 2, line 4 ¶ | skipping to change at page 2, line 4 ¶ | |||
| 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 December 21, 2014. | This Internet-Draft will expire on January 4, 2015. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2014 IETF Trust and the persons identified as the | Copyright (c) 2014 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 2, line 29 ¶ | skipping to change at page 2, line 29 ¶ | |||
| described in the Simplified BSD License. | described in the Simplified BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 3 | 2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 3 | |||
| 2.1. SID/Label sub-TLV . . . . . . . . . . . . . . . . . . . . 4 | 2.1. SID/Label sub-TLV . . . . . . . . . . . . . . . . . . . . 4 | |||
| 3. Segment Routing Capabilities . . . . . . . . . . . . . . . . 4 | 3. Segment Routing Capabilities . . . . . . . . . . . . . . . . 4 | |||
| 3.1. SR-Algorithm TLV . . . . . . . . . . . . . . . . . . . . 4 | 3.1. SR-Algorithm TLV . . . . . . . . . . . . . . . . . . . . 4 | |||
| 3.2. SID/Label Range TLV . . . . . . . . . . . . . . . . . . . 5 | 3.2. SID/Label Range TLV . . . . . . . . . . . . . . . . . . . 5 | |||
| 4. OSPFv2 Extended Prefix Opaque LSA type . . . . . . . . . . . 7 | 4. OSPFv2 Extended Prefix Opaque LSA . . . . . . . . . . . . . . 7 | |||
| 4.1. OSPF Extended Prefix TLV . . . . . . . . . . . . . . . . 8 | 4.1. OSPF Extended Prefix TLV . . . . . . . . . . . . . . . . 8 | |||
| 4.2. Prefix SID Sub-TLV . . . . . . . . . . . . . . . . . . . 9 | 4.2. Prefix SID Sub-TLV . . . . . . . . . . . . . . . . . . . 9 | |||
| 4.3. SID/Label Binding sub-TLV . . . . . . . . . . . . . . . . 13 | 4.3. SID/Label Binding sub-TLV . . . . . . . . . . . . . . . . 13 | |||
| 4.3.1. ERO Metric sub-TLV . . . . . . . . . . . . . . . . . 15 | 4.3.1. ERO Metric sub-TLV . . . . . . . . . . . . . . . . . 15 | |||
| 4.3.2. ERO sub-TLVs . . . . . . . . . . . . . . . . . . . . 15 | 4.3.2. ERO sub-TLVs . . . . . . . . . . . . . . . . . . . . 15 | |||
| 5. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . . . 20 | 5. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . . . 20 | |||
| 5.1. OSPFv2 Extended Link Opaque LSA . . . . . . . . . . . . . 20 | 5.1. OSPFv2 Extended Link Opaque LSA . . . . . . . . . . . . . 20 | |||
| 5.2. OSPFv2 Extended Link TLV . . . . . . . . . . . . . . . . 21 | 5.2. OSPFv2 Extended Link TLV . . . . . . . . . . . . . . . . 21 | |||
| 5.3. Adj-SID sub-TLV . . . . . . . . . . . . . . . . . . . . . 22 | 5.3. Adj-SID sub-TLV . . . . . . . . . . . . . . . . . . . . . 21 | |||
| 5.4. LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 23 | 5.4. LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 23 | |||
| 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 25 | 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 24 | |||
| 6.1. Intra-area Segment routing in OSPFv2 . . . . . . . . . . 25 | 6.1. Intra-area Segment routing in OSPFv2 . . . . . . . . . . 24 | |||
| 6.2. Inter-area Segment routing in OSPFv2 . . . . . . . . . . 25 | 6.2. Inter-area Segment routing in OSPFv2 . . . . . . . . . . 25 | |||
| 6.3. SID for External Prefixes . . . . . . . . . . . . . . . . 26 | 6.3. SID for External Prefixes . . . . . . . . . . . . . . . . 26 | |||
| 6.4. Advertisement of Adj-SID . . . . . . . . . . . . . . . . 27 | 6.4. Advertisement of Adj-SID . . . . . . . . . . . . . . . . 26 | |||
| 6.4.1. Advertisement of Adj-SID on Point-to-Point Links . . 27 | 6.4.1. Advertisement of Adj-SID on Point-to-Point Links . . 26 | |||
| 6.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 27 | 6.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 27 | |||
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 | |||
| 7.1. OSPF Extend Prefix LSA TLV Registry . . . . . . . . . . . 28 | 7.1. OSPF Extend Prefix LSA TLV Registry . . . . . . . . . . . 27 | |||
| 7.2. OSPF Extend Prefix LSA sub-TLV Registry . . . . . . . . . 28 | 7.2. OSPF Extend Prefix LSA sub-TLV Registry . . . . . . . . . 28 | |||
| 7.3. OSPF Extend Link LSA TLV Registry . . . . . . . . . . . . 29 | 7.3. OSPF Extend Link LSA TLV Registry . . . . . . . . . . . . 29 | |||
| 7.4. OSPF Extend Link LSA sub-TLV Registry . . . . . . . . . . 29 | 7.4. OSPF Extend Link LSA sub-TLV Registry . . . . . . . . . . 29 | |||
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 | |||
| 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 | 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
| 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 | |||
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
| 11.1. Normative References . . . . . . . . . . . . . . . . . . 30 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 30 | |||
| 11.2. Informative References . . . . . . . . . . . . . . . . . 31 | 11.2. Informative References . . . . . . . . . . . . . . . . . 31 | |||
| skipping to change at page 3, line 23 ¶ | skipping to change at page 3, line 23 ¶ | |||
| 1. Introduction | 1. Introduction | |||
| Segment Routing (SR) allows for a flexible definition of end-to-end | Segment Routing (SR) allows for a flexible definition of end-to-end | |||
| paths within IGP topologies by encoding paths as sequences of | paths within IGP topologies by encoding paths as sequences of | |||
| topological sub-paths, called "segments". These segments are | topological sub-paths, called "segments". These segments are | |||
| advertised by the link-state routing protocols (IS-IS and OSPF). | advertised by the link-state routing protocols (IS-IS and OSPF). | |||
| Prefix segments represent an ecmp-aware shortest-path to a prefix (or | Prefix segments represent an ecmp-aware shortest-path to a prefix (or | |||
| a node), as per the state of the IGP topology. Adjacency segments | a node), as per the state of the IGP topology. Adjacency segments | |||
| represent a hop over a specific adjacency between two nodes in the | represent a hop over a specific adjacency between two nodes in the | |||
| IGP. A prefix segment is typically a multi-hop path while an | IGP. A prefix segment is typically a multi-hop path while an | |||
| adjacency segment, in most of the cases, is a one-hop path. SR's | adjacency segment, in most cases, is a one-hop path. SR's control- | |||
| control-plane can be applied to both IPv6 and MPLS data-planes, and | plane can be applied to both IPv6 and MPLS data-planes, and does not | |||
| do not require any additional signaling (other than the regular IGP). | require any additional signalling (other than IGP extensions). For | |||
| For example, when used in MPLS networks, SR paths do not require any | example, when used in MPLS networks, SR paths do not require any LDP | |||
| LDP or RSVP-TE signaling. Still, SR can interoperate in the presence | or RSVP-TE signalling. However, SR can interoperate in the presence | |||
| of LSPs established with RSVP or LDP . | of LSPs established with RSVP or LDP. | |||
| This draft describes the necessary OSPF extensions that need to be | This draft describes the OSPF extensions required for Segment | |||
| introduced for Segment Routing. | Routing. | |||
| Segment Routing architecture is described in | Segment Routing architecture is described in | |||
| [I-D.filsfils-rtgwg-segment-routing]. | [I-D.filsfils-rtgwg-segment-routing]. | |||
| Segment Routing use cases are described in | Segment Routing use cases are described in | |||
| [I-D.filsfils-rtgwg-segment-routing-use-cases]. | [I-D.filsfils-rtgwg-segment-routing-use-cases]. | |||
| 2. Segment Routing Identifiers | 2. Segment Routing Identifiers | |||
| Segment Routing defines various types of Segment Identifiers (SIDs): | Segment Routing defines various types of Segment Identifiers (SIDs): | |||
| Prefix-SID, Adjacency-SID, LAN Adjacency SID and Binding SID. | Prefix-SID, Adjacency-SID, LAN Adjacency SID and Binding SID. | |||
| For the purpose of the advertisements of various SID values new | For the purpose of the advertisements of various SID values, new | |||
| Opaque LSAs (defined in [RFC5250]) are defined. These new LSAs are | Opaque LSAs (defined in [RFC5250]) are defined. These new LSAs are | |||
| defined as generic containers that can be used in order to advertise | defined as generic containers that can be used to advertise any | |||
| any additional attributes associated with the prefix or link. These | additional attributes associated with the prefix or link. These new | |||
| new Opaque LSAs are complementary to the existing LSAs and are not | Opaque LSAs are complementary to the existing LSAs and are not aimed | |||
| aimed to replace any of the existing LSAs. | to replace any of the existing LSAs. | |||
| 2.1. SID/Label sub-TLV | 2.1. SID/Label sub-TLV | |||
| SID/Label sub-TLV appears in multiple TLVs or sub-TLVs defined later | SID/Label sub-TLV appears in multiple TLVs or sub-TLVs defined later | |||
| in this document. It is used to advertise SID or label associated | in this document. It is used to advertise SID or label associated | |||
| with the prefix or adjacency. SID/Label TLV has following format: | with the prefix or adjacency. SID/Label TLV has following format: | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| skipping to change at page 4, line 34 ¶ | skipping to change at page 4, line 34 ¶ | |||
| SID/Label: if length is set to 3, then the 20 rightmost bits | SID/Label: if length is set to 3, then the 20 rightmost bits | |||
| represent a label. If length is set to 4 then the value | represent a label. If length is set to 4 then the value | |||
| represents a 32 bit SID. | represents a 32 bit SID. | |||
| The receiving router MUST ignore SID/Label sub-TLV if the length | The receiving router MUST ignore SID/Label sub-TLV if the length | |||
| is other then 3 or 4. | is other then 3 or 4. | |||
| 3. Segment Routing Capabilities | 3. Segment Routing Capabilities | |||
| Segment Routing requires some additional capabilities of the router | Segment Routing requires some additional router capabilities to be | |||
| to be advertised to other routers in the area. | advertised to other routers in the area. | |||
| These SR capabilities are advertised in Router Information Opaque LSA | These SR capabilities are advertised in the Router Information Opaque | |||
| (defined in [RFC4970]). | LSA (defined in [RFC4970]). | |||
| 3.1. SR-Algorithm TLV | 3.1. SR-Algorithm TLV | |||
| SR-Algorithm TLV is a TLV of Router Information Opaque LSA (defined | SR-Algorithm TLV is a top-level TLV of the Router Information Opaque | |||
| in [RFC4970]). | LSA (defined in [RFC4970]). | |||
| The SR-Algorithm Sub-TLV is optional, it MAY only appear once inside | The SR-Algorithm Sub-TLV is optional, it MAY only appear once inside | |||
| the Router Informational Opaque LSA. If the SID/Label Range TLV, as | the Router Informational Opaque LSA. If the SID/Label Range TLV, as | |||
| defined in Section 3.2, is advertised, then SR-Algorithm TLV MUST | defined in Section 3.2, is advertised, then SR-Algorithm TLV MUST | |||
| also be advertised. | also be advertised. | |||
| Router may use various algorithms when calculating reachability to | As SR Router may use various algorithms when calculating reachability | |||
| other nodes in area or to prefixes attached to these nodes. Examples | to OSPF routers or prefixes in an OSPF area. Examples of these | |||
| of these algorithms are metric based Shortest Path First (SPF), | algorithms are metric based Shortest Path First (SPF), various | |||
| various sorts of Constrained SPF, etc. SR-Algorithm TLV allows a | flavors of Constrained SPF, etc. The SR-Algorithm TLV allows a | |||
| router to advertise algorithms that router is currently using to | router to advertise the algorithms that the router is currently using | |||
| other routers in an area. SR-Algorithm TLV has following structure: | to other routers in an OSPF area. The SR-Algorithm TLV has following | |||
| format: | ||||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Type | Length | | | Type | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Algorithm 1 | Algorithm... | Algorithm n | | | | Algorithm 1 | Algorithm... | Algorithm n | | | |||
| +- -+ | +- -+ | |||
| | | | | | | |||
| + + | + + | |||
| where: | where: | |||
| Type: TBD, suggested value 8 | Type: TBD, suggested value 8 | |||
| Length: variable | Length: variable | |||
| Algorithm: one octet identifying the algorithm. The following | Algorithm: Single octet identifying the algorithm. The following | |||
| value has been defined: | value is defined by this document: | |||
| 0: IGP metric based SPT. | 0: IGP metric based Shortest Path Tree (SPT) | |||
| RI LSA can be advertised at any of the defined flooding scopes (link, | The RI LSA can be advertised at any of the defined opaque flooding | |||
| area, or autonomous system (AS)). For the purpose of the SR- | scopes (link, area, or Autonomous System (AS)). For the purpose of | |||
| Algorithm TLV propagation area scope flooding is required. | the SR-Algorithm TLV propagation, area scope flooding is required. | |||
| 3.2. SID/Label Range TLV | 3.2. SID/Label Range TLV | |||
| The SID/Label Range TLV is a TLV of Router Information Opaque LSA | The SID/Label Range TLV is a top-level TLV of Router Information | |||
| (defined in [RFC4970]). | Opaque LSA (defined in [RFC4970]). | |||
| SID/Label Sub-TLV MAY appear multiple times and has following format: | The SID/Label Range TLV MAY appear multiple times and has the | |||
| following format: | ||||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Type | Length | | | Type | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Range Size | Reserved | | | Range Size | Reserved | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Sub-TLVs (variable) | | | Sub-TLVs (variable) | | |||
| +- -+ | +- -+ | |||
| skipping to change at page 6, line 26 ¶ | skipping to change at page 6, line 26 ¶ | |||
| where: | where: | |||
| Type: TBD, suggested value 9 | Type: TBD, suggested value 9 | |||
| Length: variable | Length: variable | |||
| Range Size: 3 octet of the SID/label range | Range Size: 3 octet of the SID/label range | |||
| Currently the only supported Sub-TLV is the SID/Label TLV as defined | Currently the only supported Sub-TLV is the SID/Label TLV as defined | |||
| in Section 2.1. SID/Label advertised in SID/Label TLV represents the | in Section 2.1. The SID/Label advertised in SID/Label TLV represents | |||
| first SID/Label from the advertised range. | the first SID/Label in the advertised range. | |||
| Multiple occurrence of the SID/Label Range TLV MAY be advertised, in | Multiple occurrence of the SID/Label Range TLV MAY be advertised, in | |||
| order to advertise multiple ranges. In such case: | order to advertise multiple ranges. In such case: | |||
| o The originating router MUST encode each range into a different | o The originating router MUST encode each range into a different | |||
| SID/Label Range TLV. | SID/Label Range TLV. | |||
| o The originating router decides in which order the set of SID/Label | o The originating router decides in which order the set of SID/Label | |||
| Range TLVs are advertised inside Router Information Opaque LSA. | Range TLVs are advertised inside Router Information Opaque LSA. | |||
| The originating router MUST ensure the order is same after a | The originating router MUST ensure the order is same after a | |||
| graceful restart (using checkpointing, non-volatile storage or any | graceful restart (using checkpointing, non-volatile storage or any | |||
| other mechanism) in order to guarantee the same order before and | other mechanism) in order to SID/label range and SID index | |||
| after graceful restart. | correspondence is preserved across graceful restarts. | |||
| o Receiving router must adhere to the order in which the ranges are | o The receiving router must adhere to the order in which the ranges | |||
| advertised when calculating a SID/label from the SID index. | are advertised when calculating a SID/label from a SID index. | |||
| Here follows an example of advertisement of multiple ranges: | The following example illustrates the advertisement of multiple | |||
| ranges: | ||||
| The originating router advertises following ranges: | The originating router advertises following ranges: | |||
| Range 1: [100, 199] | Range 1: [100, 199] | |||
| Range 2: [1000, 1099] | Range 2: [1000, 1099] | |||
| Range 3: [500, 599] | Range 3: [500, 599] | |||
| The receiving routers concatenate the ranges and build the SRGB | The receiving routers concatenate the ranges and build the SRGB | |||
| is as follows: | is as follows: | |||
| SRGB = [100, 199] | SRGB = [100, 199] | |||
| skipping to change at page 7, line 28 ¶ | skipping to change at page 7, line 28 ¶ | |||
| index=0 means label 100 | index=0 means label 100 | |||
| ... | ... | |||
| index 99 means label 199 | index 99 means label 199 | |||
| index 100 means label 1000 | index 100 means label 1000 | |||
| index 199 means label 1099 | index 199 means label 1099 | |||
| ... | ... | |||
| index 200 means label 500 | index 200 means label 500 | |||
| ... | ... | |||
| RI LSA can be advertised at any of the defined flooding scopes (link, | The RI LSA can be advertised at any of the defined flooding scopes | |||
| area, or autonomous system (AS)). For the purpose of the SR- | (link, area, or autonomous system (AS)). For the purposes of the SR- | |||
| Capability TLV propagation area scope flooding is required. | Capability TLV propagation, area scope flooding is required. | |||
| 4. OSPFv2 Extended Prefix Opaque LSA type | 4. OSPFv2 Extended Prefix Opaque LSA | |||
| A new Opaque LSA (defined in [RFC5250]) is defined in OSPFv2 in order | A new Opaque LSA (defined in [RFC5250]) is defined in OSPFv2 in order | |||
| to advertise additional prefix attributes: OSPFv2 Extended Prefix | to advertise additional prefix attributes: OSPFv2 Extended Prefix | |||
| Opaque LSA. | Opaque LSA. | |||
| Multiple OSPFv2 Extended Prefix Opaque LSAs can be advertised by a | Multiple OSPFv2 Extended Prefix Opaque LSAs can be advertised by an | |||
| single router. Flooding scope of the OSPFv2 Extended Prefix Opaque | OSPFv2 router. The flooding scope of the OSPFv2 Extended Prefix | |||
| LSA depends on the content inside the LSA and is in control of the | Opaque LSA depends on the scope of the advertised prefixes and is | |||
| originating router. | under the control of the advertising router. In some cases (e.g., | |||
| mapping server deployment), the LSA flooding scope may be greater | ||||
| than the scope of the corresponding prefixes. | ||||
| The format of the OSPFv2 Extended Prefix Opaque LSA is as follows: | The format of the OSPFv2 Extended Prefix Opaque LSA is as follows: | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | LS age | Options | 9, 10, or 11 | | | LS age | Options | 9, 10, or 11 | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Opaque type | Instance | | | Opaque type | Instance | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Advertising Router | | | Advertising Router | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | LS sequence number | | | LS sequence number | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | LS checksum | length | | | LS checksum | length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | | |||
| +- TLVs -+ | +- TLVs -+ | |||
| | ... | | | ... | | |||
| Opaque type used by OSPFv2 Extended Prefix Opaque LSA is 7. | The opaque type used by OSPFv2 Extended Prefix Opaque LSA is 7. | |||
| The format of the TLVs within the body of the LSA is the same as the | The format of the TLVs within the body of the LSA is the same as the | |||
| format used by the Traffic Engineering Extensions to OSPF defined in | format used by the Traffic Engineering Extensions to OSPF defined in | |||
| [RFC3630]. The LSA payload consists of one or more nested | [RFC3630]. The LSA payload consists of one or more nested | |||
| Type/Length/Value (TLV) triplets. The format of each TLV is: | Type/Length/Value (TLV) triplets. The format of each TLV is: | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Type | Length | | | Type | Length | | |||
| skipping to change at page 8, line 46 ¶ | skipping to change at page 8, line 46 ¶ | |||
| The Length field defines the length of the value portion in octets. | The Length field defines the length of the value portion in octets. | |||
| The TLV is padded to 4-octet alignment; padding is not included in | The TLV is padded to 4-octet alignment; padding is not included in | |||
| the length field. Nested TLVs are also 32-bit aligned. Unrecognized | the length field. Nested TLVs are also 32-bit aligned. Unrecognized | |||
| types are ignored. | types are ignored. | |||
| 4.1. OSPF Extended Prefix TLV | 4.1. OSPF Extended Prefix TLV | |||
| The OSPF Extended Prefix TLV is used in order to advertise additional | The OSPF Extended Prefix TLV is used in order to advertise additional | |||
| attributes associated with the prefix. Multiple OSPF Extended Prefix | attributes associated with the prefix. Multiple OSPF Extended Prefix | |||
| TLVs MAY be carried in each OSPFv2 Extended Prefix Opaque LSA, | TLVs MAY be advertised in each OSPFv2 Extended Prefix Opaque LSA but | |||
| however all prefixes included in the single OSPFv2 Extended Prefix | all prefixes included in a single OSPFv2 Extended Prefix Opaque LSA | |||
| Opaque LSA MUST have the same flooding scope. The structure of the | MUST have the same flooding scope. The OSPF Extended Prefix TLV has | |||
| OSPF Extended Prefix TLV is as follows: | the following format: | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Type | Length | | | Type | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Route Type | Prefix Length | AF | Reserved | | | Route Type | Prefix Length | AF | Reserved | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Address Prefix (variable) | | | Address Prefix (variable) | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| skipping to change at page 9, line 32 ¶ | skipping to change at page 9, line 32 ¶ | |||
| Length: variable | Length: variable | |||
| Route type: type of the OSPF route. Supported types are: | Route type: type of the OSPF route. Supported types are: | |||
| 0 - unspecified | 0 - unspecified | |||
| 1 - intra-area | 1 - intra-area | |||
| 3 - inter-area | 3 - inter-area | |||
| 5 - external | 5 - external | |||
| 7 - NSSA external | 7 - NSSA external | |||
| If the route type is 0 (unspecified) the information inside the | If the route type is 0 (unspecified), the information inside the | |||
| OSPF External Prefix TLV applies to the prefix regardless of what | OSPF External Prefix TLV applies to the prefix regardless of | |||
| route-type it is. This is useful when some prefix specific | prefix's route-type. This is useful when some prefix specific | |||
| attributes are advertised by some external entity, which is not | attributes are advertised by some external entity, which is not | |||
| aware of the route-type associated with the prefix. | aware of the route-type associated with the prefix. | |||
| Prefix length: length of the prefix | Prefix length: length of the prefix | |||
| AF: 0 - IPv4 unicast | AF: 0 - IPv4 unicast | |||
| Address Prefix: the prefix itself encoded as an even multiple of | Address Prefix: the prefix itself encoded as an even multiple of | |||
| 32-bit words, padded with zeroed bits as necessary. This encoding | 32-bit words, padded with zeroed bits as necessary. This encoding | |||
| consumes ((PrefixLength + 31) / 32) 32-bit words. The default | consumes ((PrefixLength + 31) / 32) 32-bit words. The default | |||
| skipping to change at page 10, line 25 ¶ | skipping to change at page 10, line 25 ¶ | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| where: | where: | |||
| Type: TBD, suggested value 2. | Type: TBD, suggested value 2. | |||
| Length: variable | Length: variable | |||
| Flags: 1 octet field. The following flags are defined: | Flags: 1 octet field. The following flags are defined: | |||
| 0 | 0 1 2 3 4 5 6 7 | |||
| 0 1 2 3 4 5 6 7 | +--+--+--+--+--+--+--+--+ | |||
| +-+-+-+-+-+-+-+-+ | |N |NP|M |E |V |L | | | | |||
| |N|P|M|E|V|L| | | +--+--+--+--+--+--+--+--+ | |||
| +-+-+-+-+-+-+-+-+ | ||||
| where: | where: | |||
| N-Flag: Node-SID flag. If set, then the Prefix-SID refers to | N-Flag: Node-SID flag. If set, then the Prefix-SID refers to | |||
| the router identified by the prefix. Typically, the N-Flag is | the router identified by the prefix. Typically, the N-Flag is | |||
| set on Prefix-SIDs attached to a router loopback address. The | set on Prefix-SIDs attached to a router loopback address. The | |||
| N-Flag is set when the Prefix-SID is a Node- SID as described | N-Flag is set when the Prefix-SID is a Node-SID, as described | |||
| in [I-D.filsfils-rtgwg-segment-routing]. | in [I-D.filsfils-rtgwg-segment-routing]. | |||
| P-Flag: no-PHP flag. If set, then the penultimate hop MUST NOT | NP-Flag: no-PHP flag. If set, then the penultimate hop MUST | |||
| pop the Prefix-SID before delivering the packet to the node | NOT pop the Prefix-SID before delivering the packet to the node | |||
| that advertised the Prefix-SID. | that advertised the Prefix-SID. | |||
| M-Flag: Mapping Server Flag. If set, the SID is advertised | M-Flag: Mapping Server Flag. If set, the SID is advertised | |||
| from the Segment Routing Mapping Server functionality as | from the Segment Routing Mapping Server functionality as | |||
| described in [I-D.filsfils-rtgwg-segment-routing-use-cases]. | described in [I-D.filsfils-rtgwg-segment-routing]. | |||
| E-Flag: Explicit-Null Flag. If set, any upstream neighbor of | E-Flag: Explicit-Null Flag. If set, any upstream neighbor of | |||
| the Prefix-SID originator MUST replace the Prefix-SID with a | the Prefix-SID originator MUST replace the Prefix-SID with a | |||
| Prefix-SID having an Explicit-NULL value (0 for IPv4) before | Prefix-SID having an Explicit-NULL value (0 for IPv4) before | |||
| forwarding the packet. | forwarding the packet. | |||
| The V-Flag: Value/Index Flag. If set, then the Prefix-SID | The V-Flag: Value/Index Flag. If set, then the Prefix-SID | |||
| carries an absolute value. If not set, then the Prefix-SID | carries an absolute value. If not set, then the Prefix-SID | |||
| carries an index. | carries an index. | |||
| skipping to change at page 12, line 5 ¶ | skipping to change at page 12, line 5 ¶ | |||
| original ordering, when advertising prefix-SIDs to other areas. This | original ordering, when advertising prefix-SIDs to other areas. This | |||
| allows implementations that only use single Prefix-SID to have a | allows implementations that only use single Prefix-SID to have a | |||
| consistent view across areas. | consistent view across areas. | |||
| When calculating the outgoing label for the prefix, the router MUST | When calculating the outgoing label for the prefix, the router MUST | |||
| take into account E and P flags advertised by the next-hop router, if | take into account E and P flags advertised by the next-hop router, if | |||
| next-hop router advertised the SID for the prefix. This MUST be done | next-hop router advertised the SID for the prefix. This MUST be done | |||
| regardless of next-hop router contributing to the best path to the | regardless of next-hop router contributing to the best path to the | |||
| prefix or not. | prefix or not. | |||
| P-Flag (no-PHP) MUST be set on the Prefix-SIDs allocated to inter- | NP-Flag (no-PHP) MUST be set on the Prefix-SIDs allocated to inter- | |||
| area prefixes that are originated by the ABR based on intra-area or | area prefixes that are originated by the ABR based on intra-area or | |||
| inter-area reachability between areas. In case the inter-area prefix | inter-area reachability between areas. In case the inter-area prefix | |||
| is generated based on the prefix which is directly attached to the | is generated based on the prefix which is directly attached to the | |||
| ABR, P-Flag SHOULD NOT be set | ABR, NP-Flag SHOULD NOT be set | |||
| P-Flag (no-PHP) MUST NOT be set on the Prefix-SIDs allocated to | NP-flag (no-PHP) MUST NOT be set on the Prefix-SIDs allocated to | |||
| redistributed prefixes, unless the redistributed prefix is directly | redistributed prefixes, unless the redistributed prefix is directly | |||
| attached to ASBR, in which case the P-Flag SHOULD NOT be set. | attached to ASBR, in which case the NP-flag SHOULD NOT be set. | |||
| If the P-flag is not set then any upstream neighbor of the Prefix-SID | If the NP-flag is not set then any upstream neighbor of the Prefix- | |||
| originator MUST pop the Prefix-SID. This is equivalent to the | SID originator MUST pop the Prefix-SID. This is equivalent to the | |||
| penultimate hop popping mechanism used in the MPLS dataplane. In | penultimate hop popping mechanism used in the MPLS dataplane. In | |||
| such case MPLS EXP bits of the Prefix-SID are not preserved to the | such case MPLS EXP bits of the Prefix-SID are not preserved to the | |||
| ultimate hop (the Prefix-SID being removed). If the P-flag is unset | ultimate hop (the Prefix-SID being removed). If the NP-flag is clear | |||
| the received E-flag is ignored. | the received E-flag is ignored. | |||
| If the P-flag is set then: | If the NP-flag is set then: | |||
| If the E-flag is not set then any upstream neighbor of the Prefix- | If the E-flag is not set then any upstream neighbor of the Prefix- | |||
| SID originator MUST keep the Prefix-SID on top of the stack. This | SID originator MUST keep the Prefix-SID on top of the stack. This | |||
| is useful when the originator of the Prefix-SID must stitch the | is useful when the originator of the Prefix-SID must stitch the | |||
| incoming packet into a continuing MPLS LSP to the final | incoming packet into a continuing MPLS LSP to the final | |||
| destination. This could occur at an inter-area border router | destination. This could occur at an inter-area border router | |||
| (prefix propagation from one area to another) or at an inter- | (prefix propagation from one area to another) or at an inter- | |||
| domain border router (prefix propagation from one domain to | domain border router (prefix propagation from one domain to | |||
| another). | another). | |||
| If the E-flag is set then any upstream neighbor of the Prefix-SID | If the E-flag is set then any upstream neighbor of the Prefix-SID | |||
| originator MUST replace the PrefixSID with a Prefix-SID having an | originator MUST replace the PrefixSID with a Prefix-SID having an | |||
| Explicit-NULL value. This is useful, e.g., when the originator of | Explicit-NULL value. This is useful, e.g., when the originator of | |||
| the Prefix-SID is the final destination for the related prefix and | the Prefix-SID is the final destination for the related prefix and | |||
| the originator wishes to receive the packet with the original EXP | the originator wishes to receive the packet with the original EXP | |||
| bits. | bits. | |||
| When M-Flag is set, P-flag MUST be set and E-bit MUST NOT be set. | When M-Flag is set, NP-flag MUST be set and E-bit MUST NOT be set. | |||
| Example 1: if the following router addresses (loopback addresses) | Example 1: if the following router addresses (loopback addresses) | |||
| need to be mapped into the corresponding Prefix SID indexes: | need to be mapped into the corresponding Prefix SID indexes: | |||
| Router-A: 192.0.2.1/32, Prefix-SID: Index 1 | Router-A: 192.0.2.1/32, Prefix-SID: Index 1 | |||
| Router-B: 192.0.2.2/32, Prefix-SID: Index 2 | Router-B: 192.0.2.2/32, Prefix-SID: Index 2 | |||
| Router-C: 192.0.2.3/32, Prefix-SID: Index 3 | Router-C: 192.0.2.3/32, Prefix-SID: Index 3 | |||
| Router-D: 192.0.2.4/32, Prefix-SID: Index 4 | Router-D: 192.0.2.4/32, Prefix-SID: Index 4 | |||
| then the Prefix field in Extended Prefix TLV would be set to | then the Prefix field in Extended Prefix TLV would be set to | |||
| skipping to change at page 13, line 22 ¶ | skipping to change at page 13, line 22 ¶ | |||
| 10.1.5/24, Prefix-SID: Index 55 | 10.1.5/24, Prefix-SID: Index 55 | |||
| 10.1.6/24, Prefix-SID: Index 56 | 10.1.6/24, Prefix-SID: Index 56 | |||
| 10.1.7/24, Prefix-SID: Index 57 | 10.1.7/24, Prefix-SID: Index 57 | |||
| then the Prefix field in Extended Prefix TLV would be set to | then the Prefix field in Extended Prefix TLV would be set to | |||
| 10.1.1.0, Prefix Length would be set to 24, Range Size in Prefix SID | 10.1.1.0, Prefix Length would be set to 24, Range Size in Prefix SID | |||
| sub-TLV would be 7 and Index value would be set to 51. | sub-TLV would be 7 and Index value would be set to 51. | |||
| 4.3. SID/Label Binding sub-TLV | 4.3. SID/Label Binding sub-TLV | |||
| SID/Label Binding sub-TLV is used to advertise SID/Label mapping for | The SID/Label Binding sub-TLV is used to advertise a SID/Label | |||
| a path to the prefix. | mapping for a path to the prefix. | |||
| The SID/Label Binding TLV MAY be originated by any router in an OSPF | The SID/Label Binding TLV MAY be originated by any router in an OSPF | |||
| domain. The router may advertise a SID/Label binding to a FEC along | domain. The router may advertise a SID/Label binding to a FEC along | |||
| with at least a single 'nexthop style' anchor. The protocol supports | with at least a single 'nexthop style' anchor. The protocol supports | |||
| more than one 'nexthop style' anchor to be attached to a SID/Label | more than one 'nexthop style' anchor to be attached to a SID/Label | |||
| binding, which results into a simple path description language. In | binding, which results in a simple path description language. In | |||
| analogy to RSVP the terminology for this is called an 'Explicit Route | analogy to RSVP, the terminology for this is called an 'Explicit | |||
| Object' (ERO). Since ERO style path notation allows to anchor SID/ | Route Object' (ERO). Since ERO style path notation allows to anchor | |||
| label bindings to both link and node IP addresses any label switched | SID/label bindings to both link and node IP addresses, any label | |||
| path, can be described. Furthermore also SID/Label Bindings from | switched path can be described. Additionally, SID/Label Bindings | |||
| external protocols can get easily re-advertised. | from external protocols can be easily re-advertised. | |||
| The SID/Label Binding TLV may be used for advertising SID/Label | The SID/Label Binding TLV may be used for advertising SID/Label | |||
| Bindings and their associated Primary and Backup paths. In one | Bindings and their associated Primary and Backup paths. In a single | |||
| single TLV either a primary ERO Path, a backup ERO Path or both are | TLV, a primary ERO Path, backup ERO Path, or both can be advertised. | |||
| advertised. If a router wants to advertise multiple parallel paths | If a router wants to advertise multiple parallel paths, then it can | |||
| then it can generate several TLVs for the same Prefix/FEC. Each | generate several TLVs for the same Prefix/FEC. Each occurrence of a | |||
| occurrence of a Binding TLV with respect with a given FEC Prefix has | Binding TLV for a given FEC Prefix will add a new path. | |||
| accumulating and not canceling semantics. | ||||
| SID/Label Binding sub-TLV is as sub-TLV of the OSPF Extended Prefix | The SID/Label Binding sub-TLV is a sub-TLV of the OSPF Extended | |||
| TLV. Multiple SID/Label Binding TLVs can be present in OSPF Extended | Prefix TLV. Multiple SID/Label Binding TLVs can be present in OSPF | |||
| Prefix TLV. SID/Label Binding sub-TLV has following format: | Extended Prefix TLV. The SID/Label Binding sub-TLV has following | |||
| format: | ||||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Type | Length | | | Type | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Flags | Reserved | MT-ID | Weight | | | Flags | Reserved | MT-ID | Weight | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Range Size | Reserved + | | Range Size | Reserved + | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| skipping to change at page 14, line 44 ¶ | skipping to change at page 14, line 44 ¶ | |||
| mirroring context as defined in | mirroring context as defined in | |||
| [I-D.minto-rsvp-lsp-egress-fast-protection]. | [I-D.minto-rsvp-lsp-egress-fast-protection]. | |||
| MT-ID: Multi-Topology ID (as defined in [RFC4915]). | MT-ID: Multi-Topology ID (as defined in [RFC4915]). | |||
| Weight: weight used for load-balancing purposes. The use of the | Weight: weight used for load-balancing purposes. The use of the | |||
| weight is defined in [I-D.filsfils-rtgwg-segment-routing]. | weight is defined in [I-D.filsfils-rtgwg-segment-routing]. | |||
| Range Size: usage is the same as described in Section 4.2. | Range Size: usage is the same as described in Section 4.2. | |||
| SID/Label Binding TLV currently supports following Sub-TLVs: | The SID/Label Binding TLV supports the following Sub-TLVs: | |||
| SID/Label sub-TLV as described in Section 2.1. This sub-TLV MUST | SID/Label sub-TLV as described in Section 2.1. This sub-TLV MUST | |||
| appear in the SID/Label Binding Sub-TLV and it MUST only appear | appear in the SID/Label Binding Sub-TLV and it MUST only appear | |||
| once. | once. | |||
| ERO Metric sub-TLV as defined in Section 4.3.1. | ERO Metric sub-TLV as defined in Section 4.3.1. | |||
| ERO sub-TLVs as defined in Section 4.3.2. | ERO sub-TLVs as defined in Section 4.3.2. | |||
| 4.3.1. ERO Metric sub-TLV | 4.3.1. ERO Metric sub-TLV | |||
| ERO Metric sub-TLV is a Sub-TLV of the SID/Label Binding TLV. | ERO Metric sub-TLV is a Sub-TLV of the SID/Label Binding TLV. | |||
| The ERO Metric sub-TLV carries the cost of an ERO path. It is used | The ERO Metric sub-TLV advertises the cost of an ERO path. It is | |||
| to compare the cost of a given source/destination path. A router | used to compare the cost of a given source/destination path. A | |||
| SHOULD advertise the ERO Metric sub-TLV. The cost of the ERO Metric | router SHOULD advertise the ERO Metric sub-TLV. The cost of the ERO | |||
| sub-TLV SHOULD be set to the cumulative IGP or TE path cost of the | Metric sub-TLV SHOULD be set to the cumulative IGP or TE path cost of | |||
| advertised ERO. Since manipulation of the Metric field may attract | the advertised ERO. Since manipulation of the Metric field may | |||
| or distract traffic from and to the advertised segment it MAY be | attract or repel traffic to and from the advertised segment, it MAY | |||
| manually overridden. | be manually overridden. | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Type | Length | | | Type | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Metric (4 octets) | | | Metric (4 octets) | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| ERO Metric sub-TLV format | ERO Metric sub-TLV format | |||
| skipping to change at page 16, line 5 ¶ | skipping to change at page 16, line 5 ¶ | |||
| closest to the egress point, contrary the first ERO sub-TLV describes | closest to the egress point, contrary the first ERO sub-TLV describes | |||
| the first segment of a path. If a router extends or stitches a path | the first segment of a path. If a router extends or stitches a path | |||
| it MUST prepend the new segments path information to the ERO list. | it MUST prepend the new segments path information to the ERO list. | |||
| The above similarly applies to backup EROs. | The above similarly applies to backup EROs. | |||
| All ERO Sub-TLVs must immediately follow the (SID)/Label Sub-TLV. | All ERO Sub-TLVs must immediately follow the (SID)/Label Sub-TLV. | |||
| All Backup sub-ERO TLVs must immediately follow last ERO Sub-TLV. | All Backup sub-ERO TLVs must immediately follow last ERO Sub-TLV. | |||
| 4.3.2.1. IPv4 ERO subTLV | 4.3.2.1. IPv4 ERO sub-TLV | |||
| IPv4 ERO sub-TLV is a Sub-TLV of the SID/Label Binding sub-TLV. | IPv4 ERO sub-TLV is a sub-TLV of the SID/Label Binding sub-TLV. | |||
| The IPv4 ERO sub-TLV describes a path segment using IPv4 Address | The IPv4 ERO sub-TLV describes a path segment using IPv4 Address | |||
| style of encoding. Its semantics have been borrowed from [RFC3209]. | style of encoding. Its semantics have been borrowed from [RFC3209]. | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Type | Length | | | Type | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Flags | Reserved | | | Flags | Reserved | | |||
| skipping to change at page 16, line 46 ¶ | skipping to change at page 16, line 46 ¶ | |||
| where: | where: | |||
| L-bit - If the L bit is set, then the value of the attribute is | L-bit - If the L bit is set, then the value of the attribute is | |||
| 'loose.' Otherwise, the value of the attribute is 'strict.' | 'loose.' Otherwise, the value of the attribute is 'strict.' | |||
| IPv4 Address - the address of the explicit route hop. | IPv4 Address - the address of the explicit route hop. | |||
| 4.3.2.2. Unnumbered Interface ID ERO sub-TLV | 4.3.2.2. Unnumbered Interface ID ERO sub-TLV | |||
| Unnumbered Interface ID ERO sub-TLV is a Sub-TLV of the SID/Label | Unnumbered Interface ID ERO sub-TLV is a sub-TLV of the SID/Label | |||
| Binding sub-TLV. | Binding sub-TLV. | |||
| The appearance and semantics of the 'Unnumbered Interface ID' have | The appearance and semantics of the 'Unnumbered Interface ID' have | |||
| been borrowed from [RFC3477]. | been borrowed from [RFC3477]. | |||
| The Unnumbered Interface-ID ERO sub-TLV describes a path segment that | The Unnumbered Interface-ID ERO sub-TLV describes a path segment that | |||
| spans over an unnumbered interface. Unnumbered interfaces are | includes an unnumbered interface. Unnumbered interfaces are | |||
| referenced using the interface index. Interface indices are assigned | referenced using the interface index. Interface indices are assigned | |||
| local to the router and therefore not unique within a domain. All | local to the router and therefore not unique within a domain. All | |||
| elements in an ERO path need to be unique within a domain and hence | elements in an ERO path need to be unique within a domain and hence | |||
| need to be disambiguated using a domain unique Router-ID. | need to be disambiguated using a domain unique Router-ID. | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Type | Length | | | Type | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| skipping to change at page 18, line 48 ¶ | skipping to change at page 18, line 48 ¶ | |||
| where: | where: | |||
| L-bit - If the L bit is set, then the value of the attribute is | L-bit - If the L bit is set, then the value of the attribute is | |||
| 'loose.' Otherwise, the value of the attribute is 'strict.' | 'loose.' Otherwise, the value of the attribute is 'strict.' | |||
| IPv4 Address - the address of the explicit route hop. | IPv4 Address - the address of the explicit route hop. | |||
| 4.3.2.4. Unnumbered Interface ID Backup ERO sub-TLV | 4.3.2.4. Unnumbered Interface ID Backup ERO sub-TLV | |||
| Unnumbered Interface ID Backup -sub-TLV is a sub-TLV of the SID/Label | Unnumbered Interface ID Backup sub-TLV is a sub-TLV of the SID/Label | |||
| Binding sub-TLV. | Binding sub-TLV. | |||
| The appearance and semantics of the 'Unnumbered Interface ID' have | The appearance and semantics of the 'Unnumbered Interface ID' have | |||
| been borrowed from [RFC3477]. | been borrowed from [RFC3477]. | |||
| The Unnumbered Interface-ID ERO sub-TLV describes a path segment that | The Unnumbered Interface-ID ERO sub-TLV describes a path segment that | |||
| spans over an unnumbered interface. Unnumbered interfaces are | includes an unnumbered interface. Unnumbered interfaces are | |||
| referenced using the interface index. Interface indices are assigned | referenced using the interface index. Interface indices are assigned | |||
| local to the router and therefore not unique within a domain. All | local to the router and therefore not unique within a domain. All | |||
| elements in an ERO path need to be unique within a domain and hence | elements in an ERO path need to be unique within a domain and hence | |||
| need to be disambiguated using a domain unique Router-ID. | need to be disambiguated using a domain unique Router-ID. | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Type | Length | | | Type | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| skipping to change at page 20, line 8 ¶ | skipping to change at page 20, line 8 ¶ | |||
| 'loose.' Otherwise, the value of the attribute is 'strict.' | 'loose.' Otherwise, the value of the attribute is 'strict.' | |||
| Router-ID: Router-ID of the next-hop. | Router-ID: Router-ID of the next-hop. | |||
| Interface ID: is the identifier assigned to the link by the router | Interface ID: is the identifier assigned to the link by the router | |||
| specified by the Router-ID. | specified by the Router-ID. | |||
| 5. Adjacency Segment Identifier (Adj-SID) | 5. Adjacency Segment Identifier (Adj-SID) | |||
| An Adjacency Segment Identifier (Adj-SID) represents a router | An Adjacency Segment Identifier (Adj-SID) represents a router | |||
| adjacency in Segment Routing. At the current stage of Segment | adjacency in Segment Routing. | |||
| Routing architecture it is assumed that the Adj-SID value has local | ||||
| significance (to the router). | ||||
| 5.1. OSPFv2 Extended Link Opaque LSA | 5.1. OSPFv2 Extended Link Opaque LSA | |||
| A new Opaque LSA (defined in [RFC5250] is defined in OSPFv2 in order | A new Opaque LSA (defined in [RFC5250] is defined in OSPFv2 in order | |||
| to advertise additional link attributes: the OSPFv2 Extended Link | to advertise additional link attributes: the OSPFv2 Extended Link | |||
| Opaque LSA. | Opaque LSA. | |||
| The OSPFv2 Extended Link Opaque LSA has an area flooding scope. | The OSPFv2 Extended Link Opaque LSA has an area flooding scope. | |||
| Multiple OSPFv2 Extended Link Opaque LSAs can be advertised by a | Multiple OSPFv2 Extended Link Opaque LSAs can be advertised by a | |||
| single router in an area. | single router in an area. | |||
| skipping to change at page 21, line 12 ¶ | skipping to change at page 21, line 4 ¶ | |||
| [RFC3630]. The LSA payload consists of one or more nested | [RFC3630]. The LSA payload consists of one or more nested | |||
| Type/Length/Value (TLV) triplets. The format of each TLV is: | Type/Length/Value (TLV) triplets. The format of each TLV is: | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Type | Length | | | Type | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Value... | | | Value... | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| The Length field defines the length of the value portion in octets. | The Length field defines the length of the value portion in octets. | |||
| The TLV is padded to 4-octet alignment; padding is not included in | The TLV is padded to 4-octet alignment; padding is not included in | |||
| the length field. Nested TLVs are also 32-bit aligned. Unrecognized | the length field. Nested TLVs are also 32-bit aligned. Unrecognized | |||
| types are ignored. | types are ignored. | |||
| 5.2. OSPFv2 Extended Link TLV | 5.2. OSPFv2 Extended Link TLV | |||
| OSPFv2 Extended Link TLV is used in order to advertise various | OSPFv2 Extended Link TLV is used in order to advertise various | |||
| attributes of the link. It describes a single link and is | attributes of the link. It describes a single link and is | |||
| constructed of a set of Sub-TLVs. There are no ordering requirements | constructed of a set of Sub-TLVs. There are no ordering requirements | |||
| for the Sub-TLVs. Only one Extended Link TLV SHALL be carried in | for the Sub-TLVs. Only one Extended Link TLV SHALL be advertised in | |||
| each Extended Link Opaque LSA, allowing for fine granularity changes | each Extended Link Opaque LSA, allowing for fine granularity changes | |||
| in the topology. | in the topology. | |||
| The Extended Link TLV has following format: | The Extended Link TLV has following format: | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Type | Length | | | Type | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| skipping to change at page 22, line 9 ¶ | skipping to change at page 21, line 49 ¶ | |||
| Length is variable. | Length is variable. | |||
| Link-Type: as defined in section A.4.2 of [RFC2328]. | Link-Type: as defined in section A.4.2 of [RFC2328]. | |||
| Link-ID: as defined in section A.4.2 of [RFC2328]. | Link-ID: as defined in section A.4.2 of [RFC2328]. | |||
| Link Data: as defined in section A.4.2 of [RFC2328]. | Link Data: as defined in section A.4.2 of [RFC2328]. | |||
| 5.3. Adj-SID sub-TLV | 5.3. Adj-SID sub-TLV | |||
| Adj-SID is an optional Sub-TLV of the Extended Link TLV. It MAY | Adj-SID is an optional sub-TLV of the Extended Link TLV. It MAY | |||
| appear multiple times in Extended Link TLV. Examples where more than | appear multiple times in the Extended Link TLV. Examples where more | |||
| one Adj-SID may be used per neighbor are described in | than one Adj-SID may be used per neighbor are described in | |||
| [I-D.filsfils-rtgwg-segment-routing-use-cases]. The structure of the | ||||
| Adj-SID Sub-TLV is as follows: | [I-D.filsfils-rtgwg-segment-routing-use-cases]. The Adj-SID sub-TLV | |||
| has the following format: | ||||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Type | Length | | | Type | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Flags | Reserved | MT-ID | Weight | | | Flags | Reserved | MT-ID | Weight | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | SID/Label/Index (variable) | | | SID/Label/Index (variable) | | |||
| +---------------------------------------------------------------+ | +---------------------------------------------------------------+ | |||
| skipping to change at page 22, line 40 ¶ | skipping to change at page 22, line 33 ¶ | |||
| Flags. 1 octet field of following flags: | Flags. 1 octet field of following flags: | |||
| 0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | |||
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
| |B|V|L|S| | | |B|V|L|S| | | |||
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
| where: | where: | |||
| B-Flag: Backup-flag: set if the Adj-SID refer to an adjacency | B-Flag: Backup-flag: set if the Adj-SID refers to an adjacency | |||
| being protected (e.g.: using IPFRR or MPLS-FRR) as described in | being protected (e.g.: using IPFRR or MPLS-FRR) as described in | |||
| [I-D.filsfils-rtgwg-segment-routing-use-cases]. | [I-D.filsfils-rtgwg-segment-routing-use-cases]. | |||
| The V-Flag: Value/Index Flag. If set, then the Prefix-SID | The V-Flag: Value/Index Flag. If set, then the Prefix-SID | |||
| carries an absolute value. If not set, then the Prefix-SID | carries an absolute value. If not set, then the Prefix-SID | |||
| carries an index. | carries an index. | |||
| The L-Flag: Local/Global Flag. If set, then the value/index | The L-Flag: Local/Global Flag. If set, then the value/index | |||
| carried by the PrefixSID has local significance. If not set, | carried by the PrefixSID has local significance. If not set, | |||
| then the value/index carried by this subTLV has global | then the value/index carried by this subTLV has global | |||
| skipping to change at page 23, line 26 ¶ | skipping to change at page 23, line 19 ¶ | |||
| SID/Index/Label: according to the V and L flags, it contains | SID/Index/Label: according to the V and L flags, it contains | |||
| either: | either: | |||
| A 32 bit index defining the offset in the SID/Label space | A 32 bit index defining the offset in the SID/Label space | |||
| advertised by this router. | advertised by this router. | |||
| A 24 bit label where the 20 rightmost bits are used for | A 24 bit label where the 20 rightmost bits are used for | |||
| encoding the label value. | encoding the label value. | |||
| A SR capable router MAY allocate an Adj-SID for each of its | An SR capable router MAY allocate an Adj-SID for each of its | |||
| adjacencies and set the B-Flag when the adjacency is protected by a | adjacencies and set the B-Flag when the adjacency is protected by an | |||
| FRR mechanism (IP or MPLS) as described in | FRR mechanism (IP or MPLS) as described in | |||
| [I-D.filsfils-rtgwg-segment-routing-use-cases]. | [I-D.filsfils-rtgwg-segment-routing-use-cases]. | |||
| 5.4. LAN Adj-SID Sub-TLV | 5.4. LAN Adj-SID Sub-TLV | |||
| LAN Adj-SID is an optional Sub-TLV of the Extended Link TLV. It MAY | LAN Adj-SID is an optional sub-TLV of the Extended Link TLV. It MAY | |||
| appear multiple times in Extended Link TLV. It is used to advertise | appear multiple times in Extended Link TLV. It is used to advertise | |||
| SID/Label for adjacency to non-DR node on broadcast or NBMA network. | SID/Label for adjacency to non-DR node on broadcast or NBMA network. | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Type | Length | | | Type | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Flags | Reserved | MT-ID | Weight | | | Flags | Reserved | MT-ID | Weight | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| skipping to change at page 25, line 10 ¶ | skipping to change at page 24, line 51 ¶ | |||
| advertised by this router. | advertised by this router. | |||
| A 24 bit label where the 20 rightmost bits are used for | A 24 bit label where the 20 rightmost bits are used for | |||
| encoding the label value. | encoding the label value. | |||
| 6. Elements of Procedure | 6. Elements of Procedure | |||
| 6.1. Intra-area Segment routing in OSPFv2 | 6.1. Intra-area Segment routing in OSPFv2 | |||
| The OSPFv2 node that supports segment routing MAY advertise Prefix- | The OSPFv2 node that supports segment routing MAY advertise Prefix- | |||
| SIDs for any prefix that it is advertising reachability for (e.g. | SIDs for any prefix to which it is advertising reachability (e.g., a | |||
| loopback IP address) as described in Section 4.2. | loopback IP address as described in Section 4.2). | |||
| If multiple routers advertise Prefix-SID for the same prefix, then | If multiple routers advertise Prefix-SID for the same prefix, then | |||
| the Prefix-SID MUST be the same. This is required in order to allow | the Prefix-SID MUST be the same. This is required in order to allow | |||
| traffic load-balancing if multiple equal cost paths to the | traffic load-balancing if multiple equal cost paths to the | |||
| destination exist in the network. | destination exist in the network. | |||
| Prefix-SID can also be advertised by the SR Mapping Servers (as | Prefix-SID can also be advertised by the SR Mapping Servers (as | |||
| described in [I-D.filsfils-rtgwg-segment-routing-use-cases]). The | described in [I-D.filsfils-rtgwg-segment-routing-use-cases]). The | |||
| Mapping Server advertise Prefix-SID for remote prefixes that exist in | Mapping Server advertises Prefix-SIDs for remote prefixes that exist | |||
| the network. Multiple Mapping Servers can advertise Prefix-SID for | in the OSPFv2 routing domain. Multiple Mapping Servers can advertise | |||
| the same prefix, in which case the same Prefix-SID MUST be advertised | Prefix-SIDs for the same prefix, in which case the same Prefix-SID | |||
| by all of them. Flooding scope of the OSPF Extended Prefix Opaque | MUST be advertised by all of them. The flooding scope of the OSPF | |||
| LSA that is generated by the SR Mapping Server could be either area | Extended Prefix Opaque LSA that is generated by the SR Mapping Server | |||
| scope or autonomous system scope and is decided based on the | could be either area scoped or AS scoped and is determined based on | |||
| configuration of the SR Mapping Server. | the configuration of the SR Mapping Server. | |||
| 6.2. Inter-area Segment routing in OSPFv2 | 6.2. Inter-area Segment routing in OSPFv2 | |||
| In order to support SR in a multi-area environment, OSPFv2 must | In order to support SR in a multi-area environment, OSPFv2 must | |||
| propagate Prefix-SID information between areas. The following | propagate Prefix-SID information between areas. The following | |||
| procedure is used in order to propagate Prefix SIDs between areas. | procedure is used in order to propagate Prefix SIDs between areas. | |||
| When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area | When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area | |||
| prefix to all its connected areas, it will also originate an Extended | prefix to all its connected areas, it will also originate an Extended | |||
| Prefix Opaque LSA, as described in Section 4. The flooding scope of | Prefix Opaque LSA, as described in Section 4. The flooding scope of | |||
| the Extended Prefix Opaque LSA type will be set to area-scope. The | the Extended Prefix Opaque LSA type will be set to area-scope. The | |||
| route-type in OSPF Extended Prefix TLV is set to inter-area. The | route-type in OSPF Extended Prefix TLV is set to inter-area. The | |||
| Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID | Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID | |||
| value will be set as follows: | value will be set as follows: | |||
| The ABR will look at its best path to the prefix in the source | The ABR will look at its best path to the prefix in the source | |||
| area and find out the advertising router associated with its best | area and find the advertising router associated with its best path | |||
| path to that prefix. | to that prefix. | |||
| If no Prefix-SID was advertised for the prefix in the source area | If no Prefix-SID was advertised for the prefix in the source area | |||
| by the router that contributes to the best path to the prefix, | by the router that contributes to the best path to the prefix, | |||
| then the ABR will use the Prefix-SID advertised by any other | then the ABR will use the Prefix-SID advertised by any other | |||
| router (e.g.: a Prefix-SID coming from an SR Mapping Server as | router (e.g.: a Prefix-SID coming from an SR Mapping Server as | |||
| defined in [I-D.filsfils-rtgwg-segment-routing-use-cases]) when | defined in [I-D.filsfils-rtgwg-segment-routing-use-cases]) when | |||
| propagating Prefix-SID for the prefix to other areas. | propagating the Prefix-SID for the prefix to other areas. | |||
| When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area | When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area | |||
| route to all its connected areas it will also originate an Extended | route to all its connected areas it will also originate an Extended | |||
| Prefix Opaque LSA, as described in Section 4. The flooding scope of | Prefix Opaque LSA, as described in Section 4. The flooding scope of | |||
| the Extended Prefix Opaque LSA type will be set to area-scope. The | the Extended Prefix Opaque LSA type will be set to area-scope. The | |||
| route-type in OSPF Extended Prefix TLV is set to inter-area. The | route-type in OSPF Extended Prefix TLV is set to inter-area. The | |||
| Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID | Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID | |||
| will be set as follows: | will be set as follows: | |||
| The ABR will look at its best path to the prefix in the source | The ABR will look at its best path to the prefix in the source | |||
| area and find out the advertising router associated with its best | area and find the advertising router associated with its best path | |||
| path to that prefix. | to that prefix. | |||
| The ABR will then look if such router advertised a Prefix-SID for | The ABR will then determine if such router advertised a Prefix-SID | |||
| the prefix and use it when advertising the Prefix-SID to other | for the prefix and use it when advertising the Prefix-SID to other | |||
| connected areas. | connected areas. | |||
| If no Prefix-SID was advertised for the prefix in the source area | If no Prefix-SID was advertised for the prefix in the source area | |||
| by the ABR that contributes to the best path to the prefix, the | by the ABR that contributes to the best path to the prefix, the | |||
| originating ABR will use the Prefix-SID advertised by any other | originating ABR will use the Prefix-SID advertised by any other | |||
| router (e.g.: a Prefix-SID coming from an SR Mapping Server as | router (e.g.: a Prefix-SID coming from an SR Mapping Server as | |||
| defined in [I-D.filsfils-rtgwg-segment-routing-use-cases]) when | defined in [I-D.filsfils-rtgwg-segment-routing-use-cases]) when | |||
| propagating Prefix-SID for the prefix to other areas. | propagating the Prefix-SID for the prefix to other areas. | |||
| 6.3. SID for External Prefixes | 6.3. SID for External Prefixes | |||
| Type-5 LSAs are flooded domain wide. When an ASBR, which supports | Type-5 LSAs are flooded domain wide. When an ASBR, which supports | |||
| SR, generates Type-5 LSAs, it should also originate Extended Prefix | SR, generates Type-5 LSAs, it should also originate an Extended | |||
| Opaque LSAs, as described in Section 4. The flooding scope of the | Prefix Opaque LSAs, as described in Section 4. The flooding scope of | |||
| Extended Prefix Opaque LSA type is set to AS-scope. The route-type | the Extended Prefix Opaque LSA type is set to AS-scope. The route- | |||
| in OSPF Extended Prefix TLV is set to external. Prefix-SID Sub-TLV | type in OSPF Extended Prefix TLV is set to external. The Prefix-SID | |||
| is included in this LSA and the Prefix-SID value will be set to the | sub-TLV is included in this LSA and the Prefix-SID value will be set | |||
| SID that has been reserved for that prefix. | to the SID that has been reserved for that prefix. | |||
| When a NSSA ASBR translates Type-7 LSAs into Type-5 LSAs, it should | When a NSSA ASBR translates Type-7 LSAs into Type-5 LSAs, it should | |||
| also advertise the Prefix-SID for the prefix. The NSSA ABR | also advertise the Prefix-SID for the prefix. The NSSA ABR | |||
| determines its best path to the prefix advertised in the translated | determines its best path to the prefix advertised in the translated | |||
| Type-7 LSA and finds the advertising router associated with such | Type-7 LSA and finds the advertising router associated with such | |||
| path. If such advertising router has advertised a Prefix-SID for the | path. If such advertising router has advertised a Prefix-SID, for | |||
| prefix, then the NSSA ASBR uses it when advertising the Prefix-SID | the prefix, then the NSSA ASBR uses it when advertising the Prefix- | |||
| for the Type-5 prefix. Otherwise the Prefix-SID advertised by any | SID for the Type-5 prefix. Otherwise, the Prefix-SID advertised by | |||
| other router will be used (e.g.: a Prefix-SID coming from an SR | any other router will be used (e.g.: a Prefix-SID coming from an SR | |||
| Mapping Server as defined in | Mapping Server as defined in | |||
| [I-D.filsfils-rtgwg-segment-routing-use-cases]). | [I-D.filsfils-rtgwg-segment-routing-use-cases]). | |||
| 6.4. Advertisement of Adj-SID | 6.4. Advertisement of Adj-SID | |||
| The Adjacency Segment Routing Identifier (Adj-SID) is advertised | The Adjacency Segment Routing Identifier (Adj-SID) is advertised | |||
| using the Adj-SID Sub-TLV as described in Section 5. | using the Adj-SID Sub-TLV as described in Section 5. | |||
| 6.4.1. Advertisement of Adj-SID on Point-to-Point Links | 6.4.1. Advertisement of Adj-SID on Point-to-Point Links | |||
| Adj-SID MAY be advertised for any adjacency on p2p link that is in a | Adj-SID MAY be advertised for any adjacency on a p2p link that is in | |||
| state 2-Way or higher. If the adjacency on a p2p link transitions | neighbor state 2-Way or higher. If the adjacency on a p2p link | |||
| from the FULL state, then the Adj-SID for that adjacency MAY be | transitions from the FULL state, then the Adj-SID for that adjacency | |||
| removed from the area. If the adjacency transitions to a state lower | MAY be removed from the area. If the adjacency transitions to a | |||
| then 2-Way, then the Adj-SID MUST be removed from the area. | state lower then 2-Way, then the Adj-SID MUST be removed from the | |||
| area. | ||||
| 6.4.2. Adjacency SID on Broadcast or NBMA Interfaces | 6.4.2. Adjacency SID on Broadcast or NBMA Interfaces | |||
| Broadcast or NBMA networks in OSPF are represented by a star topology | Broadcast or NBMA networks in OSPF are represented by a star topology | |||
| where the Designated Router (DR) is the central point all other | where the Designated Router (DR) is the central point all other | |||
| routers on the broadcast or NBMA network connect to. As a result, | routers on the broadcast or NBMA network connect to. As a result, | |||
| routers on the broadcast or NBMA network advertise only their | routers on the broadcast or NBMA network advertise only their | |||
| adjacency to DR and BDR. Routers that are neither DR nor BDR do not | adjacency to DR and BDR. Routers that are neither DR nor BDR do not | |||
| form and do not advertise adjacencies between them. They, however, | form and do not advertise adjacencies between them. They, however, | |||
| maintain a 2-Way adjacency state between them. | maintain a 2-Way adjacency state between them. | |||
| skipping to change at page 30, line 4 ¶ | skipping to change at page 29, line 45 ¶ | |||
| placed in the existing OSPF IANA registry. New values can be | placed in the existing OSPF IANA registry. New values can be | |||
| allocated via IETF Consensus or IESG Approval. | allocated via IETF Consensus or IESG Approval. | |||
| Following initial values are allocated: | Following initial values are allocated: | |||
| o 1 - SID/Label sub-TLV | o 1 - SID/Label sub-TLV | |||
| o 2 - Adj-SID sub-TLV | o 2 - Adj-SID sub-TLV | |||
| o 3 - LAN Adj-SID/Label Sub-TLV | o 3 - LAN Adj-SID/Label Sub-TLV | |||
| Types in the range 32768-32023 are for experimental use; these will | Types in the range 32768-32023 are for experimental use; these will | |||
| not be registered with IANA, and MUST NOT be mentioned by RFCs. | not be registered with IANA, and MUST NOT be mentioned by RFCs. | |||
| Types in the range 32023-65535 are not to be assigned at this time. | Types in the range 32023-65535 are not to be assigned at this time. | |||
| Before any assignments can be made in this range, there MUST be a | Before any assignments can be made in this range, there MUST be a | |||
| Standards Track RFC that specifies IANA Considerations that covers | Standards Track RFC that specifies IANA Considerations that covers | |||
| the range being assigned. | the range being assigned. | |||
| 8. Security Considerations | 8. Security Considerations | |||
| In general, new LSAs defined in this document are subject to the same | In general, new LSAs defined in this document are subject to the same | |||
| security concerns as those described in [RFC2328]. Additionally, | security concerns as those described in [RFC2328]. Additionally, | |||
| implementations must assure that malformed TLV and Sub-TLV | implementations must assure that malformed TLV and Sub-TLV | |||
| permutations do not result in errors which cause hard OSPF failures. | permutations do not result in errors which cause hard OSPF failures. | |||
| 9. Contributors | 9. Contributors | |||
| The following people gave a substantial contribution to the content | The following people gave a substantial contribution to the content | |||
| of this document: Ahmed Bashandy, Martin Horneffer, Bruno Decraene, | of this document: Acee Lindem, Ahmed Bashandy, Martin Horneffer, | |||
| Stephane Litkowski, Igor Milojevic, Rob Shakir and Saku Ytti. | Bruno Decraene, Stephane Litkowski, Igor Milojevic, Rob Shakir and | |||
| Saku Ytti. | ||||
| 10. Acknowledgements | 10. Acknowledgements | |||
| We would like to thank Anton Smirnov for his contribution. | We would like to thank Anton Smirnov for his contribution. | |||
| Many thanks to Yakov Rekhter, John Drake and Shraddha Hedge for their | Many thanks to Yakov Rekhter, John Drake and Shraddha Hedge for their | |||
| contribution on earlier incarnations of the "Binding / MPLS Label | contribution on earlier incarnations of the "Binding / MPLS Label | |||
| TLV" in [I-D.gredler-ospf-label-advertisement]. | TLV" in [I-D.gredler-ospf-label-advertisement]. | |||
| Thanks to Acee Lindem for the detail review of the draft, | ||||
| corrections, as well as discussion about details of the encoding. | ||||
| 11. References | 11. References | |||
| 11.1. Normative References | 11.1. Normative References | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
| [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. | [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. | |||
| [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., | [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., | |||
| End of changes. 77 change blocks. | ||||
| 167 lines changed or deleted | 175 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/ | ||||