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

[Linda Dunbar <[e-mail]>]

Himanshu, 

 

I understand that my comments come too late. But thank you very much for
explaining the history. 

 

 

  _____  

From: Himanshu Shah [mailto:[e-mail]] 
Sent: Thursday, September 09, 2010 8:04 AM
To: Linda Dunbar
Cc: [e-mail]
Subject: Re: Comments to draft-ietf-l2vpn-arp-mediation-14

 

Hi Linda -

 

'link' mediation and/or service (Eth/ATM/FR) interworking, etc is not in

the charter of IETF. We spent quite bit of time in the initial years to

position this work within the scope of IETF charter.

 

[Linda] That is really interesting. 

 

As was mentioned in the IPLS discussion thread, ARP precedes unicast IP PDU

frame generation/processing. A CE router typically first engages in IGP
protocols to obtain

IP address of the neighbor/host, does ARP to obtain MAC<->IP association on
Ethernet and

then sends IP unicast frame. In ATM/FR, Inverse ARP is used. This is the
basic method

used in IP. You seem to be suggesting that CE should stop using ARP. There
is no

intension of this draft or for that matter L2VPN charter to mandate that.

 

[Linda] I am not suggesting CE should stop using ARP. I really see ARP is
not the main issue here. The draft is really mediating two different types
of links.  Now I understand it is historic. 

 

Cheers, Linda

 

 

Other comments in line..

 

 

 

 

 

 

 

 

On Sep 8, 2010, at 4:56 PM, 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?

 

 

[himanshu] Here is that bullet from the draft. I think it is quite clear..  

 

Intercept Neighbor Discovery and Inverse Neighbor Discovery

         packets received from the local CE device, learning
          information about the IPv6 configuration of the CE, before
          forwarding the packets across the VPWS to the remote PE.

 

 

 

 

 





*          

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

 

[himanshu] The entire draft is about ARP based discovery, distribution and
proxying for remote CE. I suggest giving it another read..





*          

*         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".

 

 

[himanshu] Not sure exactly what you are asking. Perhaps the discussion
above responds to your question. 

As indicated in the draft, draft can only facilitate connectivity between
one local CE with one remote CE.

If multiple CEs appear to be present on the local AC, additional means must
be used to select one local CE.

 

 

regards,

himanshu

 





Best Regards,

 

Linda Dunbar