Hi Patrice,
Please find attached the draft updated, please let me know if this address your
comments.
Thanks,
Sami
On 5/18/17, 12:44 PM, "Patrice Brissette (pbrisset)"
<pbrisset(_at_)cisco(_dot_)com> wrote:
Thank Sami
Regards,
Patrice Brissette
On 2017-05-18, 12:25 PM, "Sami Boutros" <sboutros(_at_)vmware(_dot_)com> wrote:
Hi Patrice,
Please see comments inline.
> >
> >Here are my “detailed” comments:
> >
> >Abstract — What is the plus value on that draft? No clear
> >
> >Many Long sentences in the text. very hard to understand and follow.
> >Syntax to be improved.
>
><Patrice> This comment is regarding the draft in general. It doesn’t flow
well. You need to read it more than once to see the overall picture. It might
just be to reshuffle some sections.
>
Sure will look into that.
>
> I went over the abstract, I didn’t see any long sentences. Not sure
> What to improve? Can you be specific?
>
>
> >
> >Introduction
> >Typo : “A reference model or a P2MP PW is depicted in Figure 1 below”
> >
> >“In this document, we specify a method of signaling P2MP
> > PW using LDP.” —> suggest to move it from intro to abstract
>
> Not sure if we can reference a figure in the abstract. The abstract
> Already mention that the second sentence.
>
><Patrice> This is NOT a figure but rather the explanation. That line
makes the document very clear. It just need to be spelled out. “specify a
method of signaling P2MP PW using LDP”.
This is exactly what we have in the abstract first sentence “This document
specifies a mechanism to signal Point-to-Multipoint
(P2MP) Pseudowires (PW) tree using LDP.”
>
> >
> >
> >Also, make sure the 3rd person is used. Try to a void “we” usage
>
> Agreed, I will remove all usage of “we” in the document.
>
> >
> >May I suggest to have a requirement section. Requirements are all
over
> >the document.
>
> There is already an RFC for that. [RFC7338] F. Jounay, et. al,
> "Requirements for Point to Multipoint Pseudowire", RFC7338, September
2014.
>
> This solution document addresses the requirements.
>
><Patrice> Your document enhances that based RFC by providing more “MUST”,
“SHOULD”, etc.
>They are all over the doc. To make it clear, grouping them in a section
may help. Another idea is to have Requirement sub-sections per topic.
It seems that this is the same as your document flow comment above, I will
look into that.
>
>
> >
> >“ In case of mLDP, a Leaf-PE can decide to join the P2MP LSP at any
> > time; whereas in the case of RSVP-TE, the P2MP LSP is set up by
> >the
> > R-PE, generally at the initial service provisioning time. It
> >should
> > be noted that local policy can override any decision to join, add
> >or
> > prune existing or new L-PE(s) from the tree. In any case, the PW
> > setup can ignore these differences, and simply assume that the
> >P2MP
> > PSN LSP is available when needed
> >“
> >Quite complex to follow. Missing to “why” / explanation.
>
> Sure I can clarify this a little more, will remove some sentences
> That make it confusing, we are simply here differentiating mLDP LSP
from
> p2mp LSP w/ RSVP-TE and saying that PW setup is agnostic of the
transport
> p2mp LSP setup.
>
> >
> >“The LDP liberal label retention mode is used“
> >Another requirement… is that a MAY, SHOULD, MUST?
>
> I will change it to a MUST.
>
> >
> >“In this case, a PW status message with status
> > code of 0x00000008 (Local PSN-facing PW (ingress) Receive Fault)
> >MUST
> > also be sent to the R-PE“
> >
> >How? The L-PE fails to join the P2MP PSN LSP.
>
> Correct the L-PE have to signal this failure to the root PE.
>
><Patrice> question remains, how? If L-PE fails to join the LSP, PW will
be down. How can it signals the failure to root PE?
>
L-PE will use the PW status message, to signal to root PE this is what the
text is saying.
> >
> >Section 2.2
> >“ Note that since the LDP label mapping message is only sent by the
> >R-
> > PE to all the L-PEs, it is not possible to negotiate any interface
> > parameters.“
> >Why is that note there? Is that already been mentioned previously.
>
> This is the only reference in the document.
>
><Patrice> Forgot my thoughts on that one.
>
> >Fig.4 must be moved to proper in the text OR create 2 subsection in
> >2.2
>
> Sorry didn’t get what you mean here? Can you elaborate?
>
><Patrice> Sorry …Let me try again. “P2P PW Downstream FEC Element”. I
think you should have a section just on that topic. Actually, maybe you can
create a subsection for each different FEC explained in the document.
>
Ok, I will add subsections for Downstream and Upstream.
Thanks,
Sami
> >
> >“As such, PW status negotiation procedure
> > described in [RFC4447bis] is not applicable to P2MP PW. A node
> >MUST
> > NOT claim to be P2MP PW capable by sending a LDP P2MP PW
> >Capability
> > TLV if it is not also capable of handling PW status“
> >
> >Should a node send LDP P2MP PW Capability TLV or not? Not well
explain
>
> What is said here, that you can’t be P2MP PW capable without being PW
status capable.
> Not sure how to make it clearer.
>
><Patrice> right… I must have been tired. Too many NOT
>
> >
> >
> >There is some reference to LSR in the text where the major part use
> >the wording “node”.
>
> I will make all consistent, and use LSR instead of node.
>
> Thanks,
>
> Sami
> >
> >Nits:
> >N/A
> >
> >Regards,
> >Patrice Brissette
> >
> >
> >
> >
>
>
draft-ietf-pals-p2mp-pw-03.txt
Description: draft-ietf-pals-p2mp-pw-03.txt