| IS-IS for IP Internets | S. Previdi, Ed. |
| Internet-Draft | C. Filsfils |
| Intended status: Standards Track | A. Bashandy |
| Expires: April 24, 2014 | Cisco Systems, Inc. |
| H. Gredler | |
| Juniper Networks, Inc. | |
| S. Litkowski | |
| Orange | |
| October 21, 2013 |
IS-IS Extensions for Segment Routing
draft-previdi-isis-segment-routing-extensions-04
Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).
This draft describes the necessary IS-IS extensions that need to be introduced for Segment Routing.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 24, 2014.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). Two types of segments are defined, Prefix segments and Adjacency segments. Prefix segments represent an ecmp-aware shortest-path to a prefix, as per the state of the IGP topology. Adjacency segments represent a hop over a specific adjacency between two nodes in the 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 control-plane can be applied to both IPv6 and MPLS data-planes, and do not require any additional signaling (other than the regular IGP). For example, when used in MPLS networks, SR paths do not require any LDP or RSVP-TE signaling. Still, SR can interoperate in the presence of LSPs established with RSVP or LDP.
This draft describes the necessary IS-IS extensions that need to be introduced for Segment Routing.
Segment Routing architecture is described in [I-D.filsfils-rtgwg-segment-routing].
Segment Routing use cases are described in [I-D.filsfils-rtgwg-segment-routing-use-cases].
Segment Routing architecture ([I-D.filsfils-rtgwg-segment-routing]) defines different types of Segment Identifiers (SID). This document defines the IS-IS encodings for the IGP-Prefix-SID, the IGP-Adjacency-SID, the IGP-LAN-Adjacency-SID and the Binding-SID.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where:
The SID/Label Sub-TLV is present in multiple Sub-TLVs defined in this document and contains a SID or a MPLS Label. The SID/Label Sub-TLV has the following format:
A new IS-IS Sub-TLV is defined: the Prefix Segment Identifier Sub-TLV (Prefix-SID Sub-TLV).
The Prefix-SID Sub-TLV carries the Segment Routing IGP-Prefix-SID as defined in [I-D.filsfils-rtgwg-segment-routing]. The 'Prefix SID' must be unique within a given IGP domain. The 'Prefix SID' is an index to determine the actual SID/label value inside the set of all advertised SID/label ranges of a given router. A receiving router uses the index to determine the actual SID/label value in order to construct forwarding state to a particular destination router.
In many use-cases a 'stable transport' IP Address is overloaded as an identifier of a given node. Because the IP Prefixes may be re-advertised into other levels there may be some ambiguity (e.g. Originating router vs. L1L2 router) for which node a particular IP prefix serves as identifier. The Prefix-SID Sub-TLV contains the necessary flags to dissambiguate IP Prefix to node mappings. Furthermore if a given node has several 'stable transport' IP adresses there are flags to differentiate those among other IP Prefixes advertised from a given node.
A Prefix-SID Sub-TLV is associated to a prefix advertised by a node and MAY be present in any of the following TLVs:
The Index inside the Prefix-SID Sub-TLV MUST be preserved when an IP Reachability TLV gets propagated across level boundaries.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where:
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |R|N|P| | +-+-+-+-+-+-+-+-+
The Prefix-SID Sub-TLV has the following format:
Multiple Prefix-SIDs Sub-TLVs MAY appear on the same prefix in which case each SID is encoded as a separate Sub-TLV. When multiple Prefix-SID Sub-TLVs are present, the receiving router MUST use the first encoded SID and MAY use the subsequent ones.
The No-PHP flag MUST be set on the Prefix-SIDs associated with reachability advertisements which were originated by other routers and leaked (either from Level-1 to Level-2 or vice versa).
The R-Flag MUST be set for prefixes that are not local to the router and either:
In the case where a Level-1-2 router has local interface addresses configured in one level, it may also propagate these addresses into the other level. In such case, the Level-1-2 router MUST NOT set the R bit. The R-bit MUST be set only for prefixes that are not local to the router and advertised by the router because of propagation and/or leaking.
The N-Flag is used in order to define a Node-SID. A router MAY set the N-Flag only if all of the following conditions are met:
The router MUST ignore the N-Flag on a received Prefix-SID if the prefix has a Prefix length different than /32 (IPv4) or /128 (IPv6).
The router behavior determined by the P, R and N flags are described in [I-D.filsfils-rtgwg-segment-routing].
A new IS-IS Sub-TLV is defined: the Adjacency Segment Identifier Sub-TLV (Adj-SID Sub-TLV).
The Adj-SID Sub-TLV is an optional Sub-TLV carrying the Segment Routing IGP-Adjacency-SID as defined in [I-D.filsfils-rtgwg-segment-routing] with flags and fields that may be used, in future extensions of Segment Routing, for carrying other types of SIDs.
IS-IS adjacencies are advertised using one of the IS-Neighbor TLVs below:
Multiple Adj-SID Sub-TLVs MAY be associated with a single IS-neighbor. Examples where more than one Adj-SID may be used per IS-neighbor are described in [I-D.filsfils-rtgwg-segment-routing-use-cases].
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label Sub-TLV (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+
|F|B| |
+-+-+-+-+-+-+-+
The following format is defined for the Adj-SID Sub-TLV:
In LAN subnetworks, the Designated Intermediate System (DIS) is elected and originates the Pseudonode-LSP (PN-LSP) including all neighbors of the DIS.
When Segment Routing is used, each router in the LAN MAY advertise the Adj-SID of each of its neighbors. Since, on LANs, each router only advertises one adjacency to the DIS (and doesn't advertise any other adjacency), each router advertises the set of Adj-SIDs (for each of its neighbors) inside a newly defined Sub-TLV part of the TLV advertising the adjacency to the DIS (e.g.: TLV-22).
The following new Sub-TLV is defined: LAN-Adj-SID (Type 32) containing the set of Adj-SIDs the router assigned to each of its LAN neighbors.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | System-ID (6 octets) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label Sub-TLV (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+
|F|B| |
+-+-+-+-+-+-+-+
The format of the LAN-Adj-SID Sub-TLV is as follows:
Multiple LAN-Adj-SID Sub-TLVs MAY be encoded.
In case one TLV-22/23/222/223 (reporting the adjacency to the DIS) can't contain the whole set of LAN-Adj-SID Sub-TLVs, multiple advertisements of the adjacency to the DIS MUST be used, MUST have the same metric and SHOULD be inserted within the same LSP fragment.
Each router within the level, by receiving the DIS PN LSP as well as the non-PN LSP of each router in the LAN, is capable of reconstructing the LAN topology as well as the set of Adj-SID each router uses for each of its neighbors.
The SID/Label Binding TLV MAY be originated by any router in an IS-IS domain. The router may advertise a SID/Label binding to a FEC along with at least a single 'nexthop style' anchor. The protocol supports more than one 'nexthop style' anchor to be attached to a SID/Label binding, which results into a simple path description language. In analogy to RSVP the terminology for this is called an 'Explicit Route Object' (ERO). Since ERO style path notation allows to anchor SID/label bindings to to both link and node IP addresses any label switched path, can be described. Furthermore also SID/Label Bindings from external protocols can get easily re-advertised.
The SID/Label Binding TLV may be used for advertising SID/Label Bindings and their associated Primary and Backup paths. In one single TLV either a primary ERO Path, a backup ERO Path or both are advertised. If a router wants to advertise multiple parallel paths then it can generate several TLVs for the same Prefix/FEC. Each occurence of a Binding TLV with respect with a given FEC Prefix has accumulating and not canceling semantics. Due the space constraints in the 8-Bit IS-IS TLVs an originating router MAY encode a primary ERO path in one SID/Label Binding TLV and the backup ERO path in a second SID/Label Binding TLV. Note that the FEC Prefix and SID/Label Sub-TLV MUST be identical in both TLVs.
The SID/Label Binding TLV has type TBA and has the following format:
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range | Prefix Length | FEC Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // FEC Prefix (continued, variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | optional subTLVs (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SID/Label Binding TLV format
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |F|M|X|S| | +-+-+-+-+-+-+-+-+
Flags: 1 octet field of following flags:
Weight: 1 octet: The value represents the weight of the path for the purpose of load balancing. The use of the weight is defined in [I-D.filsfils-rtgwg-segment-routing].
The 'Range' field provides the ability to specify a range of addresses and their associated Prefix SIDs. It is essentially a compression scheme to distribute a continuous Prefix and their continuous, corresponding SID/Label Block. If a single SID is advertised then the range field MUST be set to one. For range advertisments > 1, the number of addresses that need to be mapped into a Prefix-SID and the starting value of the Prefix-SID range.
Router-A: 192.0.2.1/32, Prefix-SID: Index 1 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 Router-D: 192.0.2.4/32, Prefix-SID: Index 4
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |0|0|1|1| | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range = 4 | /32 | 192 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .0 | .2 | .1 | Sub-TLV Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV Length| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example 1: if the following router addresses (loopback addresses) need to be mapped into the corresponding Prefix SID indexes.
10.1.1/24, Prefix-SID: Index 51 10.1.2/24, Prefix-SID: Index 52 10.1.3/24, Prefix-SID: Index 53 10.1.4/24, Prefix-SID: Index 54 10.1.5/24, Prefix-SID: Index 55 10.1.6/24, Prefix-SID: Index 56 10.1.7/24, Prefix-SID: Index 57
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |0|0|1|1| | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range = 7 | /24 | 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .1 | .1 | Sub-TLV Type | Sub-TLV Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 51 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example-2: If the following prefixes need to be mapped into the corresponding Prefix-SID indexes:
It is not expected that a network operator will be able to keep fully continuous FEC Prefix / SID/Index mappings. In order to support noncontinuous mapping ranges an implementation MAY generate several instances of Binding TLVs.
For example if a router wants to advertise the following ranges:
A router would need to advertise three instances of the Binding TLV.
The 'FEC Prefix' represents the Forwarding equivalence class at the tail-end of the advertised path. The 'FEC Prefix' does not need to correspond to a routable prefix of the originating node.
The 'Prefix Length' field contains the length of the prefix in bits. Only the most significant octets of the Prefix FEC are encoded. I.e. 1 octet for FEC prefix length 1 up to 8, 2 octets for FEC prefix length 9 to 16, 3 octets for FEC prefix length 17 up to 24 and 4 octets for FEC prefix length 25 up to 32, ...., 16 octets for FEC prefix length 113 up to 128.
The SID/Label Sub-TLV (Type 1) contains the SID/Label value as defined in Section 2.1. It MUST be present in every SID/Label Binding TLV.
ERO Metric sub-TLV (Type 2) is a Sub-TLV of the SID/Label Binding TLV.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ERO Metric sub-TLV format
The ERO Metric sub-TLV carries the cost of an ERO path. It is used to compare the cost of a given source/destination path. A router SHOULD advertise the ERO Metric sub-TLV. The cost of the ERO Metric sub-TLV SHOULD be set to the cumulative IGP or TE path cost of the advertised ERO. Since manipulation of the Metric field may attract or distract traffic from and to the advertised segment it MAY be manually overridden.
The IPv4 ERO subTLV (Type 3) describes a path segment using IPv4 address style of encoding. Its semantics have been borrowed from [RFC3209].
The 'L' bit in the Flags is a one-bit attribute. If the L bit is set, then the value of the attribute is 'loose.' Otherwise, the value of the attribute is 'strict.'
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |L| Reserved | IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IPv4 ERO subTLV format
The IPv6 ERO subTLV (Type 4) describes a path segment using IPv6 Address style of encoding. Its semantics have been borrowed from [RFC3209].
The 'L' bit in the Flags is a one-bit attribute. If the L bit is set, then the value of the attribute is 'loose.' Otherwise, the value of the attribute is 'strict.'
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |L| Reserved | IPv6 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IPv6 ERO subTLV format
The appearance and semantics of the 'Unnumbered Interface ID' have been borrowed from Section 4 [RFC3477].
The Unnumbered Interface-ID ERO subTLV (Type 5) describes a path segment that spans over an unnumbered interface. Unnumbered interfaces are referenced using the interface index. Interface indices are assigned 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 need to be disambiguated using a domain unique Router-ID.
The 'Router-ID' field contains the router ID of the router which has assigned the 'Interface ID' field. Its purpose is to disambiguate the 'Interface ID' field from other routers in the domain.
IS-IS supports two Router-ID formats:
The actual Router-ID format gets derived from the 'Length' field.
The 'Interface ID' is the identifier assigned to the link by the router specified by the router ID.
The 'L' bit in the Flags is a one-bit attribute. If the L bit is set, then the value of the attribute is 'loose.' Otherwise, the value of the attribute is 'strict.'
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |L| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Router ID (32 or 128 bits) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Unnumbered Interface ID ERO subTLV format
The IPv4 Backup ERO subTLV (Type 6) describes a Backup path segment using IPv4 Address style of encoding. Its appearance and semantics have been borrowed from [RFC3209].
The 'L' bit in the Flags is a one-bit attribute. If the L bit is set, then the value of the attribute is 'loose.' Otherwise, the value of the attribute is 'strict.'
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |L| Reserved | IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: IPv4 Backup ERO subTLV format
The IPv6 Backup ERO subTLV (Type 7) describes a Backup path segment using IPv6 Address style of encoding. Its appearance and semantics have been borrowed from [RFC3209].
The 'L' bit in the Flags is a one-bit attribute. If the L bit is set, then the value of the attribute is 'loose.' Otherwise, the value of the attribute is 'strict.'
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |L| Reserved | IPv6 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: IPv6 Backup ERO subTLV format
The appearance and semantics of the 'Unnumbered Interface ID' have been borrowed from Section 4 [RFC3477].
The Unnumbered Interface-ID Backup ERO subTLV (Type 8) describes a Backup LSP path segment that spans over an unnumbered interface. Unnumbered interfaces are referenced using the interface index. Interface indices are assigned 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 need to be disambiguated using a domain unique Router-ID.
The 'Router-ID' field contains the router ID of the router which has assigned the 'Interface ID' field. Its purpose is to disambiguate the 'Interface ID' field from other routers in the domain.
IS-IS supports two Router-ID formats:
The actual Router-ID format gets derived from the 'Length' field.
The 'Interface ID' is the identifier assigned to the link by the router specified by the router ID.
The 'L' bit in the Flags is a one-bit attribute. If the L bit is set, then the value of the attribute is 'loose.' Otherwise, the value of the attribute is 'strict.'
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |L| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Router ID (32 or 128 bits) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Unnumbered Interface ID Backup ERO subTLV format
All 'ERO' and 'Backup ERO' information represents an ordered set which describes the segments of a path. The last ERO subTLV describes the segment closest to the egress point of the path. Contrary the first ERO subTLV describes the first segment of a path. If a router extends or stitches a label switched path it MUST prepend the new segments path information to the ERO list. The same ordering applies for the Backup ERO labels. An implementation SHOULD first encode all primary path EROs followed by the bypass EROs.
Segment Routing requires each router to advertise its SR data-plane capability and the range of SID/Label values it uses for Segment Routing. Data-plane capabilities and SID/Label ranges are advertised using the newly defined SR-Capabilities Sub-TLV inserted into the IS-IS Router Capability TLV-242 that is defined in [RFC4971].
The Router Capability TLV specifies flags that control its advertisement. The SR Capabilities Sub-TLV MUST be propagated throughout the level and need not to be advertised across level boundaries. Therefore Router Capability TLV distribution flags MUST be set accordingly, i.e.: the S flag MUST be unset.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | Range | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range (cont.) | SID/Label Sub-TLV (variable size) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |I|V| | +-+-+-+-+-+-+-+-+
The SR Capabilities Sub-TLV (Type 2) is optional, MAY appear multiple times inside the Router Capability TLV and has following format:
If multiple occurrence of the SR-Capabilities Sub-TLV are advertised by the same router, only the Flags in the first occurrence of the Sub-TLV are to be taken into account.
The router may use various algorithms when calculating reachability to other nodes or to prefixes attached to these nodes. Examples of these algorithms are metric based Shortest Path First (SPF), various sorts of Constrained SPF, etc. The SR-Algorithm Sub-TLV (Type 15) allows the router to advertise the algorithms that the router is currently using. The following value has been defined:[RFC4971].
The SR-Algorithm Sub-TLV is inserted into the IS-IS Router Capability TLV-242 that is defined in
The Router Capability TLV specifies flags that control its advertisement. The SR-Algorithm MUST be propagated throughout the level and need not to be advertised across level boundaries. Therefore Router Capability TLV distribution flags MUST be set accordingly, i.e.: the S flag MUST be unset.
The SR-Algorithm Sub-TLV is optional, it MAY only appear a single time inside the Router Capability TLV. If the SID-Label Capability Sub-TLV is advertised then the SR-Algorithm Sub-TLV MUST also be advertised.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It has following format:
This documents request allocation for the following TLVs and subTLVs.
| PDU | TLV | subTLV | Type | subType | #Occurence |
|---|---|---|---|---|---|
| LSP | IS Neighbor | 22, 23, 222, 223 | >=0 | ||
| SID/Label | 31 | >0 | |||
| LAN SID/Label | 32 | >0 | |||
| LSP | IP reachability | 135, 235, 236, 237 | >=0 | ||
| SID/Label | 3 | >0 | |||
| LSP | SID/MPLS Binding | 149 | >=0 | ||
| SID/Label | 1 | >0 | |||
| ERO Metric | 2 | 1 | |||
| IPv4 ERO | 3 | >=0 | |||
| IPv6 ERO | 4 | >=0 | |||
| Unnumbered Interface ID ERO | 5 | >=0 | |||
| IPv4 Backup ERO | 6 | >=0 | |||
| IPv6 Backup ERO | 7 | >=0 | |||
| Unnumbered Interface ID Backup ERO | 8 | >=0 | |||
| LSP | Router Capability | 242 | >=0 | ||
| SR Capability | 2 | >=0 | |||
| SR Algorithm | 15 | 1 |
The SID/MPLS Binding TLV requires a new sub-registry. Type value 149 has been assigned, with a starting sub-TLV value of 1, range from 1-255, and managed by Expert Review.
TBD
TBD
The following people gave a substantial contribution to the content of this document: Martin Horneffer, Bruno Decraene, Igor Milojevic, Rob Shakir, Saku Ytti and Wim Henderickx.
We would like to thank Les Ginsberg, Dave Ward, Dan Frost, Stewart Bryant and Pierre Francois for their contribution to the content of this document.
Many thanks to Yakov Rekhter and Ina Minei for their contribution on earlier incarnations of the "Binding / MPLS Label TLV" in [I-D.gredler-isis-label-advertisement].
| [I-D.filsfils-rtgwg-segment-routing] | Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Ytti, S., Henderickx, W., Tantsura, J. and E. Crabbe, "Segment Routing Architecture", Internet-Draft draft-filsfils-rtgwg-segment-routing-00, June 2013. |
| [I-D.filsfils-rtgwg-segment-routing-use-cases] | Filsfils, C., Francois, P., Previdi, S., Decraene, B., Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Ytti, S., Henderickx, W., Tantsura, J. and E. Crabbe, "Segment Routing Use Cases", Internet-Draft draft-filsfils-rtgwg-segment-routing-use-cases-01, July 2013. |
| [I-D.gredler-isis-label-advertisement] | Gredler, H., Amante, S., Scholl, T. and L. Jalil, "Advertising MPLS labels in IS-IS", Internet-Draft draft-gredler-isis-label-advertisement-03, May 2013. |