One document matched: draft-gredler-ospf-label-advertisement-00.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-ospf-label-advertisement-00" ipr="trust200902">
<!-- ***** FRONT MATTER ***** -->
<front>
<title>Advertising MPLS labels in OSPF</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="12" month="April" year="2013"/>
<area>Routing</area>
<workgroup>Open Shortest Path First IGP</workgroup>
<keyword>MPLS</keyword>
<keyword>IGP</keyword>
<keyword>OSPF</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 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 advertisement</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 labels by the OSPFv2 and OSPFv3 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
<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 bind 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 a OSPFv2 and OSPFv3 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>Distributing MPLS labels in an IGP (IS-IS) has been described in
<xref target="I-D.previdi-filsfils-isis-segment-routing"> Segment
Routing</xref>. The authors propose to re-use existing traffic-engineering
extensions 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 traffic-engineering extensions is that
both have existing protocol semantics, which might not be applicable
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 by attaching label information to adjacency advertisment TLVs.
Usually implementations need to have
an adjacency in 'Up' state prior to advertising this adjacency
as TE-Link in its Link State advertisment.
In order to advertise a per-link LSP 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 MPLS 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 IP Prefix containers. 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 LSPs to its entire one-hop
neighborhood and is re-advertising those 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 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 exisiting traffic-engineering extension containers have
limited semantics describing MPLS label-switched paths in the sense of
a 'path'. Both encoding formats allow to express 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 enlist 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 (undirectional paradigm, path paradigm), which hardly can be expressed using
the existing OSPF and OSPF-TE protocol semantics. This document describes protocol extensions
which allows generic advertisement of MPLS label switched paths in OSPF.
</t>
</section>
</section>
<section title="OSPF MPLS LSA Format">
<section title="Common LSA Type">
<t>
One new LSA is defined, the MPLS Label LSA. This LSA advertises
MPLS labels along with their path information. The LSA contains
more specific information encoded in TLVs. Those TLV extensions are
shared between the OSPFv2 and OPSFv3 protocols.
</t>
</section>
<section title="OSPFv2 LSA ID">
<t>
The LSA ID of an Opaque LSA is defined as having eight bits
of type data and 24 bits of type-specific data. The MPLS Label LSA
uses type 149. The remaining 24 bits are 4 zero bits followed by the
MPLS Label value as follows:
</t>
<figure anchor="MPLS-LSAID-figure" title="MPLS LSA-ID 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 149 |0|0|0|0| MPLS Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
The 'MPLS Label' field holds the 20 Bit MPLS label.
Therefore a maximum of 2^20 MPLS Label LSAs may be sourced
by a single system.
</t>
</section>
<section title="OSPFv2 LSA Format Overview">
<t>
This extension makes use of the Opaque LSAs <xref target="RFC5250"/>.
</t>
<t>
Three types of Opaque LSAs exist, each of which has a different
flooding scope. This proposal uses only Type 10 LSAs, which have an
area flooding scope.
</t>
<t>
The MPLS Label LSA for OSPFv2 starts with the standard OSPFv2 LSA header:
</t>
<figure anchor="MPLS-Label-OSPFv2-LSA-figure" title="MPLS Label OSPFv2 LSA 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 149 |0|0|0|0| MPLS Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |
</artwork>
</figure>
</section>
<section title="OSPFv3 LSA ID">
<t>
The OSPFv3 LSA ID of an MPLS Label LSA is defined as having twelve bits
of zero followed by the 20-Bit label MPLS Label value as follows:
</t>
<figure anchor="MPLS-OSPFv3-LSAID-figure" title="MPLS OSPFv3 LSA-ID 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|0|0|0|0|0|0| MPLS Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
The 'MPLS Label' field holds the 20 Bit MPLS label.
Therefore a maximum of 2^20 MPLS Label LSAs may be sourced
by a single system.
</t>
</section>
<section title="OSPFv3 LSA Format Overview">
<t>
The MPLS Label LSA for OSPFv3 starts with the standard OSPFv3 LSA header:
</t>
<figure anchor="MPLS-Label-OSPFv3-LSA-figure" title="MPLS Label OSPFv3 LSA 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age |1|0|1| 149 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|0|0|0|0|0|0| MPLS Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |
</artwork>
</figure>
<t>
The OSPFv3 'U' Bit will always be set such that routers which
do not understand the new MPLS Label LSA will store and forward
it further.
</t>
<t>
In analogy to the OSPFv2 opaque LSA 10 the flooding scope will be
set to 'Area scoping'.
</t>
</section>
<section title="TLV Header">
<t>
The LSA payload consists of one or more nested Type/Length/Value
(TLV) triplets for extensibility. The format of each TLV is:
</t>
<figure anchor="TLV-figure" title="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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
The Length field defines the length of the value portion in
octets (thus a TLV with no value portion would have a length of zero).
The TLV is padded to four-octet alignment; padding is not included in
the length field (so a three octet value would have a length of three,
but the total size of the TLV would be eight octets). Nested TLVs are
also 32-bit aligned. Unrecognized types are ignored.
</t>
<t>
This memo defines Types 1, 2 and 3. See the IANA Considerations
section for allocation of new Types.
</t>
</section>
</section>
<section title="LSA payload details">
<t>
The MPLS Label LSA may be originated by any <xref
target="RFC3630">Traffic Engineering</xref> capable router in an OSPF
domain. A router may advertise MPLS labels along with so called 'ERO'
path segments describing the label switched path. This gets encoded
in subsequent TLVs. Since ERO style path notation allows to express
pointers to link and node IP addresses. Now any label switched path,
sourced by any protocol, can be described.
</t>
<t>
An LSA contains one or more TLVs, describing properties of the advertised MPLS label.
</t>
<t>
The following TLV extensions may be shared in both OSPV2 and OSPFv3.
Passing an IP address of the other address family (IPv4 in OPSFv3 or IPv6 in OSPFv2)
is possible as the information carried are related describing the hops
along a path. The receiver of this information is a protocol agnostic
path computation module.
</t>
<section title="Prefix ERO TLVs">
<t>
All 'Prefix ERO' information represents an ordered set
which describes the segments of a label-switched path. The last Prefix
ERO TLV describes the segment closest to the egress point of the
LSP. Contrary the first Prefix ERO TLV 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.
</t>
<section title="IPv4 Prefix ERO TLV">
<t>The IPv4 ERO TLV (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 'IPv4 Address' is treated as a prefix based on
the prefix length value below. Bits beyond the prefix are
ignored on receipt and SHOULD be set to zero on transmission.
</t>
<t>
The 'Prefix Length' field contains the length of the prefix in bits.
</t>
<t>
The 'L' bit in the TLV 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>
<t>
The 'Reserved' bits are for future use. They should be zero on
transmission and ignored on receipt.
</t>
<figure anchor="IPv4-Prefix-ERO-TLV-figure" title="IPv4 Prefix ERO 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |L| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section> <!-- end IPv4 Prefix ERO TLV -->
<section title="IPv6 Prefix ERO TLV">
<t>The IPv6 ERO TLV (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.2</xref>.
</t>
<t>
the 'IPv6 Address' is treated as a prefix based on
the prefix length value below. Bits beyond the prefix are
ignored on receipt and SHOULD be set to zero on transmission.
</t>
<t>
The 'Prefix Length' field contains the length of the prefix in bits.
</t>
<t>
The 'L' bit in the TLV 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>
<t>
The 'Reserved' bits are for future use. They should be zero on
transmission and ignored on receipt.
</t>
<figure anchor="IPv6-Prefix-ERO-TLV-figure" title="IPv6 Prefix ERO 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |L| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section> <!-- end IPv6 Prefix ERO TLV -->
</section>
<section title="Flags TLV">
<t>
The Flags TLV (Type 3) describes Flags for further MPLS LSA treatment.
</t>
<t>
Up/Down 'U' Bit: A router may flood MPLS label information across area boundaries.
In order to prevent flooding loops, a router will Set the Up/Down (U-Bit)
when propagating MPLS labels from Area 0 to a non-zero Area.
</t>
<t>
The 'Reserved' bits are for future use. They should be zero on
transmission and ignored on receipt.
</t>
<figure anchor="Flags-TLV-figure" title="Flags 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| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section> <!-- end Flags TLV -->
</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>
<figure anchor="sample-topology" title="Sample Topology">
<artwork>
AS1 : AS 2
:
: :
Level 1 : Level 2 :
: :
+-----+ +-----+-IP3--IP4--+-----+ :
| R1 +-IP1--IP2--+ R2 | | R3 | :
+--+--+ +--+--+-IP5--IP6--+--+--+-IP15-IP16-
| | | : \
IP3 IP7 IP13 : +--+--+
| | | : | R7 |
IP4 IP8 IP14 : +--+--+
| | | : /
+--+--+ +--+--+ +--+--+-IP17-IP18-
| R4 +-IP19-IP20-+ R5 |-IP11-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.3, 10.0.0.4</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>
</section>
</section>
<section anchor="one-hop-lsp-internal-rtr" 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 style="hangout">
<t>LSA 149, LSA-ID <N>:
<list style="hangout">
<t>IPv4 Prefix ERO TLV: 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 style="hangout">
<t>LSA 149, LSA-ID <N>:
<list style="hangout">
<t>IPv4 Prefix ERO TLV: 10.0.0.6/32, Strict</t>
</list></t>
</list></t>
</section>
<section title="One-hop LSP to an adjacent external Router">
<t>If R3 would advertise a label <N> bound to a one-hop LSP
from R3 to R7 (which is outside of the IGP domain),
it would encode as follows:</t>
<t><list style="hangout">
<t>LSA 149, LSA-ID <N>:
<list style="hangout">
<t>IPv4 Prefix ERO TLV: 192.168.1.7/32, Strict</t>
</list></t>
</list></t>
<t>
As you can see the representation of an MPLS label crossing
an external link is identical as an internal link <xref target="one-hop-lsp-internal-rtr"/>.
</t>
</section>
<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 style="hangout">
<t>LSA 149, LSA-ID <N>:
<list style="hangout">
<t>IPv4 Prefix ERO TLV: 10.0.0.4/32, Strict</t>
<t>IPv4 Prefix ERO TLV: 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 style="hangout">
<t>LSA 149, LSA-ID <N>:
<list style="hangout">
<t>IPv4 Prefix ERO TLV: 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 style="hangout">
<t>LSA 149, LSA-ID <N1>:
<list style="hangout">
<t>IPv4 Prefix ERO TLV: 192.168.1.3, Loose</t>
<t>IPv4 Prefix ERO TLV: 192.168.1.6, Loose</t>
<t>Flags TLV: Down</t>
</list></t>
<t>LSA 149, LSA-ID <N2>:
<list style="hangout">
<t>IPv4 Prefix ERO subTLV: 192.168.1.5, Loose</t>
<t>IPv4 Prefix ERO subTLV: 192.168.1.6, Loose</t>
<t>Flags TLV: Down</t>
</list></t>
</list></t>
<t>R5 encodes its two paths to R3 as follows:</t>
<t><list style="hangout">
<t>LSA 149, LSA-ID <N1>:
<list style="hangout">
<t>IPv4 Prefix ERO subTLV: 192.168.1.2, Loose</t>
<t>IPv4 Prefix ERO subTLV: 192.168.1.3, Loose</t>
<t>Flags TLV: Down</t>
</list></t>
<t>LSA 149, LSA-ID <N2>:
<list style="hangout">
<t>IPv4 Prefix ERO subTLV: 192.168.1.6, Loose</t>
<t>IPv4 Prefix ERO subTLV: 192.168.1.3, Loose</t>
<t>Flags TLV: Down</t>
</list></t>
</list></t>
<t>
A receiving non-backbone router does see now all 4 paths and may decide
to load-balance across all or a subset of them.
</t>
</section>
</section> <!-- end 'Advertising Label Examples' -->
<section title="Inter Area Protocol Procedures">
<section title="Applicability">
<t>
Propagation of a MPLS LSP across an area boundary is a local policy decision.
</t>
</section>
<section title="Data plane operations">
<t>
If local policy dictates that a given ABR router needs to
re-advertise a MPLS LSPs from one area 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 area. 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">
<t>
If local policy dictates that a given ABR router needs to
re-advertise a MPLS LSPs from one area to another then it
must prepend its "Traffic-Engineering-ID" as a loose hop in the
Prefix ERO TLV list. Furthermore it MUST append teh Flags TLV and
set the 'Down' Bit.
</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Many thanks to Yakov Rekhter for his useful comments.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
This documents request allocation for one common OSPFv2 and OSPFv3
LSA Type and TLVs contained within.
</t>
<texttable anchor="iana_table" title="IANA allocations">
<ttcol align="left">LSA</ttcol>
<ttcol align="left">TLV</ttcol>
<ttcol align="left">LSA Type</ttcol>
<ttcol align="left">TLV Type</ttcol>
<ttcol align="right">#Occurence</ttcol>
<c>MPLS Label</c>
<c></c>
<c>149</c>
<c></c>
<c>>=0</c>
<c></c>
<c>IPv4 Prefix ERO</c>
<c></c>
<c>1</c>
<c>>=0</c>
<c></c>
<c>IPv6 Prefix ERO</c>
<c></c>
<c>2</c>
<c>>=0</c>
<c></c>
<c>Flags</c>
<c></c>
<c>3</c>
<c>0,1</c>
</texttable>
<t>
The MPLS Label LSA requires a new sub-registry, with a starting TLV
value of 1, and managed by Expert Review.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t> This document does not introduce any change in terms of OSPF
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.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.3630.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.5036.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.5250.xml"?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-gredler-rtgwg-igp-label-advertisement-03.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-previdi-filsfils-isis-segment-routing-02.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:52:20 |