Re: [Gen-art] Review: draft-ietf-mpls-ldp-p2mp-14

[IJsbrand Wijnands]

Hi Joel,

Thanks for the comments.

 Major issues:
As I read the document, status codes (and stauts TLVs) are for reporting 
 on the status of LSPs.  They are not for negotiating behaviors.  Thus, I find 
 it very strange that make-before-break behavior (section 8) is requested (by 
 a downstream device sending a request to an upstream device) by including a 
 specific status code in the request. Has this technique been used in MPLS LDP 
 before?

Well, the status codes and TLVs are not restricted by RFC 5036 for any 
particular purpose. The MBB procedures requires to signal information about the 
LSP which is not part of the FEC. The status TLV seems a good way to do that. 
Also, the status of the LSP can be viewed as 'waiting on upstream LDP neighbor 
to respond for MBB purpose'. So I think its ok.

 
 Minor issues:
The definition (section 1.2)  of MP2MP LSPs should indicate that even 
 though all nodes are allowed to send on the LSP, there is still a 
 distinguished root node.

Ok, I will add that.

 
The LDP MP Opaque Value Element extended type (section 2.3, second 
 definition) seems to be gratuitous complexity, adding extra matching cases in 
 the LDP processing path for no stated value.  Is there really believed to be 
 a need for more than 254 types of Opaque values?  If so, explain it in the 
 document.

The opaque type was defined as a non-extensible one-octet field. This may be 
enough for the future, but you never know. I guess there are many examples in 
the IETF where fields seemed to be large enough but proved to be too small over 
time. So why not just document it now.

 
Section 3.3.1.3 begins by describing two methods for installing the 
 upstream path of a MP2MPLSP.  After carefully describing both, it says to 
 only and always use the second method.  Would it not be better to describe 
 the constraint (that the upstream path must be in place all the way to the 
 root before it claims to be established), and then describe the one method 
 that meets taht.  Just don't describe a method that is not to be used.

That is a good comment, let me think about this for a bit.

Thx,

Ice.


 
 Nits/editorial comments:
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

[Gen-art] Review: draft-ietf-mpls-ldp-p2mp-14

[Joel M. Halpern]

I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ at 
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.


Please resolve these comments along with any other Last Call comments 
you may receive.


Document: draft-ietf-mpls-ldp-p2mp-14
   Label Distribution Protocol Extensions for Point-to-Multipoint and
 Multipoint-to-Multipoint Label Switched Paths
Reviewer: Joel M. Halpern
Review Date: 23-June-2011
IETF LC End Date: 4-July-2011
IESG Telechat date: N/A

Summary:  This document is close to ready for publication as a Proposed 
Standard RFC  Certain questions should be answered, and some minor 
issues considered.


Major issues:
As I read the document, status codes (and stauts TLVs) are for 
reporting on the status of LSPs.  They are not for negotiating 
behaviors.  Thus, I find it very strange that make-before-break behavior 
(section 8) is requested (by a downstream device sending a request to an 
upstream device) by including a specific status code in the request. 
Has this technique been used in MPLS LDP before?


Minor issues:
The definition (section 1.2)  of MP2MP LSPs should indicate that 
even though all nodes are allowed to send on the LSP, there is still a 
distinguished root node.


The LDP MP Opaque Value Element extended type (section 2.3, second 
definition) seems to be gratuitous complexity, adding extra matching 
cases in the LDP processing path for no stated value.  Is there really 
believed to be a need for more than 254 types of Opaque values?  If so, 
explain it in the document.


Section 3.3.1.3 begins by describing two methods for installing the 
upstream path of a MP2MPLSP.  After carefully describing both, it says 
to only and always use the second method.  Would it not be better to 
describe the constraint (that the upstream path must be in place all the 
way to the root before it claims to be established), and then describe 
the one method that meets taht.  Just don't describe a method that is 
not to be used.


Nits/editorial comments:
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf