One document matched: draft-gredler-rtgwg-igp-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-rtgwg-igp-label-advertisement-00" 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">
<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>
<!-- Another author who claims to be an editor -->
<date day="18" month="February" 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 trough 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,
traffic engineering and egress link load balancing.</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> 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 now creates forwarding state based on label
information it may make sense to distribute label by the IGP as
well. This section lists example applications of IGP distribution of
MPLS labels.</t>
<section title="Explicit One hop tunnels">
<t>Deployment of Loop free alternate backup technology <xref
target="RFC5286">RFC 5286</xref> 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>
<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 if {E -> H -> D} is a
viable backup path. Because the metric M4 {H -> MD} is higher than
the sum of the original primary path and the backup path, this
particular path would result in a loop and therefore is rejected.
</t>
<t><xref target="I-D.ietf-rtgwg-remote-lfa">Remote LFA</xref> has
introduced the notion of "remote" LFA neighbor. Router 'H' is the
remote LFA neighbor where backup traffic can get tunneled to.
</t>
<t> Now consider that the remote LFA neighbor 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 PLR router can now program a backup path
irrespective of the undesirable underlying layer-3 topology.
</t>
</section>
<section title="Egress ASBR Link Selection">
<t>In the ingress router 'S' is facing a <xref
target="egress-asbr-link-selection">dilemma</xref>. 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 ASBR3 and ASBR4, however it cannot control the
load of the links beyond the ASBRs, except manually tweaking the
BGP import policy and filtering out a certain prefix. It would be
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 (Network embedded/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 3 and 4) 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
ASBR3 or ASBR4 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>
</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 {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 technology
has got upper limits how much labels can get pushed on the label
stack. In fact an existing tunnel (LDP tunnel {S, R1, R2} an 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 ERO
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 and have all fate-sharing
and bandwidth utilization figures.
</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.
</t>
</section>
</section> <!-- Use case section end -->
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Thanks to Yakov Rehkter for his 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.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"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:14:29 |