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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf