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

IESG:

IANA has reviewed draft-ietf-l2vpn-arp-mediation-19.txt and has
the following comments:

IANA understands that, upon approval of this document, there are three IANA
actions which must be completed.

First, in the Status Code Name Space subregistry of the Label Distribution
Protocol (LDP) Parameters registry located at:

http://www.iana.org/assignments/ldp-namespaces

three new namespaces are to be created as follows:

0x0000002C "IP Address of CE"
0x0000004A "IP Address Type Mismatch"
0x0000004B "Wrong IP Address Type"

IANA understands that these values have undergone early allocation and already
appear in the registry.  Upon approval of this document, the references for
those early allocations will be changed to [ RFC-to-be ].

Second, in the Pseudowire Interface Parameters Sub-TLV type Registry located in
the Pseudowire Name Spaces (PWE3) registry located at:

www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xml

a new Sub-TLV type will be registered as follows:

Parameter: 0x16
ID Length: 4
Description: Stack capability
Reference: [ RFC-to-be ]

IANA understands that this value has undergone early allocation and already
appears in the registry.  Upon approval of this document, the reference for this
early allocation will be changed to [ RFC-to-be ].

Third, a new registry will be created called "L2VPN PE stack capabilities".
Maintenance of the registry will be done through IETF Review as defined in RFC
5226.  There are initial assignments in this registry as follows:
   
L2VPN PE Stack Capabilities:
 
Bit (Value)      Description
===============  ==========================================
Bit 0  (0x0001) - IPv6 stack capability
Bit 1  (0x0002) - Reserved
Bit 2  (0x0004) - Reserved
        .
        .
        .
Bit 14 (0x4000) - Reserved
Bit 15 (0x8000) - Reserved

A preliminary version of the registry has already been established in the
Pseudowire Name Spaces (PWE3) registry located at:

http://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xml#l2vpn-pe-stack

Upon approval of this document, the references in that registry will be updated
to [ RFC-to-be ].

IANA understands these to be the only actions required upon approval of this
document.

State changed to In Last Call from Last Call Requested

The following Last Call Announcement was sent out:

From: The IESG

To: IETF-Announce

CC:

Reply-To: ietf@ietf.org

Subject: Last Call:  (ARP Mediation for IP Interworking of Layer 2 VPN) to Proposed Standard





The IESG has received a request from the Layer 2 Virtual Private Networks

WG (l2vpn) to consider the following document:

- 'ARP Mediation for IP Interworking of Layer 2 VPN'

  as a Proposed Standard



The IESG plans to make a decision in the next few weeks, and solicits

final comments on this action. Please send substantive comments to the

ietf@ietf.org mailing lists by 2012-04-26. Exceptionally, comments may be

sent to iesg@ietf.org instead. In either case, please retain the

beginning of the Subject line to allow automated sorting.



Abstract





The Virtual Private Wire Service (VPWS) [RFC4664] provides

    point-to-point connections between pairs of Customer Edge (CE)

    devices.  It does so by binding two Attachment Circuits (each

    connecting a CE device with a Provider Edge, PE, device) to a

    pseudowire (connecting the two PEs).  In general, the Attachment

    Circuits must be of the same technology (e.g., both Ethernet,

    both ATM), and the pseudowire must carry the frames of that

    technology.  However, if it is known that the frames' payload

    consists solely of IP datagrams, it is possible to provide a

    point-to-point connection in which the pseudowire connects

    Attachment Circuits of different technologies. This requires the

    PEs to perform a function known as "ARP Mediation". ARP

    Mediation refers to the process of resolving Layer 2 addresses

    when different resolution protocols are used on either

    Attachment Circuit. The methods described in this document are

    applicable even when the CEs run a routing protocol between

    them, as long as the routing protocol runs over IP.







The file can be obtained via

http://datatracker.ietf.org/doc/draft-ietf-l2vpn-arp-mediation/



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-ietf-l2vpn-arp-mediation/ballot/





The following IPR Declarations may be related to this I-D:



  http://datatracker.ietf.org/ipr/1738/

[Ballot discuss]
1) in section 2, it says IPv4 L2 interworking MUST be supported, but it is only a SHOULD for IPv6.
Why is IPv6 mediation not a MUST for PEs?

(please note that draft-ietf-intarea-ipv6-required-02 is in IESG Eval for Proposed Standard. It hans't been approved yet, but probably will soon.)

2) in 3, "In this case, all data link headers are removed to expose the IP packet at the ingress." should this be MUST remove?
3) in 2, "Intercept Neighbor Discovery and Inverse Neighbor Discovery packets received over the pseudowire from the remote PE, possibly modifying them (if required for the type of outgoing AC) before forwarding to the local CE,"
Can the RFC2119 language make "possibly if required" less ambiguous? Does possibly mean "MUST if REQUIRED" or "SHOULD if REQUIRED" or "MAY if REQUIRED"?
and please make sure this section is consistent with section 3, "In the case of an IPv6 L2 Interworking Circuit, the egress PE MAY modify the contents of Neighbor Discovery or Inverse Neighbor Discovery packets ..."

[Ballot discuss]
1) in section 2, it says IPv4 L2 interworking MUST be supported, but it is only a SHOULD for IPv6.

draft-ietf-intarea-ipv6-required-02 is in IESG Eval for Proposed Standard.
Why is IPv6 mediation not a MUST for PEs?
2) in 3, "In this case, all data link headers are removed to expose the IP packet at the ingress." should this be MUST remove?
3) in 2, "Intercept Neighbor Discovery and Inverse Neighbor Discovery packets received over the pseudowire from the remote PE, possibly modifying them (if required for the type of outgoing AC) before forwarding to the local CE,"
Can the RFC2119 language make "possibly if required" less ambiguous? Does possibly mean "MUST if REQUIRED" or "SHOULD if REQUIRED" or "MAY if REQUIRED"?
and please make sure this section is consistent with section 3, "In the case of an IPv6 L2 Interworking Circuit, the egress PE MAY modify the contents of Neighbor Discovery or Inverse Neighbor Discovery packets ..."

[Ballot discuss]
I am reading the ND modifications and trying very hard to convince myself that they are correct and complete. I'm not 100% sure I've managed to do that.

I scanned the mailing list for 6man and found no discussion of this draft. Did I miss it? Shouldn't relatively complex surgery on ND require some review from the experts on ND?

I'm also wondering if the SEND proxy specification from CSI WG would be an applicable recommendation in addition to recommending turning SEND off.

To be more specific, can you:

1) perform a 2-week last call in 6MAN for additional review, and
2) either point to the use of the SEND proxy specification or provide reasons why it cannot be used

[Ballot discuss]
I am reading the ND modifications and trying very hard to convince myself that they are correct and complete. I'm not 100% sure I've managed to do that.

I scanned the mailing list for 6man and found no discussion of this draft. Did I miss it? Shouldn't relatively complex surgery on ND require some review from the experts on ND?

I'm also wondering if the SEND proxy specification from CSI WG would be an applicable recommendation in addition to recommending turning SEND off.

[Ballot comment]
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"?

[Ballot discuss]
I will move to a "Yes" ballot when my Discuss has been resolved.

Why does this document include a redefinition of the Address List TLV
that is already defined in RFC 5036? Although the text says that it is
using the RFC 5036 definition, the text also says that the I-D defines
the Address List TLV.

Shouldn't you simply refer to 5036 and say how the fields are set for
your specific use?

Similarly the redefinition of the Notification message.


To be clear, the main reason for objecting to the redefinition is that
it opens the door to discrepencies, and makes it hard to handle
future extensions. (Coders should be familiar with the practice of
only defining data structures in one place :-)

---

Please add some text to clarify whether the Stack Capability field 
in the Stack capability Interface Parameter sub-TLV is an integer or
a bit-field.

The IANA section makes it look like a bit field (which is what I
would expect) but the text in the main body says...

    Stack Capability = 0x0001 to indicate IPv6 stack capability

...which makes it look like an integer

Additionally, the text goes on to imply that the interpretation of
the field is context-specific...

    The value of Stack Capability is dependent on the PW type
    context. For IP Layer2 Transport type, a setting of 0x0001
    indicates IPv6 stack capability.

...if this is the case, presumably, 0x0001 could mean something else
in other circumstances. How is this tracked in the IANA registry?

[Ballot comment]
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"?

IANA understands that, upon approval of this document, there are three
IANA Actions which need to be completed.

First, in the Status Code Name Space in the Label Distribution Protocol
(LDP) Parameters registry located at:

http://www.iana.org/assignments/ldp-namespaces

there are three temporary status code assignments that will be moved
from temporary registration to permanent registration.  They are:

Status Code Description
=========== ===============================
0x0000002C  "IP Address of CE"
0x0000004A  "IP Address Type Mismatch"
0x0000004B  "Wrong IP Address Type"

Second, in the Pseudowire Interface Parameters Sub-TLV type Registry in
the Pseudowire Name Spaces (PWE3) registry located at:

http://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xml

the following temporary registration will be moved from temporary
registration to permanent registration.  It is:

0x16  "Stack Capability"

Third, IANA is to create a new registry - "L2VPN PE stack capabilities"

IANA QUESTION --> Should this be a standalone registry, or should it be
combined with an existing, larger registry? 

The rules for maintaining the registry are "IETF Consensus" policy
defined in RFC5226.

Initial registrations in the new registry will be as follows:

L2VPN PE Stack Capabilities:
   
Bit (Value)      Description            Reference
===============  =====================  ===============
Bit 0  (0x0001) - IPv6 stack capability  [ RFC-to-be ]
Bit 1  (0x0002) - Reserved
Bit 2  (0x0004) - Reserved
Bit 3  (0x0008) - Reserved              .
Bit 4  (0x0010) - Reserved
Bit 5  (0x0020) - Reserved
Bit 6  (0x0040) - Reserved
Bit 7  (0x0080) - Reserved
Bit 8  (0x0100) - Reserved
Bit 9  (0x0200) - Reserved              .
Bit 10 (0x0400) - Reserved
Bit 11 (0x0800) - Reserved
Bit 12 (0x1000) - Reserved
Bit 13 (0x2000) - Reserved              .
Bit 14 (0x4000) - Reserved
Bit 15 (0x8000) - Reserved

IANA understands that these are the only actions that need to be
completed upon approval of this document.

[Ballot comment]
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. :-/

[Ballot comment]
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".

[Ballot comment]
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."

[Ballot comment]
- 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.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (ARP Mediation for IP Interworking of Layer 2 VPN) to Proposed Standard


The IESG has received a request from the Layer 2 Virtual Private Networks
WG (l2vpn) to consider the following document:
- 'ARP Mediation for IP Interworking of Layer 2 VPN'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-09-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


    The Virtual Private Wire Service (VPWS) [RFC4664] provides
    point-to-point connections between pairs of Customer Edge (CE)
    devices.  It does so by binding two Attachment Circuits (each
    connecting a CE device with a Provider Edge, PE, device) to a
    pseudowire (connecting the two PEs).  In general, the Attachment
    Circuits must be of the same technology (e.g., both Ethernet,
    both ATM), and the pseudowire must carry the frames of that
    technology.  However, if it is known that the frames' payload
    consists solely of IP datagrams, it is possible to provide a
    point-to-point connection in which the pseudowire connects
    Attachment Circuits of different technologies. This requires the
    PEs to perform a function known as "ARP Mediation". ARP
    Mediation refers to the process of resolving Layer 2 addresses
    when different resolution protocols are used on either
    Attachment Circuit. The methods described in this document are
    applicable even when the CEs run a routing protocol between
    them, as long as the routing protocol runs over IP.


   



The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-l2vpn-arp-mediation/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-l2vpn-arp-mediation/


No IPR declarations have been submitted directly on this I-D.

(1.a) Who is the Document Shepherd for this document? Has the
      Document Shepherd personally reviewed this version of the
      document and, in particular, does he or she believe this
      version is ready for forwarding to the IESG for publication?

Shepherd: Nabil Bitar, nabil.n.bitar@verizon.com
Yes, I have reviewed the document and I believe it is ready for forwarding
to the IESG for publication.


(1.b) Has the document had adequate review both from key WG members
      and from key non-WG members? Does the Document Shepherd have
      any concerns about the depth or breadth of the reviews that
      have been performed?

Yes, the document has received adequate discussion and review.  The document has been
around for some time. A Working Group last call was issued based on version 15 of the document.
The document had received good support on the WG email list. Two comments
were received on the list from Li Zhong that were addressed in version 16. The first
comment was editorial about a codepoint that was already defined in another section.
The second comment was related to a PE behavior when there is a mismatch in IP address family
configuration that is later corrected. That comment was addressed at the end of section 6.1 in version 16.
In addition, in version 16 and based on review by the WG chairs, the operational procedure for
CE-PE IPv6-only AC was clarified in section 5.2, and the PE behavior upon receiving a
label withdrawal message with status code "wrong IP address type" status code was clarified
by reference to section of 6.2 in RFC4447. A WG last call was issued for section 5.2 and section 6
focusing on these changes. There was no objection received on the mailing list for these changes.
version 17 addressed some ID nits only.



(1.c) Does the Document Shepherd have concerns that the document
      needs more review from a particular or broader perspective,
      e.g., security, operational complexity, someone familiar with
      AAA, internationalization or XML?

No.


(1.d) Does the Document Shepherd have any specific concerns or
      issues with this document that the Responsible Area Director
      and/or the IESG should be aware of? For example, perhaps he
      or she is uncomfortable with certain parts of the document, or
      has concerns whether there really is a need for it. In any
      event, if the WG has discussed those issues and has indicated
      that it still wishes to advance the document, detail those
      concerns here. Has an IPR disclosure related to this document
      been filed? If so, please include a reference to the
      disclosure and summarize the WG discussion and conclusion on
      this issue.

No issues or concerns. I am not aware if an IPR disclosure was filed.


(1.e) How solid is the WG consensus behind this document? Does it
      represent the strong concurrence of a few individuals, with
      others being silent, or does the WG as a whole understand and
      agree with it?

I am comfortable that the document represents WG consensus and has
been reviewed by a reasonable number of active WG participants.


(1.f) Has anyone threatened an appeal or otherwise indicated extreme
      discontent? If so, please summarize the areas of conflict in
      separate email messages to the Responsible Area Director. (It
      should be in a separate email because this questionnaire is
      entered into the ID Tracker.)

None indicated.


(1.g) Has the Document Shepherd personally verified that the
      document satisfies all ID nits? (See the Internet-Drafts Checklist
      and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
      not enough; this check needs to be thorough. Has the document
      met all formal review criteria it needs to, such as the MIB
      Doctor, media type and URI type reviews?

Yes.  This document is not subject to MIB
doctor or other reviews.


(1.h) Has the document split its references into normative and
      informative? Are there normative references to documents that
      are not ready for advancement or are otherwise in an unclear
      state? If such normative references exist, what is the
      strategy for their completion? Are there normative references
      that are downward references, as described in [RFC3967]? If
      so, list these downward references to support the Area
      Director in the Last Call procedure for them [RFC3967].

Yes, the references are split appropriately.  All of the normative
references are to published RFC's, with no downrefs.


(1.i) Has the Document Shepherd verified that the document IANA
      consideration section exists and is consistent with the body
      of the document? If the document specifies protocol
      extensions, are reservations requested in appropriate IANA
      registries? Are the IANA registries clearly identified? If
      the document creates a new registry, does it define the
      proposed initial contents of the registry and an allocation
      procedure for future registrations? Does it suggest a
      reasonable name for the new registry? See [RFC5226]. If the
      document describes an Expert Review process has Shepherd
      conferred with the Responsible Area Director so that the IESG
      can appoint the needed Expert during the IESG Evaluation?

This document does contain an IANA Considerations section and it is
consistent with the body of the document.

With respect to the "LDP Status Messages", IANA had temporarily allocated
0x0000002C to this draft; however, that allocation expired on
4/21/2011.  This draft is also requesting two additional allocations from
the same registry that have NOT been allocated by IANA yet.

This document also requests a new PW Interface Parameters sub-TLV, stack capability,
from the "Pseudowire Interface Parameters Sub-TLV type Registry" that had been already
allocated by IANA for this draft.

Finally, this document requests that IANA create a new "L2VPN PE stack
capabilities" registry whose values are to be assigned by IANA through
"IETF Consensus" policy. The document also requests a specific setting for
IPv6 stack capability.


(1.j) Has the Document Shepherd verified that sections of the
      document that are written in a formal language, such as XML
      code, BNF rules, MIB definitions, etc., validate correctly in
      an automated checker?

There are no sections of the document that use a formal language.


(1.k) The IESG approval announcement includes a Document
      Announcement Write-Up. Please provide such a Document
      Announcement Write-Up? Recent examples can be found in the
      "Action" announcements for approved documents. The approval
      announcement contains the following sections:

  Technical Summary

A Virtual Private Wire Service (VPWS) provides a point-to-point connection service
between a pair of Customer Edge (CE) devices over an IP/MPLS packet switched network using Pseudowire
Emulation Edge to Edge (PWE3) technology.  It does so by binding two Attachment Circuits (ACs),
each connecting a CE device with a Provider Edge (PE) device, to a Pseudowire (PW) extended between the two PEs.
PWE3 defines PW types that interconnect ACs of the same technology (homogeneous ACs), e.g.,
both ACs being Ethernet. In general, a VPWS provides connectivity between homogeneous ACs using the
existing PWE3 technology. However, if the ACs are layer2 attachment circuits of
heterogeneous types (e.g., one AC is Ethernet and the other one is a Fame Relay DLCI), and solely carry
IP datagrams in the corresponding packet data units' payload, it is possible to provide a VPWS that interconnects
these ACs using IP Layer2 Transport PWs often referred to simply as IP PWs.
This requires the PEs to perform a function known as "ARP Mediation".  ARP Mediation refers to the
process of resolving IP addresses to Layer 2 addresses when different address resolution
protocols are used on either Attachment Circuit.  The methods described in this document are applicable even when
the CEs run a routing protocol between them as long as the routing protocol
runs over IP.

  Working Group Summary

This document has been in existence since the very beginning of
the PPVPN and L2VPN WG's.  At first, it only included support for
IPv4, but subsequently was updated to include support for IPv6.
Ultimately, this document provides a means of interworking
IPv4-enabled ACs, IPv6-enabled ACs and dual-stack IPv4/IPv6-enabled ACs whereby
the ACs are of disparate Layer2 technologies. Several implementations of this draft have existed in
the field for several years.


  Document Quality

There are no concerns about document quality.