Address Resolution Protocol (ARP) Mediation for IP Interworking of Layer 2 VPNs
RFC 6575

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

(Stewart Bryant) Yes

(Adrian Farrel) (was Discuss) Yes

Comment (2011-09-22)
No email
send info
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"?

(Jari Arkko) (was Discuss) No Objection

(Ron Bonica) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

Comment (2011-09-21 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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"?

(Wesley Eddy) No Objection

(Stephen Farrell) No Objection

Comment (2011-09-16 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
- 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.

(David Harrington) (was Discuss) No Objection

(Russ Housley) No Objection

Comment (2011-09-21 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  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."

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

Comment (2011-09-21 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
This document appears to be predicated on "know[ing] that only IP traffic will be carried". How is this determined?

(Robert Sparks) No Objection

Comment (2011-09-21 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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".

(Sean Turner) No Objection

Comment (2011-09-22 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I have the same question Stephen did about MD5.

(Pete Resnick) Abstain

Comment (2011-09-21 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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. :-/