One document matched: draft-bowers-rtgwg-mrt-applicability-to-8021qca-01.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc comments="yes"?>
<?rfc compact="yes"?>
<?rfc inline="yes"?>
<?rfc sortrefs="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc tocompact="yes"?>
<rfc category="info" docName="draft-bowers-rtgwg-mrt-applicability-to-8021qca-01" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="Applicability of MRT to IEEE 802.1Qca">
Applicability of Maximally Redundant Trees to IEEE 802.1Qca Path Control and Reservation
</title>
<author fullname="Chris Bowers" initials="C." surname="Bowers">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1194 N. Mathilda Ave.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>US</country>
</postal>
<email>cbowers@juniper.net</email>
</address>
</author>
<author fullname="János Farkas" initials="J." surname="Farkas">
<organization>Ericsson</organization>
<address>
<postal>
<street>Konyves Kálmán krt. 11/B</street>
<city>Budapest</city>
<country>Hungary</country>
<code>1097</code>
</postal>
<email>janos.farkas@ericsson.com</email>
</address>
</author>
<date day="3" month="July" year="2015"/>
<area>Routing</area>
<workgroup>Routing Area Working Group</workgroup>
<abstract>
<t> IEEE 802.1Qca Path Control and Reservation (PCR) <xref
target="IEEE8021Qca"/> uses the algorithm specified in <xref
target="I-D.ietf-rtgwg-mrt-frr-algorithm"/> to compute Maximally
Redundant Trees (MRTs) to be used for the protection of data
traffic in bridged networks. This document discusses the
applicability of the MRT algorithm to 802.1Qca.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
IEEE 802.1Qaq Shortest Path Bridging (SPB) <xref
target="IEEE8021aq"/> is an amendment to IEEE Std 802.1Q that
allows bridged frames to travel on the shortest path between
their source and destination(s), as opposed to traveling along
paths determined by shared spanning trees. <xref
target="IEEE8021aq"/> and <xref target="RFC6329"/> specify
extensions to IS-IS that allow bridges to share the topology
information needed to construct shortest path trees. These
extensions are referred to here as ISIS-SPB. <xref
target="IEEE8021aq"/> has been already incorporated in <xref
target="IEEE8021Q"/>.
</t>
<t> <xref target="IEEE8021Qca"/> is an amendment to <xref
target="IEEE8021Q"/> that specifies explicit path control,
bandwidth assignment, and protection mechanisms for data flows for
bridged networks. <xref target="IEEE8021Qca"/> is an extension to
IS-IS that builds upon the ISIS-SPB extensions and extends them
further as described in <xref target="I-D.ietf-isis-pcr"/>. These
extensions (referred to here as ISIS-PCR) allow bridges to share
the information needed to construct explicit trees.
</t>
<t> <xref target="IEEE8021Qca"/> specifies five different methods
for the construction of explicit trees as well as how to share the
information needed to construct these trees. These five different
methods of explicit trees are referred to as Strict Tree, Loose
Tree, Loose Tree Set, MRT, and MRT with GADAG. This document is
concerned with the MRT and 'MRT with GAGAG' explicit tree methods
(algorithms). Both methods produce Maximally Redundant Trees (MRTs) <xref
target="I-D.ietf-rtgwg-mrt-frr-architecture"/>.
</t>
<t> This document is intended to explain the relationship between
<xref target="IEEE8021Qca"/> and <xref
target="I-D.ietf-rtgwg-mrt-frr-algorithm"/>. The text should not
be interpreted as normative with respect to either.
</t>
</section>
<section title="How 802.1Qca uses the MRT algorithm">
<t> The algorithm for computing Maximally Redundant Trees in <xref
target="I-D.ietf-rtgwg-mrt-frr-algorithm"/> has been specified
with a focus on supporting fast-reroute for the protection of
unicast IP and LDP traffic, as described in <xref
target="I-D.ietf-rtgwg-mrt-frr-architecture"/>. The computation
described in <xref target="I-D.ietf-rtgwg-mrt-frr-algorithm"/>
starts with the topology of an IGP area, prunes it to form an MRT
Island topology, constructs a GADAG, and then uses that GADAG to
construct a complete set of destination-based MRT-Blue and MRT-Red
trees rooted at each node in the MRT Island, where each tree spans
all nodes in the MRT Island. <xref target="IEEE8021Qca"/>
supports this mode of operation, but it also supports other modes
of operation as described below.
</t>
<section title="MRT Explicit Trees in 802.1Qca">
<t> In <xref target="IEEE8021Qca"/>, the flooding of an SPB
Instance sub-TLV (<xref target="RFC6329"/>) with the MRT ECT
Algorithm value in the absence of a Topology sub-TLV (<xref
target="I-D.ietf-isis-pcr"/>) results in the creation of an
MRT-Blue and an MRT-Red tree rooted at each node in the domain,
and each tree spans all nodes in the domain. This is equivalent to
the behavior described in <xref
target="I-D.ietf-rtgwg-mrt-frr-algorithm"/>.
</t>
<t> In addition, <xref target="IEEE8021Qca"/> allows one to affect
both the number and structure of the MRT-Blue and Red trees by
including the Topology sub-TLV in the MT-Capability TLV (type 144
<xref target="RFC6329"/>). In the context of the MRT ECT
Algorithm, Hop sub-TLVs in the Topology sub-TLV specify nodes with
flags that can indicate Root, Exclude, or Edge Bridge. In
the context of the MRT algorithm, all nodes with the Exclude flag
set are excluded from the MRT Island. The GADAG is then computed
for the MRT Island. For each node with the Root flag set, an
MRT-Blue and an MRT-Red tree rooted at that node is constructed.
</t>
<t>
Note that the Edge Bridge flag does not affect the
construction of the MRTs. It is used to determine which
filtering database (FDB) entries to install once the trees have
been determined.
</t>
</section>
<section title="'MRT with GADAG' Explicit Trees in 802.1Qca">
<t> In the previous section, each node will compute the same GADAG
based on the same topology information using the algorithm steps
in sections 5.4 and 5.5 of <xref
target="I-D.ietf-rtgwg-mrt-frr-algorithm"/>. Each node then
applies the algorithm steps in section 5.6.5 of <xref
target="I-D.ietf-rtgwg-mrt-frr-algorithm"/> to that GADAG, in
order to compute the MRT-Blue and MRT-Red next-hops for the trees
of interest.
</t>
<t>
<xref target="IEEE8021Qca"/> can operate in a mode where each node
is supplied with a common GADAG (communicated via ISIS-PCR), from
which each node then determines the MRT-Blue and MRT-Red next-hops
for the trees of interest. That is, this mode of operation
bypasses the algorithm steps in section 5.4 and 5.5 of
<xref target="I-D.ietf-rtgwg-mrt-frr-algorithm"/>
and only applies the algorithm steps in section 5.6.5 to the
GADAG communicated directly via ISIS-PCR.
</t>
<t>
This behavior is controlled in <xref target="IEEE8021Qca"/> by
flooding an SPB Instance sub-TLV with the 'MRT with GADAG' ECT
Algorithm value as well as a Topology sub-TLV. Hop sub-TLVs in
this Topology sub-TLV are used to describe the common GADAG using
an ear decomposition. The first Hop sub-TLV is the GADAG root
followed by a sequence of Hop sub-TLVs describing an ordered ear
that terminates on the GADAG root. Subsequent ears are described
as sequences of Hop sub-TLVs. Setting the Root flag for a given
Hop sub-TLV indicates that MRT-Blue and Red trees rooted at that
node should be constructed.
</t>
</section>
<section title="MRT Explicit Trees as Strict Trees">
<t> A Path Computation Element can also implement each computation
step of <xref target="I-D.ietf-rtgwg-mrt-frr-algorithm"/> and
compute the MRTs. The MRTs can be then specified by Topology
sub-TLVs, one for each. The SPB Instance sub-TLV then conveys the
ST ECT Algorithm value.
</t>
</section>
</section>
<section title="Other considerations">
<section title="Unequal link metrics">
<t> <xref target="IEEE8021aq"/> specifies that if two SPB Link
Metrics are different at each end of a link, the maximum of the
two values is used in SPB calculations. In order to provide
symmetry and maintain consistency with <xref
target="IEEE8021aq"/>, <xref target="IEEE8021Qca"/> places the
same requirement on the Link Metrics for the topology graph that
is used in the MRT algorithm. In order to accomplish this, <xref
target="IEEE8021Qca"/> makes the same modification to link metrics
before applying the MRT algorithm. This change of metric values
can affect the ordering of interfaces on a given node through the
Interface_Compare function in section 5 of <xref
target="I-D.ietf-rtgwg-mrt-frr-algorithm"/>, which in turn can
affect the GADAG computed. The change of metric values can also
affect the results of the SPF_No_Traverse_Root function used in
determining MRT next-hops, since the SPF traversal depends on
metric values.
</t>
<t> This modification of link metrics applies ONLY to <xref
target="IEEE8021Qca"/>. When the MRT lowpoint inheritance
algorithm in <xref target="I-D.ietf-rtgwg-mrt-frr-algorithm"/> is
applied to IP/LDP FRR, the topology graph with the link metrics
advertised by the IGP are used without modification by the MRT
algorithm.
</t>
</section>
<section title="Computation of MRT-Blue and MRT-Red next-hops from the point of view of other nodes">
<t> In the algorithm described in <xref
target="I-D.ietf-rtgwg-mrt-frr-algorithm"/> a given node computes
and installs its own MRT-Blue and MRT-Red next-hops for all
destinations. This computation is all that is required for the
IP/LDP FRR application to function properly. An individual node
does not need to compute the MRT-Blue and MRT-Red next-hops used
by other nodes. Instead the complete MRT tree structure is
created in the network as the result of each node computing and
installing the appropriate MRT next-hops. This is analogous to
the way that shortest path trees are instantiated in shortest path
routing, with each node needing to compute and install only its
own shortest path next-hops.
</t>
<t> In some scenarios, a bridge using <xref target="IEEE8021Qca"/>
may need to know more than just its own MRT-Blue and MRT-Red
next-hops. This can be accomplished by having a bridge perform
the MRT next-hop computation specified in section 5.6.5 of <xref
target="I-D.ietf-rtgwg-mrt-frr-algorithm"/> from the point of view
of one or more other bridges. The result of computing an MRT
next-hop from the point of view of another bridge is the normative
result. An implementation may use another method to compute MRT
next-hops from the point of view of remote bridges as long as it
produces the same result.
</t>
<t> This does not modify the MRT algorithm with respect to its use
for the IP/LDP FRR application as described in <xref
target="I-D.ietf-rtgwg-mrt-frr-architecture"/>.
</t>
</section>
<section title="Recalculation of MRTs">
<t>MRTs can be used for the protection of SPTs in a bridged
network similarly to IP/LDP FRR application of MRTs. A pair of
MRT-Blue and MRT-Red then protect the SPT rooted at the MRT
Root. The MRTs are only used for protection, i.e. MRTs do not
carry traffic during normal operation, similarly to IP/LDP FRR
operations. The Point of Local Repair (PLR) is responsible for
redirecting traffic from SPTs to MRTs upon detection of a failure
event.</t>
<t>In 802.1Qca, recalculation of MRTs after a topology change
follows the general method specified in Section 12.2 of <xref
target="I-D.ietf-rtgwg-mrt-frr-architecture"/>, with an additional
requirement. Immediately after a failure, the PLR or PLRs
redirect some traffic onto MRTs. In the meantime, all nodes
receive notification of the failure, recompute SPTs, and install
them in their FIBs. The PLRs take the traffic off of the MRTs,
and put the traffic on the new SPTs. Based on <xref
target="I-D.ietf-rtgwg-mrt-frr-architecture"/>, at this point it
is safe recompute and install the new MRTs corresponding to the
new topology.</t>
<t>802.1Qca places an additional requirement on when it is safe to
install the new MRTs. The new MRTs should not be recomputed and
installed if there is any reason to suspect that the nodes of the
domain do not share a common view on the network topology. This
is in order to prevent loops in the MRT paths that may be used by
PLRs at the next failure event. The loop prevention method to be
used for MRTs in 802.1Qca is the Agreement Protocol, which is
specified in <xref target="IEEE8021aq"/> and also described in
<xref target="AP"/>. </t>
<t> Note that while 802.1Qca requires that the Agreement Protocol
be used to avoid loops on MRTs, it does not mandate the use of the
Agreement Protocol for the shortest path trees, where other loop
mitigation techniques can be used.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document introduces no new IANA Considerations.</t>
</section>
<section title="Security Considerations">
<t> The ISIS-PCR extensions for the use of the MRT algorithm
are not believed to introduce new security concerns.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements" toc="default">
<t> The authors would like to thank Alvaro Retana for his suggestions and review.
</t>
</section>
</middle>
<back>
<references title="Informative References">
<reference anchor="IEEE8021aq" target="http://standards.ieee.org/getieee802/download/802.1aq-2012.pdf">
<front>
<title>IEEE 802.1aq: IEEE Standard for Local and
metropolitan area networks - Media Access Control (MAC)
Bridges and Virtual Bridged Local Area Networks - Amendment
20: Shortest Path Bridging</title>
<author>
<organization>IEEE 802.1</organization>
</author>
<date year="2012" />
</front>
</reference>
<reference anchor="IEEE8021Q" target="http://standards.ieee.org/findstds/standard/802.1Q-2014.html">
<front>
<title>IEEE 802.1Q-2014: IEEE Standard for Local and
metropolitan area networks - Bridges and Bridged
Networks</title>
<author>
<organization>IEEE 802.1</organization>
</author>
<date year="2014" />
</front>
</reference>
<reference anchor="IEEE8021Qca" target="http://www.ieee802.org/1/pages/802.1ca.html">
<front>
<title>IEEE 802.1Qca Bridges and Bridged Networks -
Amendment: Path Control and Reservation - Draft 2.1</title>
<author>
<organization>IEEE 802.1</organization>
</author>
<date year="(work in progress), June 23, 2015" />
</front>
</reference>
<reference anchor="AP" target="http://www.ieee802.org/1/files/public/docs2010/aq-seaman-agreement-protocol-0910-v2.pdf">
<front>
<title>Agreement Protocol</title>
<author initials="M." surname="Seaman"
fullname="Mick Seaman">
</author>
<date year="September 7, 2010" />
</front>
</reference>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-isis-pcr-00.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-rtgwg-mrt-frr-algorithm-02.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-rtgwg-mrt-frr-architecture-05.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6329.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 11:10:50 |