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

From: Xu Xiaohu <[email-masked]>
Date: Sun, 19 Sep 2010 17:25:28 +0800

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

Let's me clarify my doubt in more details. In IPLS, the MAC reachability
information (i.e., MAC->PW label mapping) is distributed among PEs. As long
as the packet is forwarded from the AC to the PW without stripping its MAC
header, IPLS should have been able to support non-IP traffic. What's the
historical reason for it to be limited to just support IP-only traffic? 

Best wishes,
Xiaohu

> > 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: Himanshu Shah <[email-masked]>
Date: Mon, 20 Sep 2010 05:37:22 -0700

Hi Xiaohu,

MAC<->IP association is discovered through IP/ARP means.
One can then claim the support for IP in all cases.
A host that is not doing IP, its MAC address
discovery is not covered in IPLS and hence can not claim
its support for all other (non-IP) cases (i.e. protocols).

thanks,
himanshu

On Sep 19, 2010, at 5:25 AM, Xu Xiaohu wrote:

Best wishes,
Xiaohu