One document matched: draft-bowers-rtgwg-mrt-applicability-to-8021qca-00.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-00" 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="13" month="February" 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.farkas-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.
    </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.farkas-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 Traffic End Point.  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-tree
    rooted at that node is constructed.
    </t> 
    <t>
    Note that the Traffic End Point
    flag does not affect the construction of the MRT trees.  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>
     
    
    <section anchor="IANA" title="IANA Considerations">
      <t>This document introduces no new IANA Considerations.
      </t>
    </section>
    
    <section title="Security Considerations">
      <t> These 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 1.4</title>
          <author>
            <organization>IEEE 802.1</organization>
          </author>
          <date year="(work in progress), February 12, 2015" />
        </front>
    </reference>

    
    <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-farkas-isis-pcr-01.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>