Address Resolution Protocol (ARP) Mediation for IP Interworking of Layer 2 VPNs
draft-ietf-l2vpn-arp-mediation-19
Yes
(Stewart Bryant)
No Objection
(Dan Romascanu)
(David Harrington)
(Gonzalo Camarillo)
(Jari Arkko)
(Ron Bonica)
(Wesley Eddy)
Abstain
Note: This ballot was opened for revision 19 and is now closed.
Adrian Farrel Former IESG member
(was Discuss)
Yes
Yes
(2011-09-22)
Unknown
Should the figure on page 5 include the label "AC3"?
---
I agree with the other ADs who are concerned about the use or non-use
of RFC 2119 language. Hopefully, this will be easy for you to clean up
and will not be construed as changing the technical content of the
document.
---
The "IP Layer 2 interworking circuit"
pseudowire is also commonly referred to as "IP pseudowire".
Can you insert a reference for "IP pseudowire"?
Stewart Bryant Former IESG member
Yes
Yes
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Harrington Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Peter Saint-Andre Former IESG member
No Objection
No Objection
(2011-09-21)
Unknown
This document appears to be predicated on "know[ing] that only IP traffic will be carried". How is this determined?
Ralph Droms Former IESG member
No Objection
No Objection
(2011-09-21)
Unknown
In section 4.3.3, is "the link-layer address of the local AC" really "the link-layer address of the PE interface attached to the local AC"?
Robert Sparks Former IESG member
No Objection
No Objection
(2011-09-21)
Unknown
Section 7.2 invokes an IANA well known policy of "IETF Consensus", referencing RFC5226, but that RFC has renamed that particular policy to "IETF Review".
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2011-09-21)
Unknown
The Gen-ART Review by Peter McCann on 20-Sep-2011 raised a minor issue and two editorial suggestions: Section 5.2 says: "Since this notification does not refer to any particular message the Message ID and Message Type fields are set to 0." There does not appear to be a Message Type field in the PDU. Section 5: suggest replacing the idiom "chicken and egg situation" with "possible deadlock situation." Section 5.2: "Section 6. below." should be "Section 6 below."
Sean Turner Former IESG member
No Objection
No Objection
(2011-09-22)
Unknown
I have the same question Stephen did about MD5.
Stephen Farrell Former IESG member
No Objection
No Objection
(2011-09-16)
Unknown
- 8.1 says that you "can" secure the PE-PE control plane "using MD5 authentication." Is that (still) the best that can be done? Doesn't it need a reference? Why can't something better be used, e.g. IPsec? Why no 2119 language? (This isn't a discuss because I hope that all that's in some other RFC.) - 8.1 says that this protocol is incompatible with SEND. I guess that's inevitable, but do you need to say more about the trade-offs concerned, e.g. would it ever be likely that a CE that depends on SEND is deployed and later on a PE doing this protocol is installed breaking the CE or changing its security properties in a bad way? (Just wondering.) - Frame Relay (FR) is expanded only on its 2nd use. 1st use is in 2nd para of section 1.
Wesley Eddy Former IESG member
No Objection
No Objection
()
Unknown
Pete Resnick Former IESG member
Abstain
Abstain
(2011-09-21)
Unknown
1. This entire document needs a good "MUST/SHOULD/MAY vs. must/should/may" scrubbing. Just to cite two examples:
4.2.2:
When the PE learns the IP address of the remote CE, it should
generate an Inverse ARP request.
It "should"? Or it "SHOULD"? Or it "will"?
4.3.2:
If a Router Discovery message contains a link layer
address, then the PE MAY also use this message to discover the
link layer address and IPv6 interface address.
That MAY doesn't sound like a protocol option.
2. Section 2:
PEs MUST support ARP mediation for IPv4 L2 Interworking
circuits. PEs SHOULD support ARP mediation for IPv6 L2
interworking circuits.
I assume this means "PEs that support ARP mediation MUST support it for IPv4 and SHOULD for IPv6". The way it is now, it sounds like ALL PEs must support this, which can't be right. That said, I see no reason for this paragraph. Mediation should be supported on both v4 and v6 circuits. I say drop the paragraph.
3. For the record, and not something the authors need to address:
I understand that the IETF doing sub-IP protocols is a ship that has sailed long before I got on the IESG. However, the mind boggles that we are deploying this particular protocol: Why can't we simply *route*?!?!? This protocol is standing on its head to allow layer 2 bridging of IP across disparate links instead of just having a routed VPN. This is goofy, it is a complete layer violation, and I don't think we should be standardizing this nonsense.
There, I feel marginally better. :-/