Skip to main content

Signaling Root-Initiated Point-to-Multipoint Pseudowire Using LDP
RFC 8338


(Deborah Brungard)

No Objection

(Adam Roach)
(Alvaro Retana)
(Mirja Kühlewind)
(Spencer Dawkins)
(Terry Manderson)


Note: This ballot was opened for revision 03 and is now closed.

Deborah Brungard Former IESG member
Yes (for -03) Unknown

Adam Roach Former IESG member
No Objection
No Objection (for -03) Unknown

Alvaro Retana Former IESG member
No Objection
No Objection (for -03) Unknown

Ben Campbell Former IESG member
No Objection
No Objection (2017-08-28 for -03) Unknown
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.
Benoît Claise Former IESG member
No Objection
No Objection (2017-08-31 for -03) Unknown
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.
Eric Rescorla Former IESG member
No Objection
No Objection (2017-08-30 for -03) Unknown
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.
Mirja Kühlewind Former IESG member
No Objection
No Objection (for -03) Unknown

Spencer Dawkins Former IESG member
No Objection
No Objection (for -03) Unknown

Suresh Krishnan Former IESG member
(was Discuss) No Objection
No Objection (2017-11-12) Unknown
Thanks for addressing my DISCUSS point.
Terry Manderson Former IESG member
No Objection
No Objection (for -03) Unknown

Kathleen Moriarty Former IESG member
(was Discuss) Abstain
Abstain (2017-12-22) Unknown
In response my discuss, a document to detail out security options was promised, but has not materialized as of yet.  While the added text for my discuss points out that MD5 isn't the best choice, there is no alternative or even a plan to follow from this document (a reference to the promised draft would have been helpful, but it doesn't exist yet).  As such, I am abstaining.  I do hope that document will be pursued and the routing ADs will ensure follow through.