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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf