Signaling Root-Initiated Point-to-Multipoint Pseudowire using LDP
Summary: Has 2 DISCUSSes. Needs one more YES or NO OBJECTION position to pass.
Suresh Krishnan Discuss
* Section 7.3. mLDP Opaque Value Element TLV Type From my reading of RFC6388, the "Value" in the TLV type is interpreted based on the type and this document does not seem to specify what goes into the value. Additionally, the document requests the type "0x3" but it looks like that type has been allocated already to "Transit IPv4 Source TLV type" as per https://www.iana.org/assignments/ldp-namespaces/ldp-namespaces.xhtml#ldp-namespaces-11
* I think there is a typo in Figure 2. The "AII Type" field should be labeled "SAII Type" instead? * Why is the PW type referencing RFC4447 when the rest of the document refers solely to RFC4447bis? Is this intentional or a mistake? "* PW Type: 15 bits representation of PW type as specified in [RFC4447]." * The term "PMSI Tunnel info" is used without being defined and is required to calculate the length. I am guessing "PMSI Tunnel info" means the combination of PMSI Tunnel Type, Length and Transport LSP ID. If this is so, please make it explicit and define. If not, clarify.
Kathleen Moriarty Discuss
I haven't sen a response to the SecDir review, so please point me to one if there has been a response. I fully agree with Tero that MD5 is not adequate and hasn't been for some time. What is the plan to rectify this and deprecate use of the TCP MD5 signature for LDP? RFC8077, says that LDP MD5 authentication key option as described in the section 2.9 of RFC5036 MUST be implemented. I asked on my ballot for RFC8077 when a deprecation process would start in support of Stephen's abstain and would like an update on that process. https://mailarchive.ietf.org/arch/msg/secdir/ga2pIVcGw9WEgBX5MXA9MCmSs_s
Deborah Brungard Yes
Ben Campbell No Objection
Please check idnits. It flags some issues that should be resolved, especially 2119 language issues. The security considerations seem inadequate. I'm no expert here, but it seems like adding p2mp support in addition to p2p support has a good chance of creating some new considerations. If it really doesn't, it would be helpful to see arguments to that effect.
Benoit Claise No Objection
Here is Sarah's OPS DIR review. Her Why (Do I care?) comment resonates with me: I could not find the information. I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. I think the document is almost ready to go. I don't have technical issue with the content, but I think the document reads in parts like several authors cut/paste/contributed, and the document doesn't flow well in spots. Perhaps this is a personal choice, but I believe that documents that read with some amount of approachability with respect to all interested readers, and not just hard core whatever-the-protocol-is-fanatics, benefits our community for the better. Last, maybe it's the product manager in me, and not the development engineer, but why do I care? Is this just to add LDP as another mechanism for establishing the PW? Is there some deficit that's being addressed by LDP that existing mechanisms don't solve? This isn't addressed in a way that resonates in the document, for me. Last, while super picky, the acronym "PSN" was used in the abstract before being properly introduced. This was mostly made more noticeable by the fact that the rest of the draft does a fantastic job of introducing the terms before using the acronym.
Spencer Dawkins No Objection
Mirja Kühlewind No Objection
Terry Manderson No Objection
Eric Rescorla No Objection
I agree with Kathleen about the MD5 issue. I recognize it's not unique to this document, but eventually we do need to deal with it. intended for bidirectional service whereas the latter is intended for both unidirectional, and optionally bidirectional service. Requirements for P2MP PW are described in [RFC7338]. P2MP PW can be This is quite hard to read because P2MP and P2P are close. Perhaps replace "former" and "latter" with names. constructed as either Single Segment (P2MP SS-PW) or Multi Segment (P2MP MS-PW) Pseudowires as mentioned in [RFC7338]. P2MP MS-PW is outside the scope of this document. A reference model or a P2MP PW is Nit: you have singular/plural disagreement Parameters field in octets. If this value is 0, then it references all PWs using the specified grouping ID. In this case, there are neither other FEC element fields (AGI, SAII, etc.) present, nor any Which grouping ID? It's not clear to me what field this corresponds to.