One document matched: draft-ietf-isis-mpls-elc-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-isis-mpls-elc-01" ipr="trust200902">
<front>
<title abbrev="Signallng ELC Using IS-IS">Signaling Entropy Label
Capability Using IS-IS</title>
<author fullname="Xiaohu Xu" initials="X.X." surname="Xu">
<organization>Huawei</organization>
<address>
<!--
<postal>
<street></street>
-->
<!-- Reorder these if your country does things differently -->
<!--
<city>Soham</city>
<region></region>
<code></code>
<country>UK</country>
</postal>
<phone>+44 7889 488 335</phone>
-->
<email>xuxiaohu@huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Sriganesh Kini" initials="S.K." surname="Kini">
<organization>Ericsson</organization>
<address>
<!--
<postal>
<street></street>
-->
<!-- Reorder these if your country does things differently -->
<!--
<city>Soham</city>
<region></region>
<code></code>
<country>UK</country>
</postal>
<phone>+44 7889 488 335</phone>
-->
<email>sriganesh.kini@ericsson.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Siva Sivabalan" initials="S.S." surname="Sivabalan">
<organization>Cisco</organization>
<address>
<!--
<postal>
<street></street>
-->
<!-- Reorder these if your country does things differently -->
<!--
<city>Soham</city>
<region></region>
<code></code>
<country>UK</country>
</postal>
<phone>+44 7889 488 335</phone>
-->
<email>msiva@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Clarence Filsfils" initials="C.F." surname="Filsfils">
<organization>Cisco</organization>
<address>
<!--
<postal>
<street></street>
-->
<!-- Reorder these if your country does things differently -->
<!--
<city>Soham</city>
<region></region>
<code></code>
<country>UK</country>
</postal>
<phone>+44 7889 488 335</phone>
-->
<email>cfilsfil@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Stephane Litkowski" initials="S.L." surname="Litkowski">
<organization>Orange</organization>
<address>
<!--
<postal>
<street></street>
-->
<!-- Reorder these if your country does things differently -->
<!--
<city>Soham</city>
<region></region>
<code></code>
<country>UK</country>
</postal>
<phone>+44 7889 488 335</phone>
-->
<email>stephane.litkowski@orange.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<!--
-->
<date year=""/>
<abstract>
<t>Multi Protocol Label Switching (MPLS) has defined a mechanism to load
balance traffic flows using Entropy Labels (EL). An ingress LSR cannot
insert ELs for packets going into a given tunnel unless an egress LSR
has indicated that it can process ELs for that tunnel. This draft
defines a mechanism to signal that capability using IS-IS. This
mechanism is useful when the label advertisement is also done via
IS-IS.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Multi Protocol Label Switching (MPLS) has defined a method in <xref
target="RFC6790"/> to load balance traffic flows using Entropy Labels
(EL). An ingress LSR cannot insert ELs for packets going into a given
tunnel unless an egress LSR has indicated that it can process ELs for
that tunnel. <xref target="RFC6790"/> defines the signaling of this
capability (a.k.a Entropy Label Capability - ELC) via signaling
protocols. Recently, mechanisms are being defined to signal labels via
link state Interior Gateway Protocols (IGP) such as IS-IS <xref
target="I-D.ietf-isis-segment-routing-extensions"/>. In such scenario
the signaling mechanisms defined in <xref target="RFC6790"/> are
inadequate. This draft defines a mechanism to signal the ELC using
IS-IS. This mechanism is useful when the label advertisement is also
done via IS-IS. In addition, in the cases where stacked LSPs are used
for whatever reasons (e.g., SPRING-MPLS <xref
target="I-D.ietf-spring-segment-routing-mpls"/>), it would be useful for
ingress LSRs to know each LSR's capability of reading the maximum label
stack deepth. This capability, referred to as Readable Label Deepth
Capability (RLDC) can be used by ingress LSRs to determine whether it's
necessary to insert an EL for a given LSP tunnel in the case where there
has already been at least one EL in the label stack <xref
target="I-D.ietf-mpls-spring-entropy-label"/> . Of course, even it has
been determined that it's neccessary to insert an EL for a given LSP
tunnel, if the egress LSR of that LSP tunnel has not yet indicated that
it can process ELs for that tunnel, the ingress LSR MUST NOT include an
entropy label for that tunnel as well.</t>
<section 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>
</section>
</section>
<section anchor="Abbreviations_Terminology" title="Terminology">
<t>This memo makes use of the terms defined in <xref target="RFC6790"/>
and <xref target="RFC4971"/>.</t>
</section>
<section anchor="ELC_ISIS" title="Advertising ELC using IS-IS">
<t>The IS-IS Router CAPABILITY TLV defined in <xref target="RFC4971"/>
is used by IS-IS routers to announce their capabilities. A new sub-TLV
of this TLV, called ELC sub-TLV is defined to advertise the capability
of the router to process the ELs. It is formatted as described in <xref
target="RFC5305"/> with a Type code to be assigned by IANA and a Length
of zero. The scope of the advertisement depends on the application but
it is RECOMMENDED that it SHOULD be domain-wide. If a router has
multiple linecards, the router MUST NOT advertise the ELC unless all of
the linecards are capable of processing ELs.</t>
</section>
<section title="Advertising RLDC using IS-IS">
<t>A new sub-TLV of the IS-IS Router CAPABILITY TLV, called RLDC sub-TLV
is defined to advertise the capability of the router to read the maximum
label stack depth. It is formatted as described in <xref
target="RFC5305"/> with a Type code to be assigned by IANA and a Length
of one. The Value field is set to the maximum readable label stack
deepth in the range between 1 to 255. The scope of the advertisement
depends on the application but it is RECOMMENDED that it SHOULD be
domain-wide. If a router has multiple linecards with different
capabilities of reading the maximum label stack deepth, the router MUST
advertise the smallest one in the RLDC sub-TLV.</t>
</section>
<!---->
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Yimin Shen and George Swallow for
their valuable comments on the draft.</t>
<!---->
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes a request to IANA to allocate two sub-TLV types
within the IS-IS Router Capability TLV.</t>
<!---->
</section>
<section anchor="Security" title="Security Considerations">
<t>This document does not introduce any new security risk.</t>
<!---->
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
<?rfc include="reference.RFC.5305"?>
<?rfc include="reference.RFC.4971"?>
<!---->
</references>
<references title="Informative References">
<!---->
<?rfc include="reference.I-D.ietf-spring-segment-routing-mpls"?>
<?rfc include="reference.I-D.ietf-isis-segment-routing-extensions"?>
<?rfc include="reference.RFC.6790"?>
<?rfc include="reference.I-D.ietf-mpls-spring-entropy-label"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:59:17 |