Subject: [mpls] MPLS RT review of draft-atlas-mpls-ldp-mrt

From: Stewart Bryant <[email-masked]>
Date: Mon, 03 Nov 2014 15:06:03 +0000

This draft is a support draft for the work on MRT that is being
led in RTGWG.

I have concerns about whether or not MRT technology has the  maturity
expected in the standards track. However that decision needs to be
taken in RTGWG and MPLS needs to follow their and lead in determining
the fate and track of this draft. This draft should not be published
ahead of the drafts that define the technology that it is supporting.

That said, the draft is well written and I cannot see any
reason why it should not be put forward for adoption as
an MPLS WG draft.

I have some minor comments below which should be looked at when
the draft is next revised.

- Stewart

==========

           LDP Extensions to Support Maximally Redundant Trees
                       draft-atlas-mpls-ldp-mrt-02

1.  Introduction

    IP/LDP Fast-Reroute using MRTs can provide 100% coverage for link and
    node failures in an arbitrary network topology where the failure
    doesn't split the network.  It can also be deployed incrementally; an

SB> NIT isn't the more common term partition the network?

    MRT Island is formed of connected supporting routers and the MRTs are
    computed inside that island.

3.  Terminology

    For ease of reading, some of the terminology defined in
    [I-D.ietf-rtgwg-mrt-frr-architecture] is repeated here.

SB> Minor point - repeating definitions means you you need
SB> to track the definitions in multiple drafts in the design
SB> and publication phase. I appreciate the convenience, but
SB> you should think hard about whether to retain this.

  Redundant Trees (RT):   A pair of trees where the path from any node
       X to the root R along the first tree is node-disjoint with the
       path from the same node X to the root along the second tree.
       These can be computed in 2-connected graphs.

    Maximally Redundant Trees (MRT):   A pair of trees where the path
       from any node X to the root R along the first tree and the path
       from the same node X to the root along the second tree share the
       minimum number of nodes and the minimum number of links.  Each
       such shared node is a cut-vertex.  Any shared links are cut-links.
       Any RT is an MRT but many MRTs are not RTs.  The two MRTs are
       referred to as MRT-Blue and MRT-Red.

    MRT-Red:   MRT-Red is used to describe one of the two MRTs; it is
       used to described the associated forwarding topology and MT-ID.
       Specifically, MRT-Red is the decreasing MRT where links in the
       GADAG are taken in the direction from a higher topologically
       ordered node to a lower one.

SB> Minor point - you should expand and reference GADAG

4.  Overview of LDP Signaling Extensions for MRT

SB> Nit - there is an English problem between the into para below
SB> and the list that follows. It does not scan from the intro to
SB> each member of the list.

    Routers need to know which of their neighbors support MRT.
    Supporting MRT indicates several different aspects of behavior, as
    listed below.

    1.  Support for Multi-Topology (MT) - this MAY also be indicated via
        the Multi-Topology LDP Capability [RFC7307].

    2.  Understand the Rainbow MRT MT-ID and apply the associated labels
        to all relevant MT-IDs.

    3.  Advertise the Rainbow MRT MT-ID to the appropriate neighbors for
        the associated prefix.

    4.  If acting as LDP egress for a prefix in the default topology,
        also advertise and act as egress for the same prefix in MRT-Red
        and MRT-Blue.

    5.  For a FEC learned from a neighbor that does not support MRT,
        originate FECS for MRT-Red and MRT-Blue with the same prefix.
SB> Nit s/FECS/FECs/
        This MRT Island egress behavior is to support an MRT Island that
        does not include all routers in the area/level.

4.1.1.  Interaction of LDP MRT Capability with IPv4 and IPv6

    An LSR which advertises the MRT LDP capability is expected to
    advertise MRT-related FEC-label bindings for both IPv4 and IPv6
    address families, if the LSR originates shortest-path FEC-label
    bindings for those address families.

SB> Surely the rule is that the you advertise bindings for the
SB> set of address families you support. That makes you IPv4 and/or
SB> IPv6 and/or IPvn agnostic.