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

[Xu Xiaohu <[e-mail]>]

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

> -----邮件原件-----
> 发件人: Himanshu Shah [mailto:[e-mail]]
> 发送时间: 2010年8月31日 23:34
> 收件人: Xu Xiaohu; [e-mail]
> 抄送: [e-mail]; [e-mail]; [e-mail]
> 主题: RE: Alternative option for IP-only L2VPN?//re: New
VersionNotification
> for draft-xu-virtual-subnet-02
> 
> Comments in line..
> 
> Thanks,
> himanshu
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
Xu
> Xiaohu
> Sent: Friday, August 27, 2010 11:40 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> 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.
> 
> 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.
> 
> 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).
> 
> 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.
> 
> 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:[e-mail]]
> > 发送时间: 2010年8月26日 12:19
> > 收件人: '[e-mail]'
> > 抄送: '[e-mail]'; '[e-mail]'; '[e-mail]'
> > 主题: 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:[e-mail]]
> > > 发送时间: 2010年8月24日 14:58
> > > 收件人: '[e-mail]'; '[e-mail]'
> > > 抄送: '[e-mail]'
> > > 主题: 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:[e-mail]]
> > > 发送时间: 2010年8月24日 12:22
> > > 收件人: [e-mail]
> > > 主题: 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.
>