Subject: Re: [Int-area] Alternative option for IP-only L2VPN?//re: New VersionNotification for draft-xu-virtual-subnet-02

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
> 
> -----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,
> 
> 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.
> 
> [Himanshu>]
> [Himanshu>]  No.
> 
> 
> 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?
> 
> [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.

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

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

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

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

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?

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

Good news.

Best wishes,
Xiaohu

> 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: 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
IPLS.
ARP
study."
large
CE
would
switches
feature
to
in
many
to
item.
PE
IP
own
Notification
of
MAC
connected
according
extensions,
MPLS/IP