[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00

LSR Working Group                                            Dave Allan
Internet Draft                                                 Ericsson
Intended status: Standards Track                           October 2018
Expires: April 2019




          A Distributed Algorithm for Constrained Flooding of IGP
                              Advertisements
                   draft-allan-lsr-flooding-algorithm-00


Abstract


   This document describes a distributed algorithm that can be applied
   to the problem of constraining IGP flooding in dense mesh
   topologies. The flooding topology utilizes two node-diverse spanning
   trees in order to provide complete coverage in the presence of any
   single failure while constraining the number of LSAs received by any
   IGP speaker connected to the flooding topology.


Status of this Memo

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

   Internet-Drafts are working documents of the Internet
   Engineering Task Force (IETF), its areas, and its working
   groups.  Note that other groups may also distribute working
   documents as Internet-Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire in March 2019.

Copyright and License Notice



Allan,                    Expires April 2019                   [Page 1]


Internet-Draft    draft-allan-lsr-flooding-algorithm       October 2018


   Copyright (c) 2018 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 the Trust Legal Provisions and are provided
   without warranty as described in the Simplified BSD License.

Table of Contents

   1. Introduction...................................................3
   1.1. Authors......................................................3
   1.2. Requirements Language........................................3
   2. Conventions used in this document..............................3
   2.1. Terminology..................................................3
   3. Solution Overview..............................................4
   3.1. The Flooding Topology........................................4
   3.2. Solution Applicability.......................................4
   3.3. Algorithm....................................................4
   3.3.1. Algorithm Basics...........................................5
   3.3.2. Generating Diverse Trees...................................5
   3.3.3. Desirable Properties Computation Wise......................6
   4. Applying the Algorithm.........................................6
   4.1. Tree Generation..............................................6
   4.2. Illustrating the result......................................6
   4.3. Interactions between Participating and Non-Participating
   Nodes.............................................................7
   4.4. Flooding of LSAs.............................................8
   4.5. Root Selection...............................................9
   4.6. Node Additions...............................................9
   5. Further work..................................................10
   5.1. Thoughts on Coexistence in the Context of a Larger Network..10
   5.1.1. Multiple flooding Domains and the Severing of Flooding
   Domains..........................................................10
   5.2. Thoughts on Flooding Topology Re-Optimization...............10
   5.3. Thoughts on Node and Network Initialization.................11
   5.4. Thoughts on Loop Prevention.................................11
   5.5. Thoughts on Pathological Failure Scenarios..................11
   6. Acknowledgements..............................................12
   7. Security Considerations.......................................12
   8. IANA Considerations...........................................12
   9. References....................................................12

Allan et al.,             Expires April 2019                   [Page 2]


Internet-Draft    draft-allan-lsr-flooding-algorithm       October 2018


   9.1. Normative References........................................12
   9.2. Informative References......................................12
   10. Author's Address.............................................13


1. Introduction

   This memo describes an algorithm suitable for reducing the quantity
   of IGP flooding in dense mesh networks.  The only property that the
   algorithm is dependent upon is that there are at least two equal and
   diverse shortest paths between any pair of IGP speakers in order to
   meet the requirements elucidated in [Li].  The algorithm uses a re-
   purposing of the tie breaking algorithm used in 802.1aq Shortest Path
   Bridging as an element of construction of the flooding topology.
   It is not the intention of this memo to specify a complete solution,
   but to offer a foundation of an eventual solution.
1.1. Authors

   David Allan

1.2. Requirements Language

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

2. Conventions used in this document

2.1. Terminology

   Member Adjacency - An adjacency that has been determined to part of
   the flooding topology.

   Member Node - A Participant node that is connected to the flooding
   topology.

   Participant Adjacency - An adjacency between two participating nodes.
   It may be a member adjacency or a non-member adjacency

   Non-Participant Adjacency - An adjacency where at least one of the
   two nodes is a not a Participating Node

   Participating Node - An IGP speaker that has advertised the
   capability, and hence the intention, to participate in a flooding
   topology



Allan et al.,             Expires April 2019                   [Page 3]


Internet-Draft    draft-allan-lsr-flooding-algorithm       October 2018


3. Solution Overview

3.1. The Flooding Topology

   A flooding topology is composed of a contiguously connected set of
   participating nodes.

   The flooding topology constructed from two diversely rooted spanning
   trees. A participating node that is connected to the physical
   topology with a degree of two or greater and has at least two
   participating adjacencies will be bi-connected to the flooding
   topology.

   The resulting flooding topology diameter will typically be two times
   the depth of the tree hierarchy. The compromise in this approach is
   that a subset of nodes in the network will not see a reduction of the
   replication burden from current practice when flooding LSAs as the
   degree of a subset of nodes in the flooding topology will correspond
   to the degree of the physical topology.

   The protocol structure of flooded information is unmodified. A
   participant node may relay a received LSA onto member links of both
   spanning trees. Specific forwarding rules prevent undue flooding, the
   result being that every participant node that is bi-connected to the
   flooding topology will receive two copies of any flooded LSA in a
   fault free network. Participating nodes that due to network
   degradation are only singly connected will receive one copy. The
   forwarding rules are described in section 4.4.

3.2. Solution Applicability

   This algorithm has been considered in the context of pure bipartite
   graphs, bipartite graphs modified with the addition of intra-tier
   adjacencies, and hierarchical variations of the above. Applicability
   to other network designs is for further study.

   For all graphs the link costs are assumed to be common for all inter-
   tier links and common for any intra-tier links. Inter-tier and intra-
   tier links do not have to have the same cost.

3.3. Algorithm

   The algorithm borrows from 802.1aq for the construction of the
   spanning trees used in this application. This is described in clause
   28.5 of [802.1Q].




Allan et al.,             Expires April 2019                   [Page 4]


Internet-Draft    draft-allan-lsr-flooding-algorithm       October 2018


3.3.1. Algorithm Basics

   The key component of the 802.1aq employed is the tie breaking
   algorithm. The original application of the algorithm was to produce a
   symmetrically congruent mesh of multicast trees and unicast
   forwarding whereby the path between any two nodes in the network was
   symmetric in both directions and congruent for both unicast and
   multicast traffic.

   For this application the algorithm is used in the generation of two
   diversely rooted spanning trees that define the flooding topology.

   As part of tree construction, the algorithm tie breaks between equal
   cost paths. When a tie is identified as part of a Dijkstra
   computation, a path-id is constructed for each equal cost path. A
   path-id is expressed as a lexicographically sorted list of the node-
   ids in the path. The set of equal cost paths is ranked, and the
   lowest selected. As an example:

         Path-id 23-39-44-68-85 is ranked lower than

         Path-id 23-44-59-63-90

   When the path-ids are of unequal length, the path-ids with the fewest
   hops are ranked superior to the longer paths, and tie breaking is
   applied to select between the shorter path-ids. This is not expected
   to apply in the general case of the dense graphs this application is
   targeted at.

   The node-ids used would be the loopback address of each node,
   therefore each path-id will be unique.

3.3.2. Generating Diverse Trees

   The algorithm includes the concept of an "algorithm-mask", which is a
   value XOR'd with the node-ids prior to sorting into path IDs and
   ranking the paths. This permits the construction of diverse trees in
   a dense topology.

   Two algorithm masks are used (zero and -1). When computing two trees
   from the same root, when there are at least two nodes to choose from
   at each distance from the root, fully diverse trees will be
   generated. When computing two trees from diverse roots in a tree
   architecture, diverse nodes will be selected in each tier in the
   hierarchy as the relay nodes to the next tier.




Allan et al.,             Expires April 2019                   [Page 5]


Internet-Draft    draft-allan-lsr-flooding-algorithm       October 2018


3.3.3. Desirable Properties Computation Wise

   The algorithm has the property of permitting the pruning of
   intermediate state as a Dijkstra progresses as ties can be
   immediately evaluated, and the all but the selected path removed from
   further consideration. This is desirable when computing a Dijkstra in
   a dense graph as all path permutations do not need to be carried
   forward during computation. This permits the computation to be quite
   fast.

   The resulting computational complexity would still be expressed as
   2N(lnN).

4. Applying the Algorithm

4.1. Tree Generation

   Each IGP speaker in the network has knowledge of each of the two
   spanning tree roots and the algorithm mask associated with each. This
   memo does not specify how root selection is performed and
   disseminated through the network, but does discuss selection
   requirements in section 4.5.

   Each root has one of the two algorithm masks associated with it.

   Each participating IGP speaker in the network computes a spanning
   tree from each the two roots (using the algorithm mask associated
   with each root) and from that can determine its own role in the
   flooding topology. The two spanning trees are designated the "low
   spanning tree" and the "high spanning tree".

   The spanning trees are a starting point for a redundant topology.
   Unlike the commonly accepted operation of a spanning tree, in this
   application the distinction between upstream and downstream
   adjacencies is important and is an input to how a member node further
   relays any LSAs received. Upstream member adjacencies are in the
   direction of a root, and downstream member adjacencies are in the
   direction away from the root.

4.2. Illustrating the result

   The following diagram illustrates the general layout of the flooding
   graph constructed using the algorithm as applied to a bi-partite
   style of tree (no intra tier links):





Allan et al.,             Expires April 2019                   [Page 6]


Internet-Draft    draft-allan-lsr-flooding-algorithm       October 2018


                                  Spine
                  +---+ +---+ +---+ +---+        +---+
                  | a | | b | | c | | d | o o o  | z |
                  +---+ +---+ +---+ +---+        +---+
                   /|\                            /|\
    \|/                                                             \|/
   +---+ +---+ +---+       +---+           +---+ +---+ +---+       +---+
   | i | |ii | |iii| o o o | x |           | 1 | | 2 | | 3 | o o o | n |
   +---+ +---+ +---+       +---+           +---+ +---+ +---+       +---+
    /|\                     /|\             /|\                     /|\


   In the example, there are two tiers of switches. The spine (nodes
   a..z), and the next tier with two groups of nodes (i..x) and (1..n).
   The algorithm will select the node with the lowest node ID in each
   tier as the replicating node for the low spanning tree; 'a' and 'i'
   for the set of nodes connecting the spine and the next tier. The
   algorithm will select the nodes with highest node ID in the same set
   of nodes for the high spanning tree; 'z' and 'n' for the same set of
   nodes.

   In the flooding topology:

   - Node 'a' is connected to nodes i..x and 1..n for the low spanning
      tree.

   - Node 'z' is connected to the same set of nodes for the high
      spanning tree.

   - Node 'i' is connected to nodes 'a'..'z' for the low spanning tree,
      and

   - Node 'n' is connected to the same nodes for the high spanning
      tree.

   - All other nodes are bi-connected to the flooding topology

   If there was a further tier added below nodes i..x, then 'i' and 'x'
   would be selected as the replicating nodes for the low and high
   spanning tree respectively. This is similarly true for nodes 1..n.



4.3. Interactions between Participating and Non-Participating Nodes

   This solution proposes primarily only nodal behaviors with respect to
   constraining flooding to member adjacencies. To address the scenario


Allan et al.,             Expires April 2019                   [Page 7]


Internet-Draft    draft-allan-lsr-flooding-algorithm       October 2018


   where the participating nodes were a subset of a larger network, it
   would be necessary to advertise the capability to participate in
   flood reduction.

   This would then require that each participating node use this
   information to be able to identify the set of participating
   adjacencies and confine the spanning tree computation to the set of
   participating adjacencies in order to identify local set of member
   adjacencies. Interactions with non-participant adjacencies would
   conform to current practice.

4.4. Flooding of LSAs

   The design of the protocol elements that are flooded is unmodified by
   this solution. Therefore, there is no additional information
   available to associate a received LSA with a given tree, nor is such
   information needed; the two spanning trees are not treated as unique
   entities in the flooding topology.

   As per current practice, a node does not relay LSAs that it has
   already seen.

   A new LSA received from an upstream member adjacency is flooded on:

      - All downstream member adjacencies exclusive of the adjacency of
      arrival, irrespective of which tree the adjacencies are part of.

      - All non-participant adjacencies

   A new LSA received from a downstream member adjacency is flooded on:

      -  All other member adjacencies exclusive of the adjacency of
        arrival irrespective of which tree the adjacencies are part of.

      -  All non-participant adjacencies

   A new LSA received from a member adjacency where upstream and
   downstream is ambiguous (it is an upstream member on one of the
   spanning trees and a downstream member on the other), is flooded on:

      - All other member adjacencies exclusive of the adjacency of
      arrival irrespective of which adjacency the links are part of.

      - All Non-Participant adjacencies





Allan et al.,             Expires April 2019                   [Page 8]


Internet-Draft    draft-allan-lsr-flooding-algorithm       October 2018


   A new LSA received from a non-member adjacency is flooded on all
   member adjacency irrespective of which tree the adjacencies are part
   of (see sections 5.1 and 5.5).

4.5. Root Selection

   The algorithm depends on tie breaking between sets of node IDs to
   produce diverse paths, therefore it does place some restrictions on
   root selection.

   A root SHOULD be selected so that the root"s node-id when XORd with
   the associated algorithm mask is the lowest ranked node in the local
   tier in the tree hierarchy. This would be analogous to path-id
   ranking where the paths were all of length 1.

   The root MUST NOT be selected such that the node-ID when XORd with
   the other root"s algorithm mask is the lowest ranked node. This would
   result in the root also being a transit node for the other spanning
   tree and produce a scenario whereby a single failure could render
   both spanning trees incomplete.

   Roots MUST NOT be directly connected for either of the low or high
   spanning trees. If the topology does not permit this to be satisfied
   purely by root selection, then the inter-root adjacency must be
   pruned from the graph prior to spanning tree computation to ensure
   that diverse paths between the roots are used.

   For a true bipartite graph, there are no other restrictions on node
   selection.

   For a bipartite graph modified with inter-tier links, the roots MUST
   be placed in different tiers to ensure a pathological combination of
   link weights and node-ids does not result in a scenario where a
   single failure would render the flooding topology incomplete.

   Other sources of failure may exist that may require an administrative
   component to root selection. This, for example, would ensure that
   both roots were not selected from a common shared risk group.

   See also section 5.5.

4.6. Node Additions

   A participating node that is added to the topology will initially not
   be served by the flooding topology. A participating node adjacent to
   that node is required to treat it as a non-participating node until
   such time as tree re-optimization has completed. At the end of tree


Allan et al.,             Expires April 2019                   [Page 9]


Internet-Draft    draft-allan-lsr-flooding-algorithm       October 2018


   optimization, typically two adjacent participating nodes will have
   member adjacencies with the new node, so the ability to flood LSAs
   between the new node and the flooding topology will have been
   uninterrupted during the process.

5. Further work

5.1. Thoughts on Coexistence in the Context of a Larger Network

   A node that had a combination of participating and non-participating
   adjacencies would be required to do the following:

   -  For any new LSA received on a participating adjacency, in addition
     to the rules for member adjacencies, it would also flood the LSA
     on all non-participating adjacencies.

   -  For any new LSA received on a non-participating adjacency, it
     would flood the LSA on all member adjacencies.

   This is reflected in the forwarding rules described in section 4.4.

5.1.1. Multiple flooding Domains and the Severing of Flooding Domains

   It is possible to envision several scenarios whereby there are sets
   of participating nodes that are not contiguously connected via
   participating adjacencies in a given IGP domain.

     1. A node has been incorrectly configured as a participating node
        but has no participating adjacencies.

     2. A participating node or set of nodes has become severed from
        the flooding topology but is still connected to other nodes in
        the network. Nodes in this set would still be able to compute a
        local extension of the flooding topology, but it would only be
        useful if the set was sufficiently large that a majority of the
        nodes were not connected to non-participants.

     3. Procedures are designed to permit more than one flooding
        topology in an IGP domain. In which case participating nodes
        would have to be administratively configured to associate with a
        flooding topology instance.

5.2. Thoughts on Flooding Topology Re-Optimization

   After a topology change, it is desirable that the flooding topology
   remain stable until the network has stabilized. However a single
   failure may render one of the spanning trees incomplete, such that a


Allan et al.,             Expires April 2019                  [Page 10]


Internet-Draft    draft-allan-lsr-flooding-algorithm       October 2018


   further single failure could make the flooding topology incomplete.
   Therefore procedures should include re-optimization of the flooding
   topology after a topology change. In order to maintain complete
   coverage it would make sense not to recompute the spanning trees
   simultaneously.

   One approach that would appear to make sense to separate in time
   network convergence, re-optimization of the low spanning tree and re-
   optimization of the high spanning tree.

   The ideal would be to reoptimize an incomplete tree first, however
   this would require the participating nodes to maintain a complete map
   of all member adjacencies so that a common determination of the most
   degraded spanning tree and hence the order of re-optimization could
   be made.

5.3. Thoughts on Node and Network Initialization

   A participating node at power up will be not be able to establish
   member links until it has synchronized with the network and the
   network is stable in the new topology. This suggests it simply treats
   power up similarly to how a topology change and network re-
   optimization is treated. The only difference being that it will flood
   all LSAs received or originated as per current practice until both
   spanning trees have stabilized.

5.4. Thoughts on Loop Prevention

   802.1aq included additional mechanisms to prevent looping, a reverse
   path forwarding check, and digest exchange across adjacencies to
   ensure IGP synchronization.

   Routing LSAs are not relayed if they are a duplicate, therefore
   destructive looping cannot occur and additional mitigation mechanisms
   are not required.

5.5. Thoughts on Pathological Failure Scenarios

   While in a stable fault free network with sufficient mesh density of
   the types considered, the flooding topology used by this solution
   would ensure that no single failure rendered both spanning trees
   incomplete, it is also useful to consider multiple failure scenarios
   and if they can be mitigated.

   Preliminary analysis suggests that in a tree network of sufficient
   mesh density, the only dual link failure that can render the flooding
   topology incomplete is if a participant node has failures in both


Allan et al.,             Expires April 2019                  [Page 11]


Internet-Draft    draft-allan-lsr-flooding-algorithm       October 2018


   upstream member adjacencies. This can be partially mitigated if the
   node recognizes this scenario and reverts to flooding on all
   adjacencies. If the suggested procedures of 5.1.1 above are adopted,
   surrounding participating nodes that receive the LSA on a non-member
   adjacency will introduce the LSA into the flooding topology.

   The pathological scenario is the simultaneous failure of both roots.
   This does suggest that root selection should place the roots two hops
   apart so there will be a constituency of participants that would
   observe a simultaneous failure of both upstream member adjacencies
   and revert to normal flooding.

6. Acknowledgements

   The author would like to acknowledge Jerome Chiabaut for his original
   algorithm work that underpins this memo.

7. Security Considerations

   For a future version of this document.

8. IANA Considerations

   This memo requires no IANA allocations

9. References

9.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
          Requirement Levels", BCP 14, RFC 2119, March 1997.

9.2. Informative References

[802.1Q] 802.1Q (2014) IEEE Standard for Local and Metropolitan
           Area Networks--Media Access Control (MAC) Bridges and
           Virtual Bridged Local Area Networks

[Li]  Li, T., Psenak, P., "Dynamic Flooding on Dense Graphs", IETF work
        in progress, draft-li-dynamic-flooding-05, June 2018









Allan et al.,             Expires April 2019                  [Page 12]


Internet-Draft    draft-allan-lsr-flooding-algorithm       October 2018


10. Author's Address

   Dave Allan
   Ericsson
   2455 Augustine Drive
   Santa Clara, CA  95054
   USA
   Email: david.i.allan@ericsson.com









































Allan et al.,             Expires April 2019                  [Page 13]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/