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

From: Chris Bowers <[email-masked]>
Date: Mon, 8 Dec 2014 15:46:56 +0000

Stewart,

Thanks for the feedback on the text.  Please see responses inline

From: mpls [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Monday, November 03, 2014 9:06 AM
To: [email-masked]; [email-masked]; 'Martin Vigoureux'
Cc: [email-masked]
Subject: [mpls] MPLS RT review of draft-atlas-mpls-ldp-mrt

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?

[CB]  agreed.

   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.

[CB] Good point.  I will see if anyone else has strong opinions on keeping this section.

 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

[CB]  Agreed.  If we decide to keep the terminology section in this draft, then I will add GADAG as well.

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.

[CB]  Agreed.  I have reworded the intro and the list items to read better, to be included in the next update.

   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/

[CB]  Agreed.

       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.

[CB]  The issue that this sentence intends to address is the following.  Suppose that someone wants to run a network with IPv4 and IPv6 with LDP for both IPv4 and IPv6, but only wants to run MRT for the IPv4 FECs (for some unspecified reason).  The LDP MRT Capability Advertisement defined in this document does not distinguish between IPv4 and IPv6, so this scenario is not supported.  We considered  adding a mechanism to distinguish between IPv4 and IPv6 MRT LDP Capability, but decided that supporting the scenario above was not  worth the added complexity.  If the WG has a different opinion, we can revisit this.  Do this make sense, or would you suggest additional text to clarify?

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 08 Dec 2014 16:57:23 +0000

> [CB]  The issue that this sentence intends to address is the following.  Suppose that someone wants to run a network with IPv4 and IPv6 with LDP for both IPv4 and IPv6, but only wants to run MRT fo…
Hi Chris

I think that needs re-wording since we have to be able to cope with
IPv4 only, IPv4+IPv6 and in the future IPv6 only. As you have written
the text it's not clear to me that we support that.

- Stewart

---

From: Chris Bowers <[email-masked]>
Date: Mon, 8 Dec 2014 17:38:19 +0000

Stewart,

Thanks.  I've added the following text to clarify.  Tell me if this works.

Chris

   The MRT LDP Capability Advertisement does not distinguish between
   IPv4 and IPv6 address families.  An LSR which advertises the MRT LDP
   capability is expected to advertise MRT-related FEC-label bindings
   for the same address families for which it advertises shortest-path
   FEC-label bindings.  Therefore, an LSR advertising MRT LDP capability
   and shortest path FEC-label bindings for IPv4 only (or IPv6 only)
   would be expected to advertise MRT-related FEC-label binding for IPv4
   only (or IPv6 only).  An LSR advertising the MRT LDP capability and
   shortest-path FEC label bindings for BOTH IPv4 and IPv6 is expected
   to advertise MRT-related FEC-label bindings for BOTH IPv4 and IPv6.
   In this scenario, advertising MRT-related FEC-label bindings only for
   IPv4 only (or only for IPv6) is not supported.

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Monday, December 08, 2014 10:57 AM
To: Chris Bowers; [email-masked]; [email-masked]; 'Martin Vigoureux'
Cc: [email-masked]
Subject: Re: [mpls] MPLS RT review of draft-atlas-mpls-ldp-mrt

On 08/12/2014 15:46, Chris Bowers wrote:
> SB> Surely the rule is that the you advertise bindings for the set of 
> SB> address families you support. That makes you IPv4 and/or
Hi Chris

I think that needs re-wording since we have to be able to cope with
IPv4 only, IPv4+IPv6 and in the future IPv6 only. As you have written the text it's not clear to me that we support that.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 09 Dec 2014 15:31:21 +0000

Chris

That looks good.

Thanks

Stewart

On 08/12/2014 17:38, Chris Bowers wrote:
> .

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html