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

From: Linda Dunbar <[email-masked]>
Date: Wed, 01 Sep 2010 10:33:34 -0500

Himanshu, 

Thanks for the answers. Your answers trigged more questions from me, which
are inserted below:

  _____  

From: Himanshu Shah [mailto:[email-masked]] 
Sent: Monday, August 30, 2010 3:58 PM
To: Linda Dunbar; [email-masked]
Subject: RE: Comments to draft-ietf-l2vpn-ipls-09

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. 

[Linda] Thanks. 

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

[Linda] If the L2VPN is to interconnect Ethernet segments, Why not use the
Ethernet PW? What are the reasons to use IP PW to interconnect Ethernet
segments?

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.

[Linda] Are there benefits of using IP PW than using Ethernet PWs to
interconnect Ethernet segments? 

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

[Linda] So it is not the ARP traditional used by end stations (or hosts),
correct? Is the message between PE and the local CEs? Or is the message for
PE to announce all the locally attached CEs to other PEs? The draft should
clearly distinguish them. 

If the message is for PEs to have a heartbeat with local routers, we should
use a different term, like host (or router) Keep-Alive message to describe
the behavior. Actually, listening to routing protocol's Hello message
probably is simpler than using this new message. Since you already has a
separate section describing how to listen to IS/IS, why not create a section
to listen to OSPF?

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

[Linda] Who not allow "unknown" unicast to be sent over the Multicast PW?
Normal bridge (switch) will forward "unknown" unicast frame to all the ports
enabled for the VLAN. 

Thanks, Linda Dunbar

Advanced Technology Dept, Wireline Networks,

Huawei Technologies, Inc.