Comments in line.. Thanks, himanshu
-----Original Message----- From: l2vpn-boun...@ietf.org [mailto:l2vpn-boun...@ietf.org] On Behalf Of Xu Xiaohu Sent: Friday, August 27, 2010 11:40 PM To: l2...@ietf.org Cc: int-area@ietf.org; l3...@ietf.org; rt...@ietf.org 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:x...@huawei.com] > 发送时间: 2010年8月26日 12:19 > 收件人: 'l2...@ietf.org' > 抄送: 'l3...@ietf.org'; 'rt...@ietf.org'; 'int-area@ietf.org' > 主题: 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:x...@huawei.com] > > 发送时间: 2010年8月24日 14:58 > > 收件人: 'rt...@ietf.org'; 'int-area@ietf.org' > > 抄送: 'l3...@ietf.org' > > 主题: 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:idsubmiss...@ietf.org] > > 发送时间: 2010年8月24日 12:22 > > 收件人: x...@huawei.com > > 主题: 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. _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
