MPLS and Ethernet Operations, Administration, and Maintenance (OAM) Interworking
draft-ietf-pwe3-mpls-eth-oam-iwk-08
Yes
(Stewart Bryant)
No Objection
(Barry Leiba)
(Benoît Claise)
(Brian Haberman)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Pete Resnick)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Sean Turner)
(Stephen Farrell)
(Wesley Eddy)
Note: This ballot was opened for revision 07 and is now closed.
Stewart Bryant Former IESG member
Yes
Yes
(for -07)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2013-02-18 for -07)
Unknown
I am balloting No Objection on this document. There is nothing fundamentally wrong with the procedures or the explanation, but I have quite a number of WIBNI-style Comments that I have set out below. I don't think that any of them should be used to hold up the document, but I wish that the issues could be made to go away. --- The formatting of this I-D seems to be strange around the left margin and the top-of-page margins. --- Does Dinesh really still work for Nortel? --- The only names in the "Authors' Addresses" section should be those on the front page. Other names should be moved to a new "Contributors" section. --- The guidelines for writing I-Ds say that the first section in the document should be the Introduction. I suspect that you have put the 2119 boilerplate first because you have use 2119 language within the Intrduction. This probably points to the fact that the Introduction is actually far more than an introduction, but is actually an introduciton, a problem, statement, and an overview of the solution. My preference would be for some restructuring work to make the separation of material cleaner, and the document a little more approachable, but it is a long shot to ask you to do this at the end of a long development sysle for this work. I would at least like you to look again at the use of 2119 language in the Introduction. Do you really need it? For example: When an Ethernet AC is an Ethernet physical port, there MAY be some application of Ethernet Link OAM [802.3]. Is that really a conformance rule for this specification, or just an observation that could be written in Enlgish? For example: The procedures outlined in this document define the entry and exit criteria for each of the four defect states with respect to Ethernet ACs and corresponding PWs, and the consequent actions that PE1 MUST support to properly interwork these defect states and corresponding notification messages between the PW domain and the Native Service (NS) domain. The "MUST" is surely fine in plain English. --- There seems to be a lot of duplicate material from RFC 6310. It is not easy to tell what is new material and what has been reproduced for reference. On the whole, I am not a fan of reproducing material from one RFC in another. If any discrepency is introduced there is an immediate problem determining which is the correct version. My preference is to make direct reference to the pre-existing material, rather than to reproduce it. Actually, I found it *really* hard to work out what material in this document is tutorial, and what material is a new specification. In my opinion, that really devalues this document. It certainly made my review less thorough because it is unclear whether text like that in section 5.1... PE1 enters the AC Receive Defect state if any of the following conditions is met: ...is a new definition of just commentary. --- Does this document update RFC 6310? he distinguish factor is whether you consider it makes sense to implement 6310 without this augmentation, or if you consider that this document only provides additional function for some cases such that 6310 is fine and fully functional without it. --- Section 2 - Ethernet Local Management Interface {E-LMI} [MEF16] Seems to use the wrong type of braces around E-LMI --- You have two different meanings for "MEP" in this document. --- The definition of MIP in Section 3.1 is surely wrong. --- In 3.2 you say that a MIP cannot terminate an OAM frame. But I thought that a MEP could send OAm specificially targetted at a MIP. It certainly can in MPLS. Is it different in Ethernet? Or do you have some special meaning for "terminate". --- In Section 4 you have "MPLS-IP PSN". Is this what is normally called an "IP/MPLS network" or is this a new term? And in this context is "MPLS PSN" meant to mean an MPLS network that has no IP support? --- A bit of nasty passive voice has crept in to Section 4.1 These NS OAM notifications are inserted into the corresponding PW. Who inserts, and where in the network? --- In 4.2 When PWs are established using the Label Distribution Protocol (LDP), LDP status notification signaling MUST be used as the default mechanism to signal AC and PW status and defects [RFC4447]. Is this restating 2119 language from RFC 4447, or is it making a new specification requirement? I'm almost at the point of a Discuss with this question, because if the answer is "new requirement" then I think you are probably updating a number of RFCs. OTOH, if it is a restatement, then you should not use 2119 language. --- In 4.2 For PWs established over an MPLS or MPLS-IP PSN using other mechanisms (e.g. static configuration), inband signaling using VCCV-BFD [RFC5885] SHOULD be used to convey AC and PW status and defects. What are the alternatives to "SHOULD"? Please state them and note when they can be used. --- 4.3 When using VCCV, the control channel (CC) type and Connectivity Verification (CV) Type are agreed on between the peer PEs using the VCC parameter field signaled as a sub-TLV of the interface parameters TLV when using FEC 129 and the interface parameter sub- TLV when using FEC 128. This paragraph should have a citation. Actually, I am not sure that anything in 4.3 is new material. Is it? --- 4.3 As defined in [RFC6310], when CV type of 0x04 0r 0x10 is used to s/0r/or/ --- It is customary and really useful to add a note at the start of an Appendix to indicate whether the material is informative or normative.
Barry Leiba Former IESG member
No Objection
No Objection
(for -07)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(for -07)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -07)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -07)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -07)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -07)
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
(for -07)
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
(for -07)
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
(for -07)
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(for -07)
Unknown
Sean Turner Former IESG member
No Objection
No Objection
(for -07)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(for -07)
Unknown
Wesley Eddy Former IESG member
No Objection
No Objection
(for -07)
Unknown