Internet DRAFT - draft-bowers-rtgwg-mrt-applicability-to-8021qca

draft-bowers-rtgwg-mrt-applicability-to-8021qca







Routing Area Working Group                                     C. Bowers
Internet-Draft                                          Juniper Networks
Intended status: Informational                                 J. Farkas
Expires: January 4, 2016                                        Ericsson
                                                            July 3, 2015


Applicability of Maximally Redundant Trees to IEEE 802.1Qca Path Control
                            and Reservation
           draft-bowers-rtgwg-mrt-applicability-to-8021qca-01

Abstract

   IEEE 802.1Qca Path Control and Reservation (PCR) [IEEE8021Qca] uses
   the algorithm specified in [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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 4, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Bowers & Farkas          Expires January 4, 2016                [Page 1]

Internet-Draft    Applicability of MRT to IEEE 802.1Qca        July 2015


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  How 802.1Qca uses the MRT algorithm . . . . . . . . . . . . .   3
     2.1.  MRT Explicit Trees in 802.1Qca  . . . . . . . . . . . . .   3
     2.2.  'MRT with GADAG' Explicit Trees in 802.1Qca . . . . . . .   3
     2.3.  MRT Explicit Trees as Strict Trees  . . . . . . . . . . .   4
   3.  Other considerations  . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Unequal link metrics  . . . . . . . . . . . . . . . . . .   4
     3.2.  Computation of MRT-Blue and MRT-Red next-hops from the
           point of view of other nodes  . . . . . . . . . . . . . .   5
     3.3.  Recalculation of MRTs . . . . . . . . . . . . . . . . . .   5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Informative References  . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   IEEE 802.1Qaq Shortest Path Bridging (SPB) [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.
   [IEEE8021aq] and [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.  [IEEE8021aq] has been already incorporated in [IEEE8021Q].

   [IEEE8021Qca] is an amendment to [IEEE8021Q] that specifies explicit
   path control, bandwidth assignment, and protection mechanisms for
   data flows for bridged networks.  [IEEE8021Qca] is an extension to
   IS-IS that builds upon the ISIS-SPB extensions and extends them
   further as described in [I-D.ietf-isis-pcr].  These extensions
   (referred to here as ISIS-PCR) allow bridges to share the information
   needed to construct explicit trees.

   [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)
   [I-D.ietf-rtgwg-mrt-frr-architecture].



Bowers & Farkas          Expires January 4, 2016                [Page 2]

Internet-Draft    Applicability of MRT to IEEE 802.1Qca        July 2015


   This document is intended to explain the relationship between
   [IEEE8021Qca] and [I-D.ietf-rtgwg-mrt-frr-algorithm].  The text
   should not be interpreted as normative with respect to either.

2.  How 802.1Qca uses the MRT algorithm

   The algorithm for computing Maximally Redundant Trees in
   [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 [I-D.ietf-rtgwg-mrt-frr-architecture].  The
   computation described in [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.  [IEEE8021Qca] supports this mode of operation, but
   it also supports other modes of operation as described below.

2.1.  MRT Explicit Trees in 802.1Qca

   In [IEEE8021Qca], the flooding of an SPB Instance sub-TLV ([RFC6329])
   with the MRT ECT Algorithm value in the absence of a Topology sub-TLV
   ([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 [I-D.ietf-rtgwg-mrt-frr-algorithm].

   In addition, [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 [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.

   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.

2.2.  'MRT with GADAG' Explicit Trees in 802.1Qca

   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 [I-D.ietf-rtgwg-mrt-frr-algorithm].  Each
   node then applies the algorithm steps in section 5.6.5 of




Bowers & Farkas          Expires January 4, 2016                [Page 3]

Internet-Draft    Applicability of MRT to IEEE 802.1Qca        July 2015


   [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.

   [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 [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.

   This behavior is controlled in [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.

2.3.  MRT Explicit Trees as Strict Trees

   A Path Computation Element can also implement each computation step
   of [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.

3.  Other considerations

3.1.  Unequal link metrics

   [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 [IEEE8021aq], [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, [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
   [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.

   This modification of link metrics applies ONLY to [IEEE8021Qca].
   When the MRT lowpoint inheritance algorithm in



Bowers & Farkas          Expires January 4, 2016                [Page 4]

Internet-Draft    Applicability of MRT to IEEE 802.1Qca        July 2015


   [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.

3.2.  Computation of MRT-Blue and MRT-Red next-hops from the point of
      view of other nodes

   In the algorithm described in [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.

   In some scenarios, a bridge using [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 [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.

   This does not modify the MRT algorithm with respect to its use for
   the IP/LDP FRR application as described in
   [I-D.ietf-rtgwg-mrt-frr-architecture].

3.3.  Recalculation of MRTs

   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.

   In 802.1Qca, recalculation of MRTs after a topology change follows
   the general method specified in Section 12.2 of
   [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



Bowers & Farkas          Expires January 4, 2016                [Page 5]

Internet-Draft    Applicability of MRT to IEEE 802.1Qca        July 2015


   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
   [I-D.ietf-rtgwg-mrt-frr-architecture], at this point it is safe
   recompute and install the new MRTs corresponding to the new topology.

   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
   [IEEE8021aq] and also described in [AP].

   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.

4.  IANA Considerations

   This document introduces no new IANA Considerations.

5.  Security Considerations

   The ISIS-PCR extensions for the use of the MRT algorithm are not
   believed to introduce new security concerns.

6.  Acknowledgements

   The authors would like to thank Alvaro Retana for his suggestions and
   review.

7.  Informative References

   [AP]       Seaman, M., "Agreement Protocol", September 7, 2010,
              <http://www.ieee802.org/1/files/public/docs2010/
              aq-seaman-agreement-protocol-0910-v2.pdf>.

   [I-D.ietf-isis-pcr]
              Farkas, J., Bragg, N., Unbehagen, P., Parsons, G.,
              Ashwood-Smith, P., and C. Bowers, "IS-IS Path Computation
              and Reservation", draft-ietf-isis-pcr-00 (work in
              progress), April 2015.






Bowers & Farkas          Expires January 4, 2016                [Page 6]

Internet-Draft    Applicability of MRT to IEEE 802.1Qca        July 2015


   [I-D.ietf-rtgwg-mrt-frr-algorithm]
              Envedi, G., Csaszar, A., Atlas, A., Bowers, C., and A.
              Gopalan, "Algorithms for computing Maximally Redundant
              Trees for IP/LDP Fast- Reroute", draft-ietf-rtgwg-mrt-frr-
              algorithm-02 (work in progress), January 2015.

   [I-D.ietf-rtgwg-mrt-frr-architecture]
              Atlas, A., Kebler, R., Bowers, C., Envedi, G., Csaszar,
              A., Tantsura, J., and R. White, "An Architecture for IP/
              LDP Fast-Reroute Using Maximally Redundant Trees", draft-
              ietf-rtgwg-mrt-frr-architecture-05 (work in progress),
              January 2015.

   [IEEE8021aq]
              IEEE 802.1, "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", 2012,
              <http://standards.ieee.org/getieee802/
              download/802.1aq-2012.pdf>.

   [IEEE8021Q]
              IEEE 802.1, "IEEE 802.1Q-2014: IEEE Standard for Local and
              metropolitan area networks - Bridges and Bridged
              Networks", 2014, <http://standards.ieee.org/findstds/
              standard/802.1Q-2014.html>.

   [IEEE8021Qca]
              IEEE 802.1, "IEEE 802.1Qca Bridges and Bridged Networks -
              Amendment: Path Control and Reservation - Draft 2.1",
              (work in progress), June 23, 2015,
              <http://www.ieee802.org/1/pages/802.1ca.html>.

   [RFC6329]  Fedyk, D., Ashwood-Smith, P., Allan, D., Bragg, A., and P.
              Unbehagen, "IS-IS Extensions Supporting IEEE 802.1aq
              Shortest Path Bridging", RFC 6329, April 2012.

Authors' Addresses

   Chris Bowers
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089
   US

   Email: cbowers@juniper.net





Bowers & Farkas          Expires January 4, 2016                [Page 7]

Internet-Draft    Applicability of MRT to IEEE 802.1Qca        July 2015


   Janos Farkas
   Ericsson
   Konyves Kalman krt. 11/B
   Budapest  1097
   Hungary

   Email: janos.farkas@ericsson.com












































Bowers & Farkas          Expires January 4, 2016                [Page 8]