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

From: Kishore Tiruveedhula <[email-masked]>
Date: Fri, 12 Dec 2014 16:10:10 +0000

Hi Greg,
    Regarding the first comment, I think this may create confusion as the RFC 5561 tells that any data added after “Reserved” considered as the “Capability Data”.   So, I think the padding 3 bytes is not needed. Even if you see the other LDP capabilities, for example P2MP, MP2MP and MBB defined in the RFC 6388 (https://wiki.tools.ietf.org/html/rfc6388#page-6 ) follows the same thing without padding.  Please let me know if you are okay without adding padding in the MRT capability also.

Section 3 RFC 5561:
https://wiki.tools.ietf.org/html/rfc5561#page-4 :

   The format of a "Capability Parameter" TLV is as follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |U|F| TLV Code Point            |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S| Reserved    |                                               |
      +-+-+-+-+-+-+-+-+       Capability Data                         |
      |                                               +-+-+-+-+-+-+-+-+
      |                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Thanks,
Kishore

From: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Thursday, December 11, 2014 at 7:38 PM
To: Chris Bowers <[email-masked]<mailto:[email-masked]>>, Loa Andersson <[email-masked]<mailto:[email-masked]>>, Mach Chen <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] MPLS-RT review of draft-atlas-mpls-ldp-mrt-02.txt

Hi Chris, I apologies for belated response to your thorough consideration of my comments. Please find my notes in-lined and tagged GIM>>.

I’m fine with the explanations and recommend the draft to be considered for WG adoption.

                Regards,
                                Greg

From: Chris Bowers [mailto:[email-masked]]
Sent: Friday, December 12, 2014 5:19 AM
To: Gregory Mirsky
Subject: FW: MPLS-RT review of draft-atlas-mpls-ldp-mrt-02.txt

Greg,

Are you good with these responses?

Chris

From: Chris Bowers
Sent: Monday, December 08, 2014 9:47 AM
To: 'Gregory Mirsky'; Loa Andersson; Mach Chen; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: MPLS-RT review of draft-atlas-mpls-ldp-mrt-02.txt

Greg,

Thanks for the review.  Please see responses inline.

From: mpls [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: Tuesday, November 18, 2014 3:31 PM
To: Loa Andersson; Mach Chen; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] MPLS-RT review of draft-atlas-mpls-ldp-mrt-02.txt

Dear Authors, MPLS WG chairs, et. al,
I've been asked to review the draft-atlas-mpls-ldp-mrt-02.txt.

The document is very well written, technically sound and clearly addresses integral part of MRT-FRR solution.
It is ready for the WG adoption in my opinion.

Below are my comments to authors that are should not be viewed as gating the adoption:
·         section 4.1, I'd consider padding the MRT Capability TLV with extra 3 octets and changing the Length field accordingly to 4;
[CB]  I’m not sure that I understand your suggestion here.  The MRT Capability TLV we are defining is an LDP Capability Parameter TLV (as defined in section 3 of RFC 5561).  It carries no Capability Data.  So its length is 1 to account for the S-bit and 7 reserved bits.  Are you suggesting that we add 3 bytes of empty Capability Data and set the length to 4?  Or did you have something else in mind?
GIM>> Yes, the 3 bytes of additional padding to make Length 4.
·         section 4.3, a bit strange that IANA request to allocate MT-IDs for MRT-Red and MRT-Blue is in ietf-rtgwg-mrt-frr-architecture and not in this document as for Rainbow-MRT’s MT-ID (section 4.2). Perhaps by grouping all in one request would make it logistically easier and minimize inter-dependency of the MRT-FRR documents.
[CB]  The reasoning behind the current placement of the IANA requests is the following. (Note that we’ll be changing “LDP Multi-Topology (MT) ID Name Space” to  “MPLS Multi-Topology Identifiers” in the IANA section of ietf-rtgwg-mrt-frr-architecture to match the change in naming of the IANA registry that occurred as drafts leading to RFC7307 were revised.)
The MPLS Multi-Topology Identifiers registry requests in ietf-rtgwg-mrt-frr-architecture are for MPLS MT-IDs  for MRT-Red and Blue for the Default Profile.  The Default Profile specifies for example using the lowpoint algorithm to compute the GADAG.  This Default Profile has MRT profile value=0.   It is possible that a future document could specify another MRT profile with a different algorithm for computing the GADAG which we could call MRT Profile1 with MRT profile value =1.  This new document would also need to include an IANA request to allocate values for MPLS MT-IDs for MRT-Red and Blue for MRT Profile 1.
The MPLS Multi-Topology Identifiers registry request in draft-atlas-mpls-ldp-mrt is for the Rainbow MRT MPLS MT-ID.  This MPLS  MT-ID provides a way to identify the Rainbow MRT FEC, which provides an optimization specific to LDP forwarding on MRTs at ABRs.  The Rainbow FEC forwarding behavior is independent of the MRT Profile, so if different MRT Profiles are defined in the future, a new Rainbow MRT MPLS MT-ID will not need to be defined.   So the idea is that the IANA requests in ietf-rtgwg-mrt-frr-architecture are specific to the Default MRT Profile.  In the supporting documents like draft-atlas-mpls-ldp-mrt as well as draft-li-isis-mrt and draft-atlas-ospf-mrt the IANA requests are for values that are independent of a specific MRT profile.

GIM>> Thank you for the utmost detailed explanation, I think I understand it better now. Had or would these relationships between objects of IANA registries, that you’ve described, be captured in any of MRT documents? I think that it is clearly should not delay this document adoption by the WG but thorough explanation in IANA Considerations section, even if it repeats content of identical sections in other documents related to MRT, would be helpful.

Thank you for your kind consideration.

        Regards,
                Greg

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]]
Sent: Tuesday, October 28, 2014 4:26 AM
To: Mach Chen; [email-masked]<mailto:[email-masked]>; Gregory Mirsky
Cc: [email-masked]<mailto:[email-masked]>; VIGOUREUX, MARTIN (MARTIN); [email-masked]<mailto:[email-masked]>
Subject: MPLS-RT review of draft-atlas-mpls-ldp-mrt-02.txt

Mach, Stewart and Greg,

You have be selected as MPLS-RT reviewers for  draft-atlas-mpls-ldp-mrt.

Note to authors: You have been CC'd on this email so that you can know that this review is going on. However, please do not review your own document.

Reviews should comment on whether the document is coherent, is it useful (ie, is it likely to be actually useful in operational networks), and is the document technically sound?  We are interested in knowing whether the document is ready to be considered for WG adoption (ie, it doesn't have to be perfect at this point, but should be a good start).

Reviews should be sent to the document authors, WG co-chairs and WG secretary, and CC'd to the MPLS WG email list. If necessary, comments may be sent privately to only the WG chairs.

If you have technical comments you should try to be explicit about what
*really* need to be resolved before adopting it as a working group document, and what can wait until the document is a working group document and the working group has the revision control.

Are you able to review this draft by Nov 18, 2014? Please respond in a timely fashion.

Thanks, Loa
(as MPLS WG chair)

-------- Original Message --------
Subject: [mpls] I-D Action: draft-atlas-mpls-ldp-mrt-02.txt
Date: Mon, 27 Oct 2014 09:09:38 -0700
From: [email-masked]<mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]>
CC: [email-masked]<mailto:[email-masked]>

A New Internet-Draft is available from the on-line Internet-Drafts directories.
  This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

         Title           : LDP Extensions to Support Maximally Redundant
Trees
         Authors         : Alia Atlas
                           Kishore Tiruveedhula
                           Chris Bowers
                           Jeff Tantsura
                           IJsbrand Wijnands
        Filename        : draft-atlas-mpls-ldp-mrt-02.txt
        Pages           : 16
        Date            : 2014-10-27

Abstract:
    This document specifies extensions to LDP to support the creation of
    label-switched paths for Maximally Redundant Trees (MRT).  A prime
    use of MRTs is for unicast and multicast IP/LDP Fast-Reroute, which
    we will refer to as MRT-FRR.

    The sole protocol extension to LDP is simply the ability to advertise
    an MRT Capability.  This document describes that extension and the
    associated behavior expected for LSRs and LERs advertising the MRT
    Capability.

    MRT-FRR uses LDP multi-topology extensions and requires three
    different multi-topology IDs to be allocated from the LDP MT-ID
    space.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-atlas-mpls-ldp-mrt/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-atlas-mpls-ldp-mrt-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-atlas-mpls-ldp-mrt-02

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls