Packet Pseudowire Encapsulation over an MPLS PSN
Note: This ballot was opened for revision 03 and is now closed.
(Adrian Farrel) Yes
(Ron Bonica) No Objection
(Gonzalo Camarillo) No Objection
(Ralph Droms) No Objection
(Wesley Eddy) No Objection
(Stephen Farrell) No Objection
(Russ Housley) No Objection
(Pete Resnick) No Objection
Comment (2012-03-11 for -03)
Sometimes I feel like people do fun things with 2119 language entirely for my entertainment when it's a document outside of my area. :-) Seriously, these are all simply comments that I think will improve the comprehensibility of the document. I hope they help. Section 1: Where the client equipment is connected to the server equipment via a physical interface, the same data-link type MUST be used to attach the clients to the Provider Edge equipments (PE)s, and a pseudowire (PW) of the same type as the data-link MUST be used [RFC3985]. Something is odd here. RFC3985 is Informational and is not a normative reference, and it doesn't include any MUSTs, so those requirements can't be coming from 3985 per se. And I suspect they are not new requirements in this document at all. Do you actually mean the following? The architecture in [RFC3985] says that, where the client equipment is connected to the server equipment via a physical interface, the same data-link type will be used to attach the clients to the Provider Edge (PE) equipment, and a pseudowire (PW) of the same type as the data-link will be used. Also in Section 1: Non-normative Appendix Appendix A provides information... This verbal tic of inserting the words "non-normative" I find completely silly. It is absolutely clear from the contents of the appendix that it is non-normative, and we're heading down the path where sections will be titled, "Non-normative Table of Contents" and "Non-normative Acknowledgements". Please remove those words. Section 5: The PEs MAY use a local Ethernet address for the Ethernet header used to encapsulate the client network layer packet. Alternatively the PEs may use the following procedure. I found the above confusing. The first "procedure" after this is an IANA procedure, and the "may" there looks like it should be a "MAY". Perhaps instead: The PEs MAY use a local Ethernet address for the Ethernet header used to encapsulate the client network layer packet, or MAY use one of the special Ethernet addresses "PacketPWEthA" or "PacketPWEthB" as described below. Also in section 5: IANA are requested to allocate two unicast Ethernet addresses [RFC5342] to this protocol (PacketPWEthA and PacketPWEthB). PacketPWEthA is the value lower Ethernet address and PacketPWEthB is the higher value Ethernet address. Where [RFC4447] signalling is used to set up the PW, the LDP peers compare IP addresses and with the PE with the higher IP address uses PacketPWEthA, whilst the LDP peer with the lower IP address uses PacketPWEthB. Very awkwardly worded and confusing to me. Instead maybe: IANA is requested to allocate [ed note: RFC Editor will change to "has allocated"] two unicast Ethernet addresses [RFC5342] for use with this protocol, referred to as "PacketPWEthA" and "PacketPWEthB". Where [RFC4447] signalling is used to set up the PW, the LDP peers numerically compare their IP addresses. The LDP PE with the higher value IP address will use PacketPWEthA, whilst the LDP peer with the lower value IP address uses PacketPWEthB. Also in section 5: Not withstanding the fact that this PW represents a point-to-point connection, some client layer protocols require the use of a destination multicast address in the Ethernet encapsulation. This mode of operation MUST be supported. The passive voice in the last sentence is problematic. Do you mean, "Peers MUST be prepared to handle a destination mulitcast address in the Ethernet encapsulation"? Section 6: Thus, for example, the Ethernet OAM is NOT REQUIRED. "NOT REQUIRED" is not a 2119 term. I think you might mean "Thus, for example, a server LSR MAY choose not to use Ethernet OAM". Or you might simply mean "not required". Appendix A: This appendix is non-normative. Please strike.
(Dan Romascanu) No Objection
Comment (2012-03-13 for -03)
1. In the Abstract s/is the case/in the case/ 2. In Section 6 - VLANs, 802.1p and 802.1Q are not Ethernet but bridging fucntions So I suggest the following changes: in the title s/Ethernet/Ethernet and IEEE 802.1/ and: OLD: The use and applicability of Ethernet VLANs, 802.1p, and 802.1Q between PEs is not supported. NEW: The use and applicability of VLANs, IEEE 802.1p, and IEEE 802.1Q between PEs is not supported. Maybe adding 'tagging' after 802.1Q would help if this is the intent.
(Peter Saint-Andre) No Objection
(Robert Sparks) No Objection
(Sean Turner) No Objection
(Stewart Bryant) (was Abstain) Recuse
Comment (2012-03-05 for -03)
Previous Abstain position was a mouse error.