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

From: Chris Bowers <[email-masked]>
Date: Thu, 11 Dec 2014 02:38:39 +0000

Mach,

Thanks for the comments.  Please see inline below [CB].

-----Original Message-----
From: Mach Chen [mailto:[email-masked]] 
Sent: Tuesday, November 18, 2014 3:30 AM
To: [email-masked]
Cc: [email-masked]; 'Martin Vigoureux'; [email-masked]
Subject: MPLS-RT review of draft-atlas-mpls-ldp-mrt

Hi Authors,

I am assigned as a MPLS-RT reviewer of draft-atlas-mpls-ldp-mrt. 

The draft is well written and ready for a call adoption. I have two comments as below:

1.

It's better to expand the acronyms (e.g., MRT, LDP, etc.) in the first usage.

[CB] Agreed. Will add to next revision.

2. 

"4.1.  MRT Capability Advertisement
It is not possible to support MRT without supporting the LDP multi-
   topology extensions, but it is possible that the only use of the
   multi-topology extensions is for MRT.  In that case, a router MAY not
   negotiate the multi-topology capability and only negotiate the MRT
   Capability with its LDP peers.  Negotiation of the multi-topology
   capability is not required with negotiation of the MRT capability."

Personally, I'd like that the MRT capability does not coupled with MT capability. This may bring extra logic/complex to the implementation. Suppose that an LSR advertises the MRT capability to its neighbors and then withdraw it later, then the receiver LSRs have to determine whether withdraw the MT capability as well. More seriously, for the MT capability negotiation process, since it does not know whether there is MRT, so when an LSR receives an MT withdraw, how it handles its MT capability? 

[CB]  Based on your feedback, we propose to require MT capability to be explicitly negotiated whenever MRT capability is negotiated.  New proposed text deletes the paragraph above, and adds the following text.   Are you OK with this approach?

------------------
4.1.1.  Interaction of MRT Capability and MT Capability
 
   An LSR advertising the LDP MRT Capability MUST also advertise the LDP
   Multi-topology (MT) capability.  If an LSR negotiates LDP MRT
   Capability with an LDP neighbor without also negotiating the LDP MT
   Capability, the LSR MUST behave as if LDP MRT Capability has not been
   negotiated and respond with the "MRT Capability negotiated without MT
   Capability" status code in the LDP Notification message (defined in
   this document).  The E-bit of this Notification should be set to 0 to
   indicate that this is an Advisory Notification.  The LDP session
   SHOULD NOT be terminated.
 
.........
 
7.  IANA Considerations
......
   IANA is requested to allocate a value for the new LDP Status Code
   (the first free value in the range 0x00000032-0x00000036) from the
   LDP registry "Status Code Name Space": "MRT Capability negotiated
   without MT Capability" (TBA-MRT-LDP-3).
 
Value          E  Description                Reference   Notes / Reg. Date
-------------  -  -------------------------  ---------   -----------------
TBA-MRT-LDP-3  0  MRT Capability negotiated  [This draft]
                  without MT Capability

---------

Best regards,
Mach

---

From: Mach Chen <[email-masked]>
Date: Fri, 12 Dec 2014 02:26:36 +0000

Hi Chris,

Thanks for considering my comments, I am OK with your proposal.

Best regards,
Mach

> From: Chris Bowers [mailto:[email-masked]]
> Sent: Thursday, December 11, 2014 10:39 AM
> To: Mach Chen; [email-masked]
> Subject: RE: MPLS-RT review of draft-atlas-mpls-ldp-mrt
> 
> Mach,
> 
> Personally, I'd like that the MRT capability does not coupled with MT capability.
> This may bring extra logic/complex to the implementation. Suppose that an LSR
> advertises the MRT capability to its neighbors and then withdraw it later, then the
> receiver LSRs have to determine whether withdraw the MT capability as well.
> More seriously, for the MT capability negotiation process, since it does not know
> whether there is MRT, so when an LSR receives an MT withdraw, how it handles
> its MT capability?
> 
> [CB]  Based on your feedback, we propose to require MT capability to be
> explicitly negotiated whenever MRT capability is negotiated.  New proposed
> text deletes the paragraph above, and adds the following text.   Are you OK
> with this approach?
> 
> ------------------