One document matched: draft-gredler-rtgwg-igp-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-rtgwg-igp-label-advertisement-03" ipr="trust200902">
<!-- ***** FRONT MATTER ***** -->
<front>
<title>Advertising MPLS labels in IGPs</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>WA</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="5" month="April" year="2013"/>
<area>Routing</area>
<workgroup>Routing Area Working Group</workgroup>
<keyword>MPLS</keyword>
<keyword>IGP</keyword>
<keyword>Label advertisement</keyword>
<abstract>
<t>Historically MPLS label distribution was driven by session
oriented protocols. In order to obtain a particular routers label
binding for a given destination FEC one needs to have first an
established session with that node.</t>
<t>This document describes a mechanism to distribute FEC/label
mappings through flooding protocols. Flooding protocols publish their
objects for an unknown set of receivers, therefore one can efficiently
scale label distribution for use cases where the receiver of label
information is not directly connected.</t>
<t>Application of this technique are found in the field of
backup (LFA) computation, Label switched path stitching,
egress protection, traffic engineering and egress ASBR link selection.</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 learn the Label Information database of a particular router
one needs to have a direct control-plane session using the given
protocol.</t>
<t>There are a couple of interesting use cases where the
consumer of a MPLS label allocation may not be adjacent to the router
having allocated the label. Bringing up an explicit session using
existing label distribution protocols between the non-adjacent label
allocator and the label consumer is the existing remedy for this
dilemma.</t>
<t>For LDP protection routing <xref
target="NNHOP">LDP next next hop
labels</xref> have been proposed to provide the 2 hop neighborhood
labels. While the 2 hop neighborhood provides good backup coverage for
the typical network operator topology it is inadequate for some sparse
for example ring like topologies.</t>
<t> Depending on the application, retrieval and setup of
forwarding state of such >1 hop label allocations may only be
transient. As such configuring and un-configuring the explicit session
is an operational burden and therefore should be avoided.</t>
</section>
<section title="Motivation and Applicability">
<t>It may not be immediate obvious, however introduction of
<xref target="I-D.ietf-rtgwg-remote-lfa">Remote LFA</xref> technology
has implied important changes for an IGP implementation. Previously
the IGP had a one-way communication path with the LDP module. The IGP
supplies tracking routes and LDP selects the best neighbor based upon
FEC to tracking routes exact matching results. Remote LFA changes that
relationship such that there is a bi-directional communication path
between the IGP and LDP. Now the IGP needs to learn about if a label
switched path to a given destination prefix has been established and
what the ingress label for getting there is. The IGP needs to push
that label for the tracking routes of destinations beyond a remote
LFA neighbor.</t>
<t>Since the IGP is now aware of label switched paths
and it does create forwarding state based on label information it
makes sense to distribute label switched paths by the IGP as
well.
</t>
</section>
<section title="Use cases for IGP label distribution">
<t>
This section lists example use cases which illustrate IGP
distribution of MPLS label switched paths.
</t>
<section title="Increase LFA backup coverage using 'Directed Forwarding'">
<t>Deployment of Loop free alternate backup technology <xref
target="RFC5286"/> results in backup graphs whose
coverage is highly dependent on the underlying Layer-3 topology.
Typical network deployments provide backup coverage less than 100
percent (see <xref target="RFC6571">RFC 6571 Section 4.3 for
Results</xref>) for IGP destination prefixes.
</t>
<t>By closer examining the coverage gaps from the referenced
production network topologies, it becomes obvious that most topologies
lacking backup coverage are close to <xref
target="coverage-gap-analysis">ring shaped topologies</xref>.
</t>
<t><xref target="I-D.ietf-rtgwg-remote-lfa">Remote LFA</xref> has
introduced the notion of a "remote" LFA neighbor. This helper router
which is both in P and Q space could forward the traffic to the
final destination. Router 'H' is in P space, however due to
the actual metric allocation router 'H' is not in Q space.
</t>
<figure anchor="coverage-gap-analysis" title="Coverage gap analysis">
<artwork><![CDATA[
+-----+
| D |
+-----+
/ \
/ M1 \ M4 >= (M1 + M2 + M3)
/ \
+-----+ +-----+
| PLR | | H |
+-----+ +-----+
\ /
\ M2 / M3
\ /
+-----+
| E |
+-----+
]]></artwork>
</figure>
<t>The protection router (PLR) evaluates for a primary path to
destination 'D' if {E -> H -> D} is a viable backup path. Because the
metric M4 {H -> D} is higher than the sum of the original primary path
and the path from router 'H' to the PLR, this particular path would
result in a loop and therefore is rejected.</t>
<t> Now consider that router 'H' would advertise a label for
FEC 'D', which has the semantics that H will POP the label and forward
to the destination node 'D'. This is done irrespective of the
underlying IGP metric 'M4' it is a 'strict forwarding' label. The PLR
router can now construct a label stack where the outermost label
provides transport to router 'H'. The next label on the MPLS stack is
the IGP learned 'strict forwarding label' label. Note that the label
'strict forwarding' semantics are similar to a 1-hop ERO (Explicit
route object). The Remote 'LFA' calculation would need to get changed,
such that even if a node is not in PQ space, but rather in P space, it
may get used as a backup neighbor if it advertises a strict forwarding
label to the final destination. A recursive version of the algorithm
is applicable as well as long a node in P space has some non looping
LSP path to the final destination. The PLR router can now program a
backup path irrespective of the undesirable underlying layer-3
topology.</t>
<!-- FIXME add link to bridge disjoint P and Q node -->
<t>Using existing tunnels for backup routing has been
previously described in <xref
target="I-D.bryant-ipfrr-tunnels"></xref>. Section 5.2.3 'Directed
forwarding' describes an option to insert a single MPLS label between
the tunnel and the payload. Traffic may thereby be directed to a particular
neighbor. The mechanism described in this document, is an MPLS specific
manifestation of 'Directed forwarding'.
</t>
</section>
<section title="Egress ASBR Link Selection">
<t>In the topology described in <xref
target="egress-asbr-link-selection"></xref>. router 'S' is facing a
dilemma. Router S receives a BGP route from all of its 4 upstream
routers. Using existing mechanism the provider owning AS1 can control
the loading of its direct links *to* its ASBR1 and ASBR2, however it
cannot control the load of the links beyond the ASBRs, except manually
tweaking the eBGP import policy and filtering out a certain prefix. It
would be more desirable to have visibility of all four BGP paths
and be able to control the loading of those four paths using Weighted
ECMP. Note that the computation of the 'Weight' percentage and the
component doing this computation (Router embedded or SDN) is outside the
scope of this document.</t>
<t>If all the ASes would be under one common administrative
control then the network operator could deploy a forwarding hierarchy
by using <xref target="RFC3107"/> to learn about the remote-AS BGP
nexthop addresses and associated labels. An ingress router 'S' would
then stack the transport label to its local egress ASBR and the remote
ASBR supplied label. In reality it is hard to convince a peering AS to
deploy another protocol just in order to easier control the egress
load on the WAN links for the ingress AS.</t>
<t>A 'strict forwarding' paradigm would solve this problem: An
Egress ASBR (e.g. ASBR 1 and 2) allocates a strict forwarding label
toward all of its peering ASes and advertises it into its local
IGP. The forwarding state of all those labels is to POP off the label
and forward to the respective interface. The ingress router 'S' then
builds a MPLS label stack by combining its local transport label to
ASBR1 or ASBR2 with the IGP learned label pointing to the remote-AS
ASBR.</t>
<figure anchor="egress-asbr-link-selection" title="Egress ASBR Link selection">
<artwork><![CDATA[
-------------traffic-flow--------->
<-----------signaling-flow---------
:
: AS3
: +-------+
AS1 _:___+ ASBR3 |
/ : +-------+
+-------+ :
| ASBR1 | : AS4
+-------+ : +-------+
/ \_:___+ ASBR4 |
/ : +-------+
/ :
+-----+ :
| S | :
+-----+ : AS5
\ : +-------+
\ _:___+ ASBR5 |
\ / : +-------+
+-------+ :
| ASBR2 | : AS6
+-------+ : +-------+
\_:___+ ASBR6 |
: +-------+
:
]]></artwork>
</figure>
<t>
ASBR {1,2} may want to periodically check the liveliness state to
the endpoint of the label (ASBR {3,4,5,6}) which they are advertising.
<xref target="RFC5880">BFD Echo mode</xref> is suitable technology to ensure
liveliness state of undirectional links.
</t>
</section>
<section title="Tail end protection of BGP service routes">
<t>
<xref target="I-D.minto-2547-egress-node-fast-protection"/> describes
how PE routers advertising their labeled routes could get protected from
node-failures. This is a local repair technology being dependent upon successful
construction of a LFA path from any PLR to the 'protector PE' in a network.
</t>
<figure anchor="ctx-advertisement" title="Backup Context advertisement">
<artwork><![CDATA[
>>>>>>>>CTX-label>>>>>>
// \\
// \\
+------+ +------+ +------+ +------+ +------+ +------+
| CE1 +---+PEingr+---+PEprot+---+ P +---+ PLR +-X-+PEegr +
+------+ +------+ +------+ +------+ +------+ +------+
\\ \ / //
>>>>>>>>>>>>>>>>>>>>>>primary-LSP>>>>>>>>
\ /
\ +------+ /
\___+ CE2 +____/
+------+
]]></artwork>
</figure>
<t>
Assume a primary LDP LSP from the 'ingress PE' router to the
'egress PE' router. Now consider the FRR calculation from the 'PLR'
router if its direct link to the 'egress PE' router fails (X) or the
entire 'egress PE' goes down. The 'PLR' cannot find a LFA path
to local-repair the traffic to the 'protector PE'. This is because
the 'protector PE' router has not yet converged, and hence would want
to forward the traffic to the original PE egress router, such that a
temporal forwarding loop would be established.
</t>
<t>
Using IGP advertisement of MPLS Labels the 'protector PE'
router can advertise a Label which identifies backup traffic such that
arriving traffic, can be forwarded using a context specific
forwarding table, rather than the main LSP transit table. The
advertised context label is a unidirectional pointer to the 'egress
PE' router. The LFA calculation of the PLR gets augmented such that
it considers advertised labels pointing to the original tail-end
of the LSP. The network learns thereby an egress LSP point
which is is as good as the original egress LSP point.
</t>
</section>
<section title="Explicit Path Routing through Label Stacking">
<t>IGP advertised strict forwarding labels can be utilized for
constructing simple EROs via virtue of the MPLS label stack. In <xref
target="ero-label-stacking">a classical traffic engineering
problem</xref> is illustrated. The best IGP path between {S,D} is {S,
R3, R4, D}. Unfortunately this path is congested. It turns out that
the links {S, R1}, {R1, R4} and {R2, R4} do have some spare capacity. In the
past a C-SPF calculation would have passed the ERO {S, R1, R4, R2, D}
down to RSVP for signaling. The conceptional problem with RSVP
signaled paths is that they cannot by shared with other nodes in the
network. Hence all potential ingress routers need to setup their
"private" ERO path and allocate network signaling resources and
forwarding state. </t>
<figure anchor="ero-label-stacking" title="Explicit Routing using Label stacking">
<artwork><![CDATA[
+----+ +----+
| R1 +---------+ R2 |
+----+ 2 +----+
/ \ | \
/ 2 \ | \ 2
/ \ | \
+-----+ \ | +-----+
| S | \ 5 | 5 | D |
+-----+ \ | +-----+
\ \ | /
\ 1 \ | / 1
\ \ | /
+----+ +----+
| R3 +---------+ R4 |
+----+ 1 +----+
]]></artwork>
</figure>
<t>Consider now every router along the path does advertise a
strict forwarding label for its direct neighbor. Router S could now
construct a couple of paths for avoiding the hot links without
explicitly signaling them.</t>
<t>
<list style="symbols">
<t>{S, R1, R2, D}</t>
<t>{S, R1, R4, D}</t>
<t>{S, R1, R4, R2, D}</t>
</list>
</t>
<t>Note that not every hop in the ERO needs to be unique label
in the label stack. This is undesired as existing forwarding hardware
technology has got upper limits how much labels can get pushed on the
label stack. In fact an existing tunnel (for example LDP tunnel {S,
R1, R2} can be reused for certain path segments.</t>
</section>
<section title="Stitching MPLS Label Switched Path Segments">
<t>
One of the shortcomings of existing traffic-engineering
solutions is that existing label switched paths cannot get advertised
and shared by many ingress routers in the network. In the <xref
target="advertising-path-segments">example network</xref> a LSP with an
ERO of {R4, R2, R6} has been established in order to utilize two
unused north / south links. The only way to attract traffic to that LSP
is to advertise the LSP as a forwarding adjacency. This causes loss of
the original path information which might be interesting for a potential router
which might wants to use this LSP for backup purposes. A computing router
would need to have all underlying fate-sharing and bandwidth utilization
information.
</t>
<figure anchor="advertising-path-segments" title="Advertising path segments">
<artwork><![CDATA[
+----+ +----+ +----+
| R1 +---------+ R2 +---------+ R5 |
+----+ 2 +----+ 2 +----+
/ \ | \ \
/ 2 \ | \ \ 2
/ \ | \ \
+----+ \ | \ +----+
| S | \ 5 | 5 \ 5 | D |
-----+ \ | \ +----+
\ \ | \ /
\ 1 \ | \ / 1
\ \ | \ /
+----+ +----+ +----+
| R3 +---------+ R4 |---------+ R6 |
+----+ 1 +----+ 1 +----+
]]></artwork>
</figure>
<t>
The IGP on R4 can now advertise the LSP segment by advertising its ingress label
and optionally pass the original ERO, such that any upstream router can do
their fate-sharing computations. Potential ingress routers now can use
this LSP as a segment of the overall LSP. Furthermore ingress routers can
combine label advertisements from different routers along the path.
For example router S could stacks its LDP path to R2 {S, R1, R2} plus
the IGP learned RSVP LSP {R4, R5, R6} plus a strict forwarding label {R6, D}.
</t>
</section>
</section> <!-- Use case section end -->
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Many thanks to Yakov Rehkter, Ina Minei, Stephane Likowski and Bruno
Decraene for their useful comments.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t> This document does not introduce any change in terms of IGP
security. It simply proposes to flood existing information gathered from
other protocols via the IGP.
</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.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.5286.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5880.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6571.xml"?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-rtgwg-remote-lfa-01.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-bryant-ipfrr-tunnels-03.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-minto-2547-egress-node-fast-protection-01.xml"?>
<!-- expired drafts -->
<reference anchor="NNHOP" target="http://tools.ietf.org/html/draft-shen-mpls-ldp-nnhop-label-02">
<front>
<title>Discovering LDP Next-Nexthop Labels</title>
<author fullname="Enke" initials="E." surname="Chen">
<organization>Cisco Systems, Inc.</organization>
</author>
<author fullname="Naiming" initials="N." surname="Shen">
<organization>Cisco Systems, Inc.</organization>
</author>
<author fullname="Albert" initials="A." surname="Tian">
<organization>Redback Networks</organization>
</author>
<date month = "November" year="2005" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:13:35 |