Subject: Comments to draft-ietf-l2vpn-ipls-09

From: Linda Dunbar <[email-masked]>
Date: Fri, 27 Aug 2010 16:13:35 -0500

Himanshu, 

I am very puzzled by the approach described by draft-ietf-l2vpn-ipls-09.
Hope you can help me with the questions:

*	Your draft requires PEs snoop all the ARP messages from local CEs,
and then establish appropriate PW to remote PEs. 

First of all, CEs may not always send ARP message before sending any data
frames. Your draft assumes that those CEs are routers. Then routers sends
IS/IS LSAs and Hellos which are broadcast messages. From neighbors' LSA and
Hellos, the router will learn neighbor's MAC/IP. It doesn't need to send ARP
requests. When CEs don't send ARP, how does your approach work? 

*	On page 5 bullet 2, you wrote that if PEy has two CEs (CEa and CEb),
two separate PWs are created. Creating one PW per CE is a lot of work. Why
need this complexity?

If there is dedicated PW for each CE and those CEs are routers, then PEs
just forward the data frames to the dedicated PWs. There is no need for
removing the MAC header along the PW. There is only one place to go along
the PW, why bother adding and removing the MAC header?   

*	As for ARP, there is gratuitous ARP and ARP requests. Your draft
should clearly differentiate them if you still want to go along with the
approach to snoop ARP.  Section 5.1.1 stated that PE will generate ARP
requests periodically. It is really not necessary at all. 

*	For IPv6, Local PE can simply block un-needed solicited-node
multicast address based on local CE's IP address, so that ND message won't
go through the local domain if the CE is not the target. Personally, I don't
think it is necessary for PEs to mess with ND or ARP. If CE is a router,
then the routing discovery messages (like OSPF and ISIS) will broadcast all
local addresses to their immediate neighbors. All the routers in this
broadcast domain will learn them. If PE wants to learn them, PE can too. 

*	Section 6.0: PW creation: do you mean PW is created upon detecting
the first ARP message? Will it be too slow? The message has to wait until
the PW is created? When CEs sends out data frames before sending any ARP,
does it mean that PE has to hold all the data frames until the corresponding
PW is established? How much buffer PE needs to have? 

Thanks, Linda Dunbar

Advanced Technology Dept, Wireline Networks,

Huawei Technologies, Inc.

---

From: Himanshu Shah <[email-masked]>
Date: Mon, 30 Aug 2010 13:57:59 -0700

Hi Linda -
I am glad that IPLS is rekindling the interest due to Data Center Interconnect activities.
Central theme of IPLS is to provide L2 based multipoint connectivity for IP through
Control plane MAC address distribution.

Response to your questions in line..

Regards,
himanshu

From: Linda Dunbar [mailto:[email-masked]]
Sent: Friday, August 27, 2010 5:14 PM
To: [email-masked]; Himanshu Shah
Subject: Comments to draft-ietf-l2vpn-ipls-09

Himanshu,

I am very puzzled by the approach described by draft-ietf-l2vpn-ipls-09. Hope you can help me with the questions:

 *   Your draft requires PEs snoop all the ARP messages from local CEs, and then establish appropriate PW to remote PEs.

First of all, CEs may not always send ARP message before sending any data frames. Your draft assumes that those CEs are routers. Then routers sends IS/IS LSAs and Hellos which are broadcast messages. From neighbors' LSA and Hellos, the router will learn neighbor's MAC/IP. It doesn't need to send ARP requests. When CEs don't send ARP, how does your approach work?
[Himanshu>] As stated in section 5.1 CE Discovery - PE also discovers CE (learn MAC addr) from link-local IP multicast frames. You mention ISIS which does not use IP PDU. There is a separate section in the draft on how ISIS PDUs can be handled. As for
OSPF and other protocols that use IP PDU, they do use ARP for address resolution.

 *   On page 5 bullet 2, you wrote that if PEy has two CEs (CEa and CEb), two separate PWs are created. Creating one PW per CE is a lot of work. Why need this complexity?
[Himanshu>] IP PW carries IP frames (no MAC header). PE receiving frames over PW need a PW label to find next hop related information, since PE does not look up IP-DA (i.e. LPM) and there are no IP tables.

If there is dedicated PW for each CE and those CEs are routers, then PEs just forward the data frames to the dedicated PWs. There is no need for removing the MAC header along the PW. There is only one place to go along the PW, why bother adding and removing the MAC header?
[Himanshu>] L2VPN charter states multipoint service for IP traffic (as opposed to p2p service for IP traffic provided by arp-mediation draft), which is what IPLS provides. You could use MAC headers and Ethernet PWs using VPLS.

 *   As for ARP, there is gratuitous ARP and ARP requests. Your draft should clearly differentiate them if you still want to go along with the approach to snoop ARP.  Section 5.1.1 stated that PE will generate ARP requests periodically. It is really not necessary at all.
[Himanshu>] There is no announcement when an IP end station goes away. Section 5.1.1 describes a low grade ARP based heartbeat to keep a check that CE is operational. This has nothing to do with snooping.

 *   For IPv6, Local PE can simply block un-needed solicited-node multicast address based on local CE's IP address, so that ND message won't go through the local domain if the CE is not the target. Personally, I don't think it is necessary for PEs to mess with ND or ARP. If CE is a router, then the routing discovery messages (like OSPF and ISIS) will broadcast all local addresses to their immediate neighbors. All the routers in this broadcast domain will learn them. If PE wants to learn them, PE can too.
 [Himanshu>] Can you expand on this?

 *   Section 6.0: PW creation: do you mean PW is created upon detecting the first ARP message? Will it be too slow? The message has to wait until the PW is created? When CEs sends out data frames before sending any ARP, does it mean that PE has to hold all the data frames until the corresponding PW is established? How much buffer PE needs to have?
 [Himanshu>]In IPLS there is 'multicast' PW where multicast IP frames as well as ARP frames can flow. The 'multicast' PW is created when IPLS instance is configured. 'unknown' unicast frames are not sent on this 'multicast' pw, so yes, there is no provision to propagate unknown unicast MAC DA until PE knows where the  MAC DA resides. These frames are NOT stored at the source PE (i.e. discarded) waiting on some remote PE to announce where the MAC DA resides. Fortunately, IP is structured layered protocol which provides various means to associate IP to MAC (if Ethernet). As long as PE is reciprocating on all those methods, it will discover the local CE and announce it to all the remote PEs. It is also possible to configure the MAC address of the CE in lieu of anticipated unsuccessful auto discovery.

Thanks, Linda Dunbar