One document matched: draft-gredler-isis-label-advertisement-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-gredler-isis-label-advertisement-03"
ipr="trust200902">
<!-- ***** FRONT MATTER ***** -->
<front>
<title>Advertising MPLS labels in IS-IS</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="Hannes Gredler" initials="H." surname="Gredler" role="editor">
<organization>Juniper Networks, Inc.</organization>
<address>
<postal>
<street>1194 N. Mathilda Ave.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>US</country>
</postal>
<email>hannes@juniper.net</email>
</address>
</author>
<author fullname="Shane Amante" initials="S." surname="Amante">
<organization>Level 3 Communications, Inc.</organization>
<address>
<postal>
<street>1025 Eldorado Blvd</street>
<city>Broomfield</city>
<region>CO</region>
<code>80021</code>
<country>US</country>
</postal>
<email>shane@level3.net</email>
</address>
</author>
<author fullname="Tom Scholl" initials="T." surname="Scholl">
<organization>Amazon</organization>
<address>
<postal>
<street></street>
<city>Seattle</city>
<region>WN</region>
<code></code>
<country>US</country>
</postal>
<email>tscholl@amazon.com</email>
</address>
</author>
<author fullname="Luay Jalil" initials="L." surname="Jalil">
<organization>Verizon</organization>
<address>
<postal>
<street>1201 E Arapaho Rd.</street>
<city>Richardson</city>
<region>TX</region>
<code>75081</code>
<country>US</country>
</postal>
<email>luay.jalil@verizon.com</email>
</address>
</author>
<date day="21" month="May" year="2013"/>
<area>Routing</area>
<workgroup>IS-IS for IP Internets</workgroup>
<keyword>MPLS</keyword>
<keyword>IGP</keyword>
<keyword>IS-IS</keyword>
<keyword>Label advertisement</keyword>
<abstract>
<t>Historically MPLS label distribution was driven by
protocols like LDP, RSVP and LBGP. All of those protocols are session
oriented. In order to obtain a label binding for a given destination FEC from
a given router one needs first to establish an LDP/RSVP/LBGP session
with that router.
</t>
<t><xref target="I-D.gredler-rtgwg-igp-label-advertisement">
Advertising MPLS labels in IGPs</xref>
describes several use cases where utilizing the flooding machinery
of link-state protocols for MPLS label distribution allows
to obtain the binding without requiring to establish an LDP/RSVP/LBGP
session with that router.
</t>
<t>This document describes the protocol extension to distribute
MPLS label bindings using the IS-IS protocol.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>MPLS label allocations are predominantly distributed by using
the LDP <xref target="RFC5036"/>, RSVP <xref target="RFC5151"/> or
labeled BGP <xref target="RFC3107"/> protocol. All of those protocols
have in common that they are session oriented, which means that in
order to obtain label binding for a given destination FEC from
a given router one needs first to establish a direct
control plane (LDP/RSVP/LBGP) session with that router.
</t>
<t>There are a couple of practical
<xref target="I-D.gredler-rtgwg-igp-label-advertisement">use cases</xref>
where the consumer of a MPLS label binding may not
be adjacent to the router that performs the binding. Bringing up an
explicit session using the existing label distribution protocols between
the non-adjacent router that binds the label and the router that
acts as a consumer of this binding is the existing remedy for
this dilemma. </t>
<t>This document describes an IS-IS protocol extension which allows
routers to advertise MPLS label bindings within and beyond an IGP domain, and
controlling inter-area distribution.
</t>
</section>
<section title="Motivation, Rationale and Applicability">
<t>One possible way of distributing MPLS labels using IS-IS has been described in
<xref target="I-D.previdi-filsfils-isis-segment-routing"> Segment
Routing</xref>. The authors propose to re-use the IS-Reach TLVs (22,
23, 222) and Extended IP Prefix TLVs (135, 236) for carrying the label
information. While retrofitting existing protocol machinery for new
purposes is generally a good thing, <xref
target="I-D.previdi-filsfils-isis-segment-routing">Segment
Routing</xref> falls short of addressing some use-cases defined in
<xref target="I-D.gredler-rtgwg-igp-label-advertisement"/>.
</t>
<t>The dominant issue around re-using IS-Reach TLVs and the extended IP Prefix TLVs is that
both family of TLVs have existing protocol semantics, which might not be well suitable
to advertising MPLS label switched paths in a generic fashion. These are specifically:</t>
<t><list style="symbols">
<t>Bi-directionality semantics</t>
<t>IP path semantics</t>
<t>Lack of 'path' notion</t>
</list>
</t>
<section title="Issue: Bi-directionality semantics">
<t>
'Bi-directionality semantics', affects the complexity around advertisement of unidirectional LSPs.
Label advertisement of per-link labels or <xref
target="I-D.previdi-filsfils-isis-segment-routing">'Adj-SIDs'</xref>
is done using IS-reach TLVs. Usually implementations need to have
an adjacency in 'Up' state prior to advertising this adjacency
as IS-reach TLV in its Link State PDUs (LSPs).
In order to advertise e.g. one-hop MPLS LSP in a given link an implementation first needs to have
an adjacency, which only transitions to 'Up' state after passing the 3-way
check. This implies bi-directionality. If an implementation wants to advertise
per-link LSPs to e.g. outside the IGP domain then it would need
to fake-up an adjacency. Changing existing IGP Adjacency code to support
such cases defeats the purpose of re-using existing functionality as there is
not much common functionality to be shared.
</t>
</section>
<section title="Issue: IP path semantics">
<t>
LSPs pointing to a Node are advertised as <xref
target="I-D.previdi-filsfils-isis-segment-routing">'Node-SIDs'</xref>
using the family of extended IP Reach TLVs. That means that in order
to advertise a MPLS LSP, one is inheriting the semantics of advertising an
IP path. Consider router A has got existing MPLS LSPs to its entire one-hop
neighborhood and is re-advertising those MPLS LSPs using IP reachability semantics.
Now we have two exact matching IP advertisements. One from the owning router
(router B) which advertises its stable transport loopback address and another one
from router A re-advertising a MPLS LSP path to router B. Existing routing software
may get confused now as the 'stable transport' address shows up from multiple places
in the network and more worse the IP forwarding path for control-plane protocols may get
mingled with the MPLS data plane.
</t>
</section>
<section title="Issue: Lack of 'path' notion">
<t>
Both IS-Reach TLVs and IP Prefix Reachability TLVs have a
limited semantics describing MPLS label-switched paths in the sense of
a 'path'. Both encoding formats allow to specify a pointer to some
specific router, but not to describe a MPLS label switched path
containing all of its path segments. <xref
target="I-D.previdi-filsfils-isis-segment-routing"/> allows to define
'Forwarding Adjacencies' as per <xref target="RFC4206"/>. The way to
describe a path of a given forwarding adjacency is to carry a list of
"Segment IDs". That implies that nodes which do not yet participate in
'Segment routing' or are outside of a 'Segment routing' domain can not
be expressed using those path semantics.
</t>
<t>
A protocol for advertising MPLS label switched paths, should
be generic enough to express paths sourced by existing MPLS LSPs,
such that ingress routers can flexibly combine them according to
application needs.
</t>
</section>
<section title="Motivation">
<t>
IGP advertisement of MPLS label switched paths requires a new set of
protocol semantics (path paradigm), which hardly can be expressed using
the existing IS-IS protocol. This document describes IS-IS protocol extensions
which allows generic advertisement of MPLS label bindings in IS-IS.
</t>
<t>The Protocol extensions described in this document are equally applicable to
IPv4 and IPv6 carried over MPLS. Furthermore the proposed use of distributing
MPLS Labels using IGP prototocols adheres to the architectural principles laid
out in <xref target="RFC3031"/>.
</t>
</section>
</section>
<section title="MPLS label TLV">
<t>The MPLS Label TLV may be originated by any
<xref target="RFC5305">Traffic Engineering</xref>
capable router in an IS-IS domain. The router may advertise a single label
binding or a block of label bindings. For single label binding advertisement
a router needs to provide at least a single 'nexthop style' anchor.
The protocol supports more than one 'nexthop style' anchor
to be attached to a 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 label bindings to
to both link and node IP addresses any label switched path,
can be described. Furthermore also Label Bindings from other protocols
can get easily re-advertised.
</t>
<t>Due to the limited size of subTLV space (See <xref
target="RFC5311"/> section 4.5 for details), The MPLS Label TLV has
cumulative rather than canceling semantics. If a router originates
more than one MPLS Label TLV with the same Label value, then the
subTLVs of the second, third, etc. TLV are accumulated. Since some
subTLVs represent an ordered set (e.g. ERO subTLVs) allocation and
ordering of TLV space inside particular IS-IS LSP fragment is
significant and needs to be tracked.
</t>
<t>The MPLS Label TLV has type 149 and has the following format:</t>
<figure anchor="MPLS-TLV-figure" title="MPLS TLV format">
<artwork>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|R|R|R| MPLS Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t><list style="symbols">
<t>4 bits of flags, consisting of:
<list style="symbols">
<t>1 bit of up/down information (U bit)</t>
<t>3 bits are reserved for future use</t>
</list></t>
<t>20 bits of MPLS label information</t>
<t>0-252 octets of sub-TLVs, where each sub-TLV consists of a
sequence of:
<list style="symbols">
<t>1 octet of sub-TLV type</t>
<t>1 octet of length of the value field of the sub-TLV</t>
<t>0-250 octets of value</t>
</list></t>
</list></t>
<section title="Flags">
<t>Flags
<list style="hanging">
<t>Up/Down Bit: A router may flood MPLS label information across level boundaries.
In order to prevent flooding loops, a router will Set the Up/Down (U-Bit)
when propagating from Level 2 down to Level 1. This is done as per the
procedures for IP Prefixes lined out in <xref target="RFC5302"/>.
</t>
</list></t>
</section>
<section title="subTLV support">
<t>
An originating router MAY want to attach one or more
subTLVs to the MPLS label TLV. SubTLVs presence is inferred from the
length of the MPLS Label TLV. If the MPLS Label TLV Length field is >
3 octets then one or more subTLVs may be present.
</t>
</section>
<section title="IPv4 Prefix ERO subTLV">
<t>The IPv4 ERO subTLV (Type 1) describes a path segment using IPv4 Prefix style of encoding.
Its appearance and semantics have been borrowed from <xref target="RFC3209">
Section 4.3.3.2</xref>.
</t>
<t>The 'Prefix Length' field contains the length of the prefix in bits.
Only the most significant octets of the prefix are encoded. I.e. 1
octet for prefix length 1 up to 8, 2 octets for prefix length 9 to
16, 3 octets for prefix length 17 up to 24 and 4 octets for prefix
length 25 up to 32, etc.</t>
<t>
The 'L' bit in the subTLV 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.'
</t>
<figure anchor="IPv4-Prefix-ERO-subTLV-figure" title="IPv4 Prefix ERO subTLV format">
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Prefix Length | IPv4 Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix (continued, variable-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section> <!-- end IPv4 Prefix ERO subtLV -->
<section title="IPv6 Prefix ERO subTLV">
<t>The IPv6 ERO subTLV (Type 2) describes a path segment using IPv6 Prefix style of encoding.
Its appearance and semantics have been borrowed from <xref target="RFC3209">
Section 4.3.3.3</xref>.
</t>
<t>The 'Prefix Length' field contains the length of the prefix in bits.
Only the most significant octets of the prefix are encoded. I.e. 1
octet for prefix length 1 up to 8, 2 octets for prefix length 9 to
16, 3 octets for prefix length 17 up to 24 and 4 octets for prefix
length 25 up to 32, ...., 16 octets for prefix length 113 up to 128.
</t>
<t>
The 'L' bit in the subTLV 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.'
</t>
<figure anchor="IPv6-Prefix-ERO-subTLV-figure" title="IPv6 Prefix ERO subTLV format">
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Prefix Length | IPv6 Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Prefix (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Prefix (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Prefix (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Prefix (continued, variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section> <!-- end IPv6 Prefix ERO subtLV -->
<section title="Unnumbered Interface ID ERO subTLV">
<t>The appearance and semantics of the 'Unnumbered Interface ID'
have been borrowed from <xref target="RFC3477"> Section 4</xref>.
</t>
<t>The Unnumbered Interface-ID ERO subTLV (Type 9)
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.
</t>
<t>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.</t>
<t>IS-IS supports two Router-ID formats:</t>
<t><list style="symbols">
<t><xref target="RFC5305">(TLV 134, 32-Bit format)</xref></t>
<t><xref target="RFC6119">(TLV 140, 128-Bit format)</xref></t>
</list></t>
<t>The actual Router-ID format gets derived from the 'Length' field.</t>
<t><list style="symbols">
<t>For 32-Bit Router-ID width the subTLV length is set to 8 octets.</t>
<t>For 128-Bit Router-ID width the subTLV length is set to 20 octets.</t>
</list></t>
<t>The 'Interface ID' is the identifier assigned to the link
by the router specified by the router ID.
</t>
<t>
The 'L' bit in the subTLV 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.'
</t>
<figure anchor="Unnumbered-Interface-ID-ERO-subTLV-figure"
title="Unnumbered Interface ID ERO subTLV format">
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Router ID (32 or 128 bits) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section> <!-- end Unnumbered Interface ID ERO subtLV -->
<section title="IPv4 Prefix Bypass ERO subTLV">
<t>The IPv4 Bypass ERO subTLV (Type 3) describes a Bypass LSP path segment using IPv4 Prefix style of encoding.
Its appearance and semantics have been borrowed from <xref target="RFC3209">
Section 4.3.3.2</xref>.
</t>
<t>The 'Prefix Length' field contains the length of the prefix in bits.
Only the most significant octets of the prefix are encoded, i.e. 1
octet for prefix length 1 up to 8, 2 octets for prefix length 9 to
16, 3 octets for prefix length 17 up to 24 and 4 octets for prefix
length 25 up to 32, etc.</t>
<t>
The 'L' bit in the subTLV 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.'
</t>
<figure anchor="IPv4-Prefix-Bypass-ERO-subTLV-figure" title="IPv4 Prefix Bypass ERO subTLV format">
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Prefix Length | IPv4 Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix (continued, variable-length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section> <!-- end IPv4 Prefix Bypass ERO subtLV -->
<section title="IPv6 Prefix Bypass ERO subTLV">
<t>The IPv6 ERO subTLV (Type 4) describes a Bypass LSP path segment using IPv6 Prefix style of encoding.
Its appearance and semantics have been borrowed from <xref target="RFC3209">
Section 4.3.3.3</xref>.
</t>
<t>The 'Prefix Length' field contains the length of the prefix in bits.
Only the most significant octets of the prefix are encoded, i.e. 1
octet for prefix length 1 up to 8, 2 octets for prefix length 9 to
16, 3 octets for prefix length 17 up to 24 and 4 octets for prefix
length 25 up to 32, ...., 16 octets for prefix length 113 up to 128.
</t>
<t>
The 'L' bit in the subTLV 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.'
</t>
<figure anchor="IPv6-Prefix-Bypass-ERO-subTLV-figure" title="IPv6 Prefix Bypass ERO subTLV format">
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Prefix Length | IPv6 Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Prefix (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Prefix (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Prefix (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Prefix (continued, variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section> <!-- end IPv6 Prefix Bypass ERO subtLV -->
<section title="Unnumbered Interface ID Bypass ERO subTLV">
<t>The appearance and semantics of the 'Unnumbered Interface ID'
have been borrowed from <xref target="RFC3477"> Section 4</xref>.
</t>
<t>The Unnumbered Interface-ID Bypass ERO subTLV (Type 10)
describes a Bypass 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.
</t>
<t>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.</t>
<t>IS-IS supports two Router-ID formats:</t>
<t><list style="symbols">
<t><xref target="RFC5305">(TLV 134, 32-Bit format)</xref></t>
<t><xref target="RFC6119">(TLV 140, 128-Bit format)</xref></t>
</list></t>
<t>The actual Router-ID format gets derived from the 'Length' field.</t>
<t><list style="symbols">
<t>For 32-Bit Router-ID width the subTLV length is set to 8 octets.</t>
<t>For 128-Bit Router-ID width the subTLV length is set to 20 octets.</t>
</list></t>
<t>The 'Interface ID' is the identifier assigned to the link
by the router specified by the router ID.
</t>
<t>
The 'L' bit in the subTLV 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.'
</t>
<figure anchor="Unnumbered-Interface-ID-Bypass-ERO-subTLV-figure"
title="Unnumbered Interface ID Bypass ERO subTLV format">
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Router ID (32 or 128 bits) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section> <!-- end Unnumbered Interface ID Bypass ERO subtLV -->
<section title="Prefix ERO and Prefix Bypass ERO subTLV path semantics">
<t>
All 'Prefix ERO' and 'Prefix Bypass ERO' information represents
an ordered set
which describes the segments of a label-switched path. The last Prefix
ERO subTLV describes the segment closest to the egress point of the
LSP. Contrary the first Prefix ERO subTLV describes the first segment
of a label switched path. If a router extends or stitches a label
switched path it MUST prepend the new segments path information to the
Prefix ERO list. The same ordering applies for the Bypass ERO
labels. An implementation SHOULD first encode all primary path
EROs followed by the bypass EROs.
</t>
</section>
<section title="All Router Block subTLV"
anchor="all-rtr-block-subtlv">
<t>
The 'All Router Block' subTLV (Type 6) denominates the label block size of
an MPLS Label advertisement and its semantics to connect to all routers in
a given IS-IS domain using a local assigned <xref target="RFC3031"/>
label range. Note that the actual mapping of a router within the label range
is done using the subTLVs described in
<xref target="all-rtr-id-ipv4-map-subtlv"/> and
<xref target="all-rtr-id-ipv6-map-subtlv"/>. Since generation of
an 'All Router ID IPv4 Map' or 'All Router ID IPv6 Map' subTLV
is a local policy decision, it might be the case
that connectivity is provided not to 'All' but rather a subset of 'All'
routers. Keeping policy decisions aside, for simplicity reasons,
assume that All Routers in a domain do generate either the
'All Router ID IPv4 Map' or
'All Router ID IPv6 Map' subTLVs and therefore all routers
desire construction of a Label switched path from every source router
in the network.
The basic concept of using label blocks to provide connectivity
to a set of routers has been borrowed from <xref target="RFC4761"/>
which allows to advertise labels from multiple end-points using a single control-plane
message. The difference to <xref target="RFC4761"/> is that rather than advertising
where a particular packet came from (=source semantics), destination semantics
(where a particular packet will be going to) is advertised.
</t>
<t>
Along with each label block a router advertises one for more 'IDs'.
The 'ID' must be unique within a given domain.
The 'ID' serves as ordinal to determine the actual label value
inside the set of all advertised label ranges of a given router.
A receiving router uses the ordinal to determine the actual label value
in order to construct forwarding state to
a particular destination router.
The 'ID' is separately advertised using the subTLVs described in
<xref target="all-rtr-id-ipv4-map-subtlv"/> and
<xref target="all-rtr-id-ipv6-map-subtlv"/>.
</t>
<t>
The ability to advertise more than one label block eases operational
procedures for increasing the number of supported routers within a domain.
For example consider a given domain has got support for <M> routers and runs
out of ID space. It simply advertises one more label block to cover additional
ordinals outside the range of the first label block.
An example of label-block expansion is described in more detail in
<xref target="all-rtr-block-resize-example"/>
</t>
<figure anchor="All-Router-Block-sub-TLV-figure"
title="All Router Block subTLV format">
<artwork>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block Size | Algo | Topology-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
The 'Block Size' value contains the size of the label advertisement.
The 'value determines the amount of reachable router endpoints
within a given Label block.
It MUST contain a value greater or equal than two.
Note that the label base is inferred from the Label Value in the
carrying MPLS Label TLV.
For example if a router wants to advertise a label range of 5000-5099 then
it would need to generate a MPLS Label TLV with a Label value of 5000
and a Block Size of 100.
</t>
<t>
The 'Algo' value denominates the path computation algorithm in order
to calculate the forwarding topology. The basic SPF algorithm
has an assigned 'Algo' code point of zero. The purpose of the
'Algo' field is to extend the notion of Label Block Signaling
to arbitrary algorithms like for example 'MRT'
(<xref target="I-D.ietf-rtgwg-mrt-frr-architecture"/>.
Advertised Label Blocks with an unknown, unsupported or non-configured
algorithm MUST be silently ignored.
</t>
<t>
The 'Reserved' bits are for future use. They should be zero on
transmission and ignored on receipt.
</t>
<t>
The 'Topology-ID' field contains the Multi Topology ID
(<xref target="RFC5120"/>) for which the advertised Label Block
does apply. The basic IPv4 unicast Topology has an assigned
'Topology-ID' code point of zero. The basic IPv6 unicast Topology has
an assigned 'Topology=ID' code point of 2.
Advertised Label Blocks with an unknown, unsupported or non-configured
Topology-ID MUST be silently ignored.
</t>
<t>
A MPLS Label TLV containing the 'All Router Block' subTLV MUST only contain
the 'All Router IPv4 Map' subTLV
(<xref target="all-rtr-id-ipv4-map-subtlv"/>)
or the 'All Router IPv6 Map' subTLV
(<xref target="all-rtr-id-ipv6-map-subtlv"/>).
</t>
</section> <!-- end 'All Routers Block subTLV' -->
<section title="All Router ID IPv4 Map subTLV"
anchor="all-rtr-id-ipv4-map-subtlv">
<t>
The 'All Router ID IPv4 Map' TLV (Type 7) maps an 'ID' to a given
stable transport IPv4 address. Its purpose is to associate
a given transport IPv4 IP address to the ordinal inside a label range
as described in <xref target="all-rtr-block-subtlv"/>.
</t>
<t>
A router MAY advertise more than one 'ID' to 'IPv4 address'
mapping pair, in case it has more than one stable transport
IPv4 address.
</t>
<figure anchor="All-Router-ID-IPv4-Map-subTLV-figure"
title="All Router ID IPv4 Map subTLV format">
<artwork>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
The 'IPv4 address' contains stable IPv4 transport address of a given router.
</t>
<t>
The 'ID' contains the ordinal value of an advertising router inside the
set of all advertised label blocks of a given router.
</t>
</section> <!-- end 'All Router ID IPv4 Map subTLV' -->
<section title="All Router ID IPv6 Map subTLV"
anchor="all-rtr-id-ipv6-map-subtlv">
<t>
The 'All Router ID IPv6 Map' TLV (Type 8) maps an 'ID' to a given
stable transport IPv6 address. Its purpose is to associate
a given transport IPv6 IP address to the ordinal inside a label range
as described in <xref target="all-rtr-block-subtlv"/>.
</t>
<t>
A router MAY advertise more than one 'ID' to 'IPv6 address'
mapping pair, in case it has more than one stable transport
IPv6 address.
</t>
<figure anchor="All-Router-ID-IPv6-Map-subTLV-figure"
title="All Router ID IPv6 Map subTLV format">
<artwork>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
The 'IPv6 address' contains the stable IPv6 transport address
of a given router.
</t>
<t>
The 'ID' contains the ordinal value of an advertising router inside the
set of all advertised label blocks of a given router.
</t>
</section> <!-- end 'All Router ID IPv6 Map subTLV' -->
</section>
<section title="Advertising Label Examples">
<section title="Sample Topology">
<t>
The following <xref target="sample-topology">topology</xref> and IP addresses shall be used throughout
the Label advertisement examples.
</t>
<?rfc needLines="20" ?>
<figure anchor="sample-topology" title="Sample Topology">
<artwork>
AS1 : AS 2
:
: :
Level 1 : Level 2 :
: :
: :
+-----+ +-----+-IP3--1-IP4--+-----+ :
| R1 +-IP1--1-IP2--+ R2 | | R3 | :
+--+--+ +--+--+-IP5--3-IP6--+--+--+-IP15-IP16-
| | | : \
IP9 IP7 IP13 : \
| | | : +--+--+
1 1 1 : | R7 |
| | | : +--+--+
IP10 IP8 IP14 : /
| | | : /
+--+--+ +--+--+ +--+--+-IP17-IP18-
| R4 +-IP19-2-IP20-+ R5 |-IP11-2-IP12-| R6 | :
+-----+ +-----+ +-----+ :
: :
: :
: :
</artwork>
</figure>
<section title="Transport IP addresses and Router-IDs">
<t><list style="symbols">
<t>R1: 192.168.1.1</t>
<t>R2: 192.168.1.2</t>
<t>R3: 192.168.1.3</t>
<t>R4: 192.168.1.4</t>
<t>R5: 192.168.1.5</t>
<t>R6: 192.168.1.6</t>
<t>R7: 192.168.1.7</t>
</list></t>
</section>
<section title="Link IP addresses">
<t><list style="symbols">
<t>R1 to R2 link: 10.0.0.1, 10.0.0.2</t>
<t>R1 to R4 link: 10.0.0.9, 10.0.0.10</t>
<t>R2 to R3 link #1: 10.0.0.3, 10.0.0.4</t>
<t>R2 to R3 link #2: 10.0.0.5, 10.0.0.6</t>
<t>R2 to R5 link: 10.0.0.7, 10.0.0.8</t>
<t>R3 to R6 link: 10.0.0.13, 10.0.0.14</t>
<t>R3 to R7 link: 10.0.0.15, 10.0.0.16</t>
<t>R4 to R5 link: 10.0.0.19, 10.0.0.20</t>
<t>R5 to R6 link: 10.0.0.11, 10.0.0.12</t>
<t>R6 to R7 link: 10.0.0.17, 10.0.0.18</t>
</list></t>
<t>
The IGP link metrics are displayed in the middle of the link.
All of them are assumed to be bi-directional.
</t>
</section>
</section>
<section title="One-hop LSP to an adjacent Router">
<t>If R1 would advertise a label <N> bound to a one-hop LSP
from R1 to R2 it would encode as follows:</t>
<t><list>
<t>TLV 149: MPLS label <N>, Flags {}:
<list>
<t>IPv4 Prefix ERO subTLV: 192.168.1.2/32, Strict</t>
</list></t>
</list></t>
</section>
<section title="One-hop LSP to an adjacent Router using a specific link">
<t>If R2 would advertise a label <N> bound to a one-hop LSP
from R2 to R3, using the link #2 it would encode as follows</t>
<t><list>
<t>TLV 149: MPLS label <N>, Flags {}:
<list>
<t>IPv4 Prefix ERO subTLV: 10.0.0.6/32, Strict</t>
</list></t>
</list></t>
</section>
<section title="Advertisement of Fast Re-Route LSP for One-Hop LSP">
<t>R2 may advertise a one-hop LSP from R2 to R3, along with a Link
Protection Bypass for the directly adjacent links between those
two nodes. The Link Protection Bypass would use the path: {R2,
R5, R6, R3}. R2 would encode both the primary LSP and Link
Protection Bypass LSP as follows:</t>
<t><list>
<t>TLV 149: MPLS label <N>, Flags {}:
<list>
<t>IPv4 Prefix ERO subTLV: 192.168.1.3/32, Strict</t>
<t>IPv4 Prefix Bypass ERO subTLV: 192.168.1.5/32, Strict</t>
<t>IPv4 Prefix Bypass ERO subTLV: 192.168.1.6/32, Strict</t>
<t>IPv4 Prefix Bypass ERO subTLV: 192.168.1.3/32, Strict</t>
</list></t>
</list></t>
</section> <!-- end 'Advertisement of Fast Re-Route LSP' -->
<section title="Advertisement of an RSVP LSP">
<t>Consider a RSVP LSP name "R2-to-R6" traversing (R2 to R3 using link #1, R6):</t>
<t>If R2 would advertise a label <N> bound to the RSVP LSP named 'R2-to-R6',
it would encode as follows</t>
<t><list>
<t>TLV 149: MPLS label <N>, Flags {}:
<list>
<t>IPv4 Prefix ERO subTLV: 10.0.0.4/32, Strict</t>
<t>IPv4 Prefix ERO subTLV: 192.168.1.6/32, Strict</t>
</list></t>
</list></t>
</section>
<section title="Advertisement of an LDP LSP">
<t>Consider R2 that creates a LDP label binding for FEC 172.16.0.0/12
using label <N>.</t>
<t>If R2 would re-advertise this binding in IS-IS it would encode as follows</t>
<t><list>
<t>TLV 149: MPLS label <N>, Flags {}:
<list>
<t>IPv4 Prefix ERO subTLV: 172.16.0.0/12, Loose</t>
</list></t>
</list></t>
</section>
<section title="Interarea advertisement of diverse paths">
<t>Consider two R2->R6 paths: {R2, R3, R6} and {R2, R5, R6}</t>
<t>Consider two R5->R3 paths: {R5, R2, R3} and {R5, R6, R3}</t>
<t>R2 encodes its two paths to R6 as follows:</t>
<t><list>
<t>TLV 149: MPLS label <N1>, Flags {}:
<list>
<t>IPv4 Prefix ERO subTLV: 192.168.1.3, Strict</t>
<t>IPv4 Prefix ERO subTLV: 192.168.1.6, Strict</t>
</list></t>
<t>TLV 149: MPLS label <N2>, Flags {}:
<list>
<t>IPv4 Prefix ERO subTLV: 192.168.1.5, Strict</t>
<t>IPv4 Prefix ERO subTLV: 192.168.1.6, Strict</t>
</list></t>
</list></t>
<t>R5 encodes its two paths to R3 as follows:</t>
<t><list>
<t>TLV 149: MPLS label <N1>, Flags {}:
<list>
<t>IPv4 Prefix ERO subTLV: 192.168.1.2, Strict</t>
<t>IPv4 Prefix ERO subTLV: 192.168.1.3, Strict</t>
</list></t>
<t>TLV 149: MPLS label <N2>, Flags {}:
<list>
<t>IPv4 Prefix ERO subTLV: 192.168.1.6, Strict</t>
<t>IPv4 Prefix ERO subTLV: 192.168.1.3, Strict</t>
</list></t>
</list></t>
<t>
A receiving L1 router does see now all 4 paths and may decide
to load-balance across all or a subset of them.
</t>
</section>
<section title="Advertisement of SPT labels using 'All Router Block' TLV"
anchor="all-rtr-block-example">
<t>
All routers within a given area MUST advertise their Label Blocks
along with an 'ID'.
</t>
<t>If R2 would advertise a label block <N1> with a size of 10,
declaring SPT label forwarding support to all routers within a given domain,
it would encode as follows:</t>
<t><list>
<t>TLV 149: MPLS Label <N1>, Flags {}:
<list>
<t>All Router Block subTLV: Block Size 10, Algo 0, Topology 0</t>
<t>All Router ID IPv4 Map subTLV: ID 2, 192.168.1.2</t>
</list></t>
</list></t>
<t>If R3 would advertise a label block <N2> with a size of 10,
declaring SPT label forwarding support to all routers within a given domain,
it would encode as follows:</t>
<t><list>
<t>TLV 149, MPLS Label <N2>, Flags {}:
<list>
<t>All Router Block subTLV: Block Size 10, Algo 0, Topology 0</t>
<t>All Router ID IPv4 Map subTLV: ID 3, 192.168.1.3</t>
</list></t>
</list></t>
<t>If R5 would advertise a label block <N3> with a size of 10,
declaring SPT label forwarding support to all routers within a given domain,
it would encode as follows:</t>
<t><list>
<t>TLV 149, MPLS Label <N3>, Flags {}:
<list>
<t>All Router Block subTLV: Block Size 10, Algo 0, Topology 0</t>
<t>All Router ID IPv4 Map subTLV: ID 5, 192.168.1.5</t>
</list></t>
</list></t>
<t>If R6 would advertise a label block <N4> with a size of 10,
declaring SPT label forwarding support to all routers within a given domain,
it would encode as follows:</t>
<t><list>
<t>TLV 149, MPLS Label <N4>, Flags {}:
<list>
<t>All Router Block subTLV: Block Size 10, Algo 0, Topology 0</t>
<t>All Router ID IPv4 Map subTLV: ID 6, 192.168.1.6</t>
</list></t>
</list></t>
<t>
Consider now R2 constructing a SPT label for R6. R2s SPT to R6 is
{R2, IP4, R3, R6}. R2 first determines if its downstream router
(R3) has advertised a label-block. Since R3 has advertised a label block
'N2' and it has received R6 'ID' of 6 it will be picking the 6th label
value inside the advertised range of its downstream neighbor.
Specifically R2 MUST be program a
MPLS SWAP for its own label range Label(N1+6) to Label(N2+6),
NH 10.0.0.4 into its MPLS transit RIB.
Furthermore R2 MAY program a MPLS PUSH operation for IP 192.168.1.6 to
Label (N2+6), NH 10.0.0.4 into its IPv4 tunnel RIB.
</t>
<t>
Next walk down to R3, which is
the next router on the SPT tree towards R6.
R3s SPT to R6 is {R3, R6}.
R3 determines if its downstream router
(R6) has advertised a label-block. Since R6 has advertised a label block
'N4' and it has received R6 'ID' of 6 it will be picking the 6th label
value inside the advertised range of its downstream neighbor.
Since R3 is the penultimate router to R6 it MUST program a
MPLS POP for its own label range Label(N2+6) NH 10.0.0.14 into
its MPLS transit RIB.
Furthermore R3 MAY program a MPLS NOP for IP 192.168.1.6,
NH 10.0.0.14 into its IPv4 tunnel RIB.
</t>
</section>
<section title="Expansion of an 'All Router Block' subTLV"
anchor="all-rtr-block-resize-example">
<t>
All routers within a given area MUST advertise their Label Blocks
along with an 'ID'. Now assume that the initial label block
size assignment is too small to support all routers which
generate an ordinal within an IGP domain.
Consider the seven routers in <xref target="sample-topology"/>,
and assume that R7 advertises a new ID '15' using an
'All Router ID Map' subTLV. ID '15' is outside of the range
of '10' as per the previous example in
<xref target="all-rtr-block-example"/>.
Now all the routers in an IGP domain need to advertise one
more label block in order to map the ID '15' to an actual
label value.
</t>
<t>All routers would advertise in addition to their
label block <N> with a size of 10, a second label block <N2>
with a size sufficient enough that the new ordinal can get covered.
In this example the same block size 10 is used also for the
second label block. For example router R2 would advertise the
following label bindings.
</t>
<t><list>
<t>TLV 149: MPLS Label <N1>, Flags {}:
<list>
<t>All Router Block subTLV: Block Size 10, Algo 0, Topology 0</t>
<t>All Router ID IPv4 Map subTLV: ID 2, 192.168.1.2</t>
</list></t>
<t>TLV 149: MPLS Label <N2>, Flags {}:
<list>
<t>All Router Block subTLV: Block Size 10, Algo 0, Topology 0</t>
</list></t>
</list></t>
<t>
Now the upstream router can map the new ID of R7 to an
actual label value, as ID '15' corresponds to the 5th label
inside the second Label block.
</t>
</section>
</section> <!-- end 'Advertising Label Examples' -->
<section title="Inter Area Protocol Procedures">
<section title="Applicability">
<t>
Propagation of a MPLS LSP across a level boundary is a local policy decision.
</t>
</section>
<section title="Data plane operations">
<t>
If local policy dictates that a given L1L2 router needs to
re-advertise a MPLS LSPs from one Level to another then it MUST
allocate a new label and program its label forwarding table to connect
the new label to the path in the respective other level. Depending on
how to reach the re-advertised LSP, this is typically done using
a MPLS 'SWAP' or 'SWAP/PUSH' data plane operation.
</t>
</section>
<section title="Control plane operations">
<section title="MPLS Label operations">
<t>
If local policy dictates that a given L1L2 router
re-advertises a MPLS LSPs into another Level then it
MUST prepend its "Traffic-Engineering-ID" as a loose hop in the
Prefix ERO subTLV list. If the LSP is propagated from a higher Level
to a lower Level then the 'Down' bit MUST be set.
</t>
</section>
<section title="MPLS Label Block operations">
<t>
If local policy dictates that a given L1L2 router advertises
its 'All Router Block' into another Level, then it also
MUST re-advertise all known 'ID' ordinals (again gated by policy)
to the respective other Level. Without knowledge of all 'ID's
in the network no router is able to construct SPT label switched paths.
If a Label Block and its ID mappings are propagated from a
higher Level to a lower Level then the 'Down' bit MUST be set.
</t>
</section>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Many thanks to Yakov Rekhter and John Drake for their useful comments.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
This documents request allocation for the following TLVs and subTLVs.
</t>
<?rfc needLines="18" ?>
<texttable anchor="iana_table" title="IANA allocations">
<ttcol align="center">PDU</ttcol>
<ttcol align="left">TLV</ttcol>
<ttcol align="left">subTLV</ttcol>
<ttcol align="left">Type</ttcol>
<ttcol align="left">subType</ttcol>
<ttcol align="right">#Occurence</ttcol>
<c>LSP</c>
<c>MPLS Label</c>
<c></c>
<c>149</c>
<c></c>
<c>>=0</c>
<c></c>
<c></c>
<c>IPv4 Prefix ERO</c>
<c></c>
<c>1</c>
<c>>=0</c>
<c></c>
<c></c>
<c>IPv6 Prefix ERO</c>
<c></c>
<c>2</c>
<c>>=0</c>
<c></c>
<c></c>
<c>Unnumbered Interface ID ERO</c>
<c></c>
<c>9</c>
<c>>=0</c>
<c></c>
<c></c>
<c>IPv4 Prefix Bypass ERO</c>
<c></c>
<c>3</c>
<c>>=0</c>
<c></c>
<c></c>
<c>IPv6 Prefix Bypass ERO</c>
<c></c>
<c>4</c>
<c>>=0</c>
<c></c>
<c></c>
<c>Unnumbered Interface ID Bypass ERO</c>
<c></c>
<c>10</c>
<c>>=0</c>
<c></c>
<c></c>
<c>All Router Block</c>
<c></c>
<c>6</c>
<c>>=0</c>
<c></c>
<c></c>
<c>All Router ID IPv4 Map</c>
<c></c>
<c>7</c>
<c>>=0</c>
<c></c>
<c></c>
<c>All Router ID IPv6 Map</c>
<c></c>
<c>8</c>
<c>>=0</c>
</texttable>
<t>
The MPLS Label TLV requires a new sub-registry.
Type value 149 has been assigned, with a starting sub-TLV
value of 1, range from 1-127, and managed by Expert Review.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t> This document does not introduce any change in terms of IS-IS
security. It simply proposes to flood MPLS label information via the IGP.
All existing procedures to ensure message integrity do apply here.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3031.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3107.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3477.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4206.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4761.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5036.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5120.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5151.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5302.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5305.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5311.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6119.xml"?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-gredler-rtgwg-igp-label-advertisement-05.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-previdi-filsfils-isis-segment-routing-02.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-rtgwg-mrt-frr-architecture-02.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:09:51 |