RE: Comments to draft-ietf-l2vpn-arp-mediation-14

[Linda Dunbar <[e-mail]>]

Shane, 

 

I totally understand your points. 

Yes, my comments were too late. 

 

Linda 

 

  _____  

From: Shane Amante [mailto:[e-mail]] 
Sent: Wednesday, September 08, 2010 8:37 PM
To: Linda Dunbar
Cc: [e-mail]; 'Himanshu Shah'
Subject: Re: Comments to draft-ietf-l2vpn-arp-mediation-14

 

Hi Linda,

 

I would note that the WG Last Call for ARP-MED was completed as of
4/25/2010.  We're in the process of writing up the PROTO doc and sending
ARP-MED off to the IESG.  While your comments/questions for clarification of
the existing document(s) are still welcome, I believe it's long past the
time to significantly update or change them.  Furthermore, we are aware of
implementations of ARP-MED, which is why it's important that we (finally)
publish this draft "as is" as an RFC and do not delay it further.

 

Finally, I think it's important to keep in mind that both IPLS and ARP-MED
have been around for quite some time (~2003?) and, thus, were created with a
different set of requirements and design assumptions than you may expect
and/or desire.  If you have a proposal for enhancements and/or changes to
IPLS or ARP-MED, I would suggest you publish an Internet Draft for people to
review and consider whether that is something the L2VPN WG, or another WG,
is an appropriate place to further discuss and potentially develop it.

 

I will let Himanshu or another co-author/contributor respond to your
questions below.

 

Thanks,

 

-shane

<WG co-chair hat on>

 

 

On Sep 8, 2010, at 14:56 MDT, Linda Dunbar wrote:





Himanshu, et al,

 

May I suggest a more accurate name for the mechanism described in this
draft? This draft describes a way for VPWS to interconnect CEs with
different Link Layers.

More accurate name for the mechanism described in the draft should be
"Link-mediation".

 

The name "arp-mediation" is mis-leading. First of all, there is really no
need for PE or CE to perform ARP for the configurations described in the
draft. The draft assumes that there is only one local CE for each AC.  If
the link layer between AC and CE is Ethernet, the PE can simply encapsulate
the data frames received from remote side (i.e. from VPWS) with DA =
broadcast and SA =its own MAC.  Since there is only one CE for the AC,
broadcast will reach the CE the same way as unicast frame without consuming
any extra bandwidth.

 

For data frames from CE towards remote CE (i.e. towards AC), the PE can
simply remove the Link Layer header and forward inner IP frame across the
VPWS. The remote PE can simply add its own Link Layer header (with
DA=broadcast) and forward it to the only CE attached.

Local PE doesn't need to know the remote CE's IP. From routing point of
view, the remote CE is just next hop from the local CE. Therefore, the data
frame from CE towards AC may have IP address not equal to the remote CE.
Your draft also stated that the PEs are not routers. Therefore, PEs don't
need to have all the forwarding information.

 

 

Other minor comments:

*         Page 6, Bullet 3 under action for IPv6: The bullet 2 stated that
local PE intercepts ND and Inverse ND. Does it mean that ND and Inverse ND
will not traverse through the VPWS? So remote PE will not see any ND or
inverse ND frame from VPWS, will it?

*         Page 8, second paragraph: "..proxy function are completed". What
proxy function is this referring to?

*         Page 8: last paragraph: in the situation where LAN is connected
PE, your draft requires the PE to select one CE. Does it mean the PE will
forward traffic to other CEs to the locally select CE?  Under this
circumstance, it is more effective for PE to use the broadcast address for
traffic towards local CEs. Then there is no need to "select one CE".

 

Best Regards,

 

Linda Dunbar