Subject: re: Alternative option for IP-only L2VPN?//re: New Version Notification for draft-xu-virtual-subnet-02

From: Xu Xiaohu <[email-masked]>
Date: Sat, 28 Aug 2010 11:39:52 +0800

Hi all,

Since there is no comment till now, let me make some comments on the IPLS
first.

1. If I understand the so-called PW in IPLS correctly, it is not the
traditional PW any more. The so-called PW label in IPLS is more like a VPN
label for the VRF route in L3VPN (in per-vrf-route label mode). That's to
say, the PW label in IPLS is a VPN label for the route of CE MAC. To be
understanded more easily, I suggest using other term than PW label in IPLS.

2. ARP packets even including the unicast ARP reply packets are forwarded
from ACs to "multicast" PWs. Besides, the received APR packets from the
"multicast" PWs will be flooded to all CEs. Does this action worsen the ARP
storm impacts, instead of alleviating them?

3. As said in IPLS, "...Note that the use of multipoint to point and
unidirectional characteristics of the PW makes BGP as the ideal candidate
for PW-FEC signaling. The use of BGP for such purposes is for future study."
Besides, LDP-based PW signaling is not much scalable and optimal in a large
scale network (e.g., large metro networks) where a large amount of meshed
LDP sessions and the corresponding configuration work would be required.
Provided BGP was used, why not go step further, e.g., use it to advertise CE
host route, since only IP traffic needs to be supported in the IP-only
L2VPN? 

4. As saind in IPLS, "An IP frame received over a unicast pseudowire is
prepended with a MAC header before transmitting it on the appropriate ACs
and the source MAC address is the PE’s own local MAC address or a MAC
address which has been specially configured on the PE for this use."  As a
result, the Ethernet switches between the PE and CEs can not keep the MAC
entries of the remote CEs from expiring even there are continues traffic
between these CEs. Note that the destination MAC address of the packet to
the remote CE which is sent from a local CE is the MAC of the remote CE,
rather than the local PE's MAC. Thus, flooding unknown unicast packets would
not be avoided on the above Ethernet switches. 

5. As said in IPLS, "...IPLS prohibits connection of a common LAN or VLAN to
more than one PE". However, isn't the multi-homing to multiple PEs needed in
practice? 

6. If I understand it correctly, the so-called ARP proxy in IPLS is not
exactly the Proxy ARP technology defined in [RFC 925] since "...the local PE
responds to ARP requests received over the Attachment Circuit via learnt IP
and MAC address
associations, which are advertised by the remote PEs.", rather than its own
MAC address. Hence, I suggest using other term than ARP proxy in IPLS.

Best wishes,
Xiaohu

> -----邮件原件-----
> 发件人: Xu Xiaohu [mailto:[email-masked]]
> 发送时间: 2010年8月26日 12:19
> 收件人: [email-masked]'
> 抄送: [email-masked]'; [email-masked]'; [email-masked]'
> 主题: Alternative option for IP-only L2VPN?//re: New Version Notification
for
> draft-xu-virtual-subnet-02
> 
> Hi,
> 
> I noticed that Virtual Subnet
> (http://tools.ietf.org/html/draft-xu-virtual-subnet-02) is much similar
with
> IPLS (http://tools.ietf.org/wg/l2vpn/draft-ietf-l2vpn-ipls/) from the
> perspective of service function (i.e., IP-only L2VPN). Besides, in both
> approaches, the Ethernet MAC header of a unicast IP packet received from
an
> AC is stripped before forwarding the frame to the remote PE.
> 
> The major differences between them are as follows:
> 
> In IPLS, the Address List TLV as defined in LDP [RFC 3036] is used to
> signal the MAC (and optionally IP) address of the local CE, besides, IP
traffic
> is forwarded from the AC to the PW based on the destination MAC address of
the
> layer 2 frame (and not based on the IP Header), although the Ethernet MAC
header
> of a unicast IP packet received from an AC is stripped before forwarding
the
> frame to the unicast pseudowire.
> 
> In VS, the proven BGP/MPLS VPN [RFC2547bis] is used to exchange connected
host
> routes for the local CE hosts which are automatically generated according
to
> the ARP cache entries of CE hosts. IP traffic is forwarded based on the
> destination IP addresses just as what today's L3VPN does.
> 
> Any comments?
> 
> Best wishes,
> Xiaohu
> 
> 
> > -----邮件原件-----
> > 发件人: Xu Xiaohu [mailto:[email-masked]]
> > 发送时间: 2010年8月24日 14:58
> > 收件人: [email-masked]'; [email-masked]'
> > 抄送: [email-masked]'
> > 主题: fwd: New Version Notification for draft-xu-virtual-subnet-02
> >
> > Hi all,
> >
> > This is an updated version of Virtual Subnet (VS): A Scalable Data
Center
> > Network Architecture (see
> > http://tools.ietf.org/html/draft-xu-virtual-subnet-02).
> >
> > VS actually uses BGP/MPLS VPN technology [RFC4364] with some extensions,
> > together with some other proven technologies including ARP proxy
> > [RFC925][RFC1027] to build a scalable large IP subnet across the MPLS/IP
> > backbone of the data center network. As a result, VS can be deployed
today
> as
> > a scalable data center network.
> >
> > I wonder whether Internet Area Working Group or Routing Area Working
Group
> is
> > a suitable place to discuss this. By the way, since the draft is much
related
> > to L3VPN, I also copy this email to the L3VPN WG mailing-list.
> >
> > Best wishes,
> > Xiaohu
> >
> > [RFC925] Postel, J., "Multi-LAN Address Resolution", RFC-925, USC
> > Information Sciences Institute, October 1984.
> > [RFC1027] Smoot Carl-Mitchell, John S. Quarterman,” Using ARP to
Implement
> > Transparent Subnet Gateways”, RFC 1027, October 1987.
> >
> > -----邮件原件-----
> > 发件人: IETF I-D Submission Tool [mailto:[email-masked]]
> > 发送时间: 2010年8月24日 12:22
> > 收件人: [email-masked]
> > 主题: New Version Notification for draft-xu-virtual-subnet-02
> >
> >
> > A new version of I-D, draft-xu-virtual-subnet-02.txt has been
successfully
> > submitted by Xiaohu Xu and posted to the IETF repository.
> >
> > Filename:	 draft-xu-virtual-subnet
> > Revision:	 02
> > Title:		 Virtual Subnet: A Scalable Data Center Network
Architecture
> > Creation_date:	 2010-08-24
> > WG ID:		 Independent Submission
> > Number_of_pages: 12
> >
> > Abstract:
> > This document proposes a scalable data center network architecture
> > which, as an alternative to the Spanning Tree Protocol Bridge
> > network, uses a Layer 3 routing infrastructure to provide scalable
> > virtual Layer 2 network connectivity services.
> >
> >
> >
> > The IETF Secretariat.

---

From: Himanshu Shah <[email-masked]>
Date: Tue, 31 Aug 2010 08:33:39 -0700

Comments in line..

Thanks,
himanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xu Xiaohu
Sent: Friday, August 27, 2010 11:40 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: re: Alternative option for IP-only L2VPN?//re: New Version Notification for draft-xu-virtual-subnet-02

Hi all,

[Himanshu>] 
[Himanshu>]  No.

[Himanshu>] The main purpose of IPLS is to not prevent ARP storms.
However, optional ARP proxy mechanism is described in the draft which
can be used to prevent propagation of ARP broadcast, if needed.

[Himanshu>] IPLS provides a layer-2 based multipoint IP connectivity. 
Distribution of MAC addresses of CEs is an important step in IPLS, while
distribution of IP address of CE is optional and recommended but is
not required for the operation of the IPLS as such. 

[Himanshu>] This is true. It is recommended that these intermediary switches
are configured to not age out the learned MAC entries (it is common feature
in most LAN switches).

[Himanshu>] As suggested in the draft, dual-homing is supported by IP host/router
connecting to two PEs on different subnets. Now it is possible to have many other
out-of-band mechanisms (that have been discussed in various other drafts) to 
support dual-homing within the same subnet. This can be a future work item.

Best wishes,
Xiaohu

for
with
an
traffic
the
header
the
host
to
Center
today
Group
related
Implement
successfully
Architecture

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 01 Sep 2010 09:36:25 +0800

Hi Himanshu,

> -----邮件原件-----
> 发件人: Himanshu Shah [mailto:[email-masked]]
> 发送时间: 2010年8月31日 23:34
> 收件人: Xu Xiaohu; [email-masked]
> 抄送: [email-masked]; [email-masked]; [email-masked]
> 主题: RE: Alternative option for IP-only L2VPN?//re: New
VersionNotification
> for draft-xu-virtual-subnet-02
> 
> Comments in line..
> 
> Thanks,
> himanshu
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Xu
> Subject: re: Alternative option for IP-only L2VPN?//re: New Version
> Notification for draft-xu-virtual-subnet-02
> 
> Hi all,
> 

How about calling it ARP cache rather than ARP proxy?  ARP proxy will
respond with its won MAC address on behalf of the requested host, according
to the specification defined in [RFC925].

> not required for the operation of the IPLS as such.

Since the MAC reachability information is distributed among PEs, the non-IP
Ethernet traffic could also be supported as well in IPLS. Right?

> are configured to not age out the learned MAC entries (it is common
feature

Considering a large data center network where tens to hundreds of thousands
of VMs exist, do you think these intermediary switches' forwarding tables
can still scale well?

> connecting to two PEs on different subnets. Now it is possible to have
many
> other

Good news.

Best wishes,
Xiaohu

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 01 Sep 2010 14:22:06 +0800

Hi all,

An updated version of Virtual Subnet (VS) is now available at
http://tools.ietf.org/html/draft-xu-virtual-subnet-03.

Major technical changes include:
1) A section of VS vs VPLS is added.
2) A section of VS vs IPLS is added.
3) Multicast/broadcast mechanism is simplified.
4) CE host discovery mechanism is completed by adding an option of ARP
request for ALL-Systems multicast group address (i.e., 224.0.0.1).

Best wishes,
Xiaohu

VersionNotification
Xu
many