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

From: Linda Dunbar <[email-masked]>
Date: Wed, 08 Sep 2010 15:56:59 -0500

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

---

From: John E Drake <[email-masked]>
Date: Wed, 8 Sep 2010 14:04:24 -0700

Linda,

This sounds remarkably like the Network Layer Transport Service defined in Section 3.4.5 of RFC 5921.

Thanks,

John

Sent from my iPhone

From: [email-masked] [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, September 08, 2010 1:57 PM
To: [email-masked]; 'Himanshu Shah'
Subject: Comments to draft-ietf-l2vpn-arp-mediation-14

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

---

From: Shane Amante <[email-masked]>
Date: Wed, 8 Sep 2010 19:36:32 -0600

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:

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

---

From: Himanshu Shah <[email-masked]>
Date: Thu, 9 Sep 2010 06:04:03 -0700

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.

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.

Other comments in line..

On Sep 8, 2010, at 4:56 PM, Linda Dunbar wrote:

Himanshu, et al,

Other minor comments:

[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

---

From: Linda Dunbar <[email-masked]>
Date: Sun, 12 Sep 2010 08:53:07 -0500

Himanshu, 

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

  _____  

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

Hi Linda -

[Linda] That is really interesting. 

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

[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..

 

 

Himanshu, et al,

 

Other minor comments:

 

 

*          

[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

---

From: Linda Dunbar <[email-masked]>
Date: Sun, 12 Sep 2010 08:53:07 -0500

Shane, 

I totally understand your points. 

Yes, my comments were too late. 

Linda 

  _____  

From: Shane Amante [mailto:[email-masked]] 
Sent: Wednesday, September 08, 2010 8:37 PM
To: Linda Dunbar
Cc: [email-masked]; '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>

Himanshu, et al,

 

Other minor comments:

Best Regards,

Linda Dunbar