From martin.vigoureux@alcatel-lucent.com Sat May 5 06:23:09 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A4621F852D for ; Sat, 5 May 2012 06:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Fd-fGi9SE3d for ; Sat, 5 May 2012 06:23:08 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by ietfa.amsl.com (Postfix) with ESMTP id 1752E21F8528 for ; Sat, 5 May 2012 06:23:07 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q45DN5Bp023248 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 5 May 2012 15:23:06 +0200 Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 5 May 2012 15:23:05 +0200 Received: from [135.244.20.68] (135.5.27.11) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sat, 5 May 2012 09:23:02 -0400 Message-ID: <4FA529B1.8000108@alcatel-lucent.com> Date: Sat, 5 May 2012 15:22:57 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: Subject: Adoption of draft-zzhang-mvpn-mib-00 as WG document Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.5.27.11] X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: l3vpn-chairs@tools.ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 13:23:09 -0000 Working Group, the poll has ended some weeks ago. There is good support for making draft-zzhang-mvpn-mib-00 a working group document. Could the authors resubmit the document as draft-ietf-l3vpn-mvpn-mib-00 thus without any other changes than date and filename. Thanks. Martin & Thomas From ice@cisco.com Mon May 7 02:55:43 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEB521F857A for ; Mon, 7 May 2012 02:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o980j4MHHSrl for ; Mon, 7 May 2012 02:55:42 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC3C21F8547 for ; Mon, 7 May 2012 02:55:42 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q479tfdh023297 for ; Mon, 7 May 2012 11:55:41 +0200 (CEST) Received: from ams-iwijnand-8712.cisco.com (ams-iwijnand-8712.cisco.com [10.55.191.147]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q479te10017058; Mon, 7 May 2012 11:55:41 +0200 (CEST) Subject: Re: Regarding draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: IJsbrand Wijnands In-Reply-To: <201204221331.q3MDVx122253@magenta.juniper.net> Date: Mon, 7 May 2012 11:55:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6EABF66C-AF44-49D6-AA8F-728C894ED957@cisco.com> <201204221331.q3MDVx122253@magenta.juniper.net> To: Yakov Rekhter X-Mailer: Apple Mail (2.1257) Cc: L3VPN mailing list X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 09:55:43 -0000 Yakov, Thanks for your comments; Maybe its best if we view this draft not as a 'VPN' solution, but as a = solution that uses VRF's to implement a service. As I tried to explain before, this is not a solution that is meant to = offer as a generic VPN service to end customers, but a solution used by = a provider to internally partition services using VRF's. Maybe my statement that this solution is to be used in a VPN environment = was wrong and caused confusion. =46rom the providers deployment POV, = this is not an end customer VPN service. The MVPN procedures you reference below just don't apply to this draft. Thx, Ice. On 22 Apr 2012, at 15:31, Yakov Rekhter wrote: > Ice, >=20 >> Dear L3VPN, >>=20 >> We presented draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 to >> the MPLS WG last IETF in Taipei and received a comment that this >> should be discussed in L3 VPN. As it looks there is not going to >> be a L3VPN meeting in Paris, for that reason I'm sending out this >> email to solicit input on this draft. >>=20 >> This draft describes a solution to be used in a VPN environment, >> but it is no t intended to be used as a generic solution for = Multicast >> VPNs. It is for specific deployments where traffic is bundled in >> 'service' VPNs within a Providers n etwork, following similar >> procedures and rationale as described in draft-ietf-m >> pls-mldp-in-band-signaling-05. These VPNs are not generic customer >> VPNs, but used to transport content such as IPTV or financial data >> through a Providers network. >>=20 >> The basic idea is that the ingress PE's VRF RD is added to the mLDP >> FEC opaque encoding to make it unique and VPN specific. This follows >> the same model as described in draft-ietf-mpls-mldp-recurs-fec-04 >> section 3. We had a similar discussion regarding the use of the >> RD in the opaque encoding and decided to accept it as WG document >> in the MPLS WG. >>=20 >> Some may say this solution does not follow the multicast procedures >> as documented in draft-ietf-l3vpn-2547bis-mcast-10, and for that >> reason should not be allowed. >>=20 >> However, >>=20 >> 1. This is not any different from draft-ietf-mpls-mldp-recurs-fec-04=20= >> section 3. >> 2. This draft is driven by customer interest. >> 3. This solution relies on existing IP-VPN BGP procedures without=20 >> additional extensions. >>=20 >> For that reason we like to see=20 >> draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 progress as=20 >> WG document in the MPLS WG. >>=20 >> We welcome your feedback, >>=20 >=20 > As you asked for feedback, here are few commends on the draft: >=20 > 1. The following should be added to Abstract and Introduction: >=20 > Procedures specified in this draft are not compatible with > the standard MVPN procedures, as specified in [RFC6513, RFC6514]. > Thus, a PE router that implements procedures specified in > this draft would not be able to interoperate with a PE > router that implements the standard MVPN procedures. >=20 >=20 > 2. =46rom the draft: >=20 > For a variety of > reasons (discussed in [I-D.ietf-l3vpn-2547bis-mcast]), this is not a > suitable for a general purpose multicast VPN solution. =20 >=20 > The above is a bit confusing/misleading. The reason why this solution > is not suitable for a general purpose multicast VPN solution is > that it does not meet some of the mandatory requirements for=20 > multicast VPN solution, as stated in rfc4834. With this in mind > I would like the authors to replace the above with the following: >=20 > The solution described in this draft is not suitable for a general > purpose multicast VPN solution, as it does not meet multiple > mandatory requirements for multicast VPNs specified in [rfc4834], > such as (a) scalability, (b) support for MVPN customers running ASM,=20= > (c) support for extranets, (d) support for tunneling technologies > other than mLDP, etc.. >=20 > 3. =46rom the draft: >=20 > But the procedures described herein are much simpler than the=20 > general purpose MVPN procedures,=20 >=20 > This is just a matter of opinion, and as such should be removed > from the draft. >=20 > 4. =46rom the draft: >=20 > Due to the 1-1 mapping and the multicast source and group = information > being encoded in the mLDP FEC, there is deterministic mapping beween > the multicast tree and the mLDP LSP in the core network. This > improves and simplifies fault resolution. >=20 > There is nothing in the general purpose MVPN procedures that > would prevent the same. Thus the same fault resolution could > be done with the general purpose MVPN procedures. With > this in mind I propose either (a) to delete the above text, or > (b) keep the above text, and add the following to the above text: >=20 > The same fault resolution could be accomplished with the > general purpose MVPN procedures. >=20 > 5. =46rom the draft: >=20 > In order to use the mLDP in-band signaling procedures for a > particular group address in a particular VPN, the Provider Edge (PE) > routers that attach to that VPN MUST be configured with a range of > multicast group addresses for which mLDP in-band signaling is to be > enabled. This configuration is per VRF ("Virtual Routing and > Forwarding table", defined in [RFC4364]). For those groups, and > those groups only, the procedures of this document are used instead > of the general purpose Multicast VPN procedures. This configuration > must be present in all PE routers that attach to sites containing > senders or receivers for the given set of group addresses. >=20 > First of all, the document should spell out that configuring on a > PE "a range of multicast group addresses for which mLDP in-band > signaling is to be enabled" requires coordination between a > customer and a service provider. >=20 > Second, the document needs spell out the procedures for groups that > are not in this range. E.g., should traffic to these groups be > discarded ? Should this traffic be handled using standard MVPN > procedures ? Something else ? >=20 > 6. As I said before, this draft, as you said above, "describes a > solution to be used in a VPN environment". Thus it is outside the > scope of the MPLS WG (as VPN is outside the charter of that WG). >=20 > If the authors want to progress this draft as a WG document, then > they should ask L3VPN WG to progress it as an L3VPN WG document (as > VPN is within the charter of that WG). >=20 > Yakov. >=20 From pedro.r.marques@gmail.com Mon May 7 14:47:22 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3862C21F870B for ; Mon, 7 May 2012 14:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.844 X-Spam-Level: X-Spam-Status: No, score=-0.844 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFrheKm2oAhK for ; Mon, 7 May 2012 14:47:21 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 91DA421F86F1 for ; Mon, 7 May 2012 14:47:21 -0700 (PDT) Received: by dadv36 with SMTP id v36so1761938dad.27 for ; Mon, 07 May 2012 14:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:references:to:message-id :mime-version:x-mailer; bh=4DHhpjc1VTdZTBWzcCqHNJyHGkFJtBq+U9fMol+0hs0=; b=WS32Xz18+Xkhk76ePuvPBRt1uxq4m+vf07Z4SPssIvb0QwLu85n8Z1Xvd6oyVzGz8o ayzU86+KmyXZeLmBEy0M/b+W0gZ1opt5ETxeifzyer/qq1ltqpvy50X8KjXN3Ngpt6b8 pqynbg5Zgo5+hcbRVZnENKLc2DdOXhHdCTd1fTVn4wxIjN9ljGsgZiR1tgqC5Iu1U/hs 5ss9D3JMBY3Ncga7CB1TWhYnQzLHAkEFCo+vEaDThgcEyKABBxoUPhA9jmE90wp20rNw oGS1HaXIdpu8835wDjrqEuaiEhoW6lul/GLQbsrTsM5V5CWjGMNjwhh/1qoS+4v1og2a whBQ== Received: by 10.68.218.163 with SMTP id ph3mr453805pbc.6.1336426816315; Mon, 07 May 2012 14:40:16 -0700 (PDT) Received: from [192.168.1.111] ([67.21.1.106]) by mx.google.com with ESMTPS id h10sm19426149pbh.69.2012.05.07.14.40.14 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 May 2012 14:40:14 -0700 (PDT) From: Pedro Roque Marques Content-Type: multipart/alternative; boundary="Apple-Mail=_FC448A5B-813B-4D2A-AF3D-96C370FED94E" Subject: New Version Notification for draft-marques-l3vpn-mcast-edge-00.txt Date: Mon, 7 May 2012 14:40:22 -0700 References: <20120507212659.4792.86315.idtracker@ietfa.amsl.com> To: l3vpn@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 21:47:22 -0000 --Apple-Mail=_FC448A5B-813B-4D2A-AF3D-96C370FED94E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear L3VPN WG, Myself and my co-authors would appreciate any comments and suggestions = you may have on the document bellow. thank you, Pedro. Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-marques-l3vpn-mcast-edge-00.txt > Date: May 7, 2012 2:26:59 PM PDT > To: roque@contrailsystems.com > Cc: yiqunc@microsoft.com, derick.winkworth@fisglobal.com, = lufang@cisco.com >=20 > A new version of I-D, draft-marques-l3vpn-mcast-edge-00.txt has been = successfully submitted by Pedro Marques and posted to the IETF = repository. >=20 > Filename: draft-marques-l3vpn-mcast-edge > Revision: 00 > Title: Edge multicast replication for BGP IP VPNs. > Creation date: 2012-05-07 > WG ID: Individual Submission > Number of pages: 14 >=20 > Abstract: > In data-center networks it is common to use Clos network topologies > [clos] in order to provide a non-blocking switched network. In = these > topologies it is often not desirable to provide native IP multicast > service. >=20 > This document defines a multicast replication algorithm along with > its control and data forwarding procedures that provides a multicast > service for a BGP IP VPN network without assuming that the = underlying > infrastructure supports IP multicast. >=20 >=20 >=20 >=20 > The IETF Secretariat --Apple-Mail=_FC448A5B-813B-4D2A-AF3D-96C370FED94E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = L3VPN WG,
Myself and my co-authors would appreciate any comments and = suggestions you may have on the document = bellow.

thank you,
  = Pedro.

Begin forwarded message:

Subject: New Version Notification for = draft-marques-l3vpn-mcast-edge-00.txt
Date: May 7, 2012 2:26:59 = PM PDT

=
A new version of I-D, draft-marques-l3vpn-mcast-edge-00.txt has = been successfully submitted by Pedro Marques and posted to the IETF = repository.

Filename: = draft-marques-l3vpn-mcast-edge
Revision: 00
Title: Edge = multicast replication for BGP IP VPNs.
Creation date: = 2012-05-07
WG ID: Individual Submission
Number = of pages: 14

Abstract:
  In data-center networks it = is common to use Clos network topologies
  [clos] in order = to provide a non-blocking switched network.  In these
=   topologies it is often not desirable to provide native IP = multicast
  service.

  This document = defines a multicast replication algorithm along with
  its = control and data forwarding procedures that provides a multicast
=   service for a BGP IP VPN network without assuming that the = underlying
  infrastructure supports IP = multicast.




The IETF = Secretariat

= --Apple-Mail=_FC448A5B-813B-4D2A-AF3D-96C370FED94E-- From xuxiaohu@huawei.com Mon May 7 20:21:57 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59CE721F84F8; Mon, 7 May 2012 20:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[AWL=1.450, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddT4F0qlYrle; Mon, 7 May 2012 20:21:56 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A541A21F84CD; Mon, 7 May 2012 20:21:56 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFP49141; Mon, 07 May 2012 23:21:53 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 7 May 2012 20:20:37 -0700 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 7 May 2012 20:20:39 -0700 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.182]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Tue, 8 May 2012 11:20:36 +0800 From: Xuxiaohu To: "l2vpn@ietf.org" , "l3vpn@ietf.org" , "nvo3@ietf.org" Subject: Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Thread-Topic: Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Thread-Index: AQHNJOUqEV0uAsQuJk6ASHAvdqt8upavh4QAgA+/yUA= Date: Tue, 8 May 2012 03:20:36 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F20BF9@szxeml525-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.99] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 03:21:57 -0000 SGkgYWxsLA0KDQpUaGlzIHRvcGljIG1heSBiZSBpbnRlcmVzdGluZyB0byBMMlZQTiwgTDNWUE4g YW5kIGV2ZW4gTlZvMyBmb2xrcy4gDQoNCkFueSBjb21tZW50cyBhcmUgd2VsY29tZS4NCg0KQmVz dCByZWdhcmRzLA0KWGlhb2h1LyBNYXJzaGFsbC9MdWN5DQoNCj4gLS0tLS3pgq7ku7bljp/ku7Yt LS0tLQ0KPiDlj5Hku7bkuro6IFh1eGlhb2h1DQo+IOWPkemAgeaXtumXtDogMjAxMuW5tDTmnIgy OOaXpSAxMDo1NQ0KPiDmlLbku7bkuro6ICdtcGxzQGlldGYub3JnJw0KPiDmioTpgIE6ICdtYXJz aGFsbC5ldWJhbmtzQGdtYWlsLmNvbSc7IEx1Y3kgeW9uZw0KPiDkuLvpopg6IGZ3ZDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC14dS1tcGxzLWluLXVkcC0wMC50eHQNCj4gDQo+ IEhpIGFsbCwNCj4gDQo+IEVxdWFsIENvc3QgTXVsdGktUGF0aCAoRUNNUCkgYW5kIExpbmsgQWdn cmVnYXRpb24gR3JvdXAgKExBRykgYXJlIHdpZGVseSB1c2VkDQo+IGluIHRoZSBjb3JlIG9mIElQ LWVuYWJsZWQgUGFja2V0IFN3aXRjaCBOZXR3b3JrcyAoUFNOKSBmb3IgbG9hZC1iYWxhbmNpbmcN Cj4gcHVycG9zZXMuIE1vc3QgY29yZSByb3V0ZXJzIChpLmUuLCBQIHJvdXRlcnMpIGluIHRoZSBJ UC1lbmFibGVkIFBTTiBhcmUgY2FwYWJsZSBvZg0KPiBsb2FkLWJhbGFuY2luZyBJUCB0cmFmZmlj IGZsb3dzIGFjcm9zcyBFQ01QIHBhdGhzIGFuZC9vciBMQUcgYmFzZWQgb24gdGhlIGhhc2gNCj4g b2YgdGhlIGZpdmUtdHVwbGUgb2YgICBVRFAvVENQIHBhY2tldHMgKGkuZS4sIHNvdXJjZSBJUCBh ZGRyZXNzLCBkZXN0aW5hdGlvbiBJUA0KPiBhZGRyZXNzLCBzb3VyY2UgcG9ydCwgZGVzdGluYXRp b24gcG9ydCwgYW5kIHByb3RvY29sKSBvciBzb21lIGZpZWxkcyBpbiB0aGUgSVANCj4gaGVhZGVy IG9mIG5vbi1VRFAvVENQIHBhY2tldHMgKGUuZy4sIHNvdXJjZSBJUCBhZGRyZXNzLCBkZXN0aW5h dGlvbiBJUCBhZGRyZXNzKS4NCj4gDQo+IEhvd2V2ZXIsIHdpdGggZXhpc3RpbmcgSVAtYmFzZWQg ZW5jYXBzdWxhdGlvbiBtZXRob2RzIGFzIGRlZmluZWQgaW4gW1JGQzQwMjNdDQo+IHN1Y2ggYXMg TVBMUy1pbi1JUCBhbmQgTVBMUy1pbi1HUkUsIGRpc3RpbmN0IGN1c3RvbWVyIHRyYWZmaWMgZmxv d3Mgb2YgdmFyaW91cw0KPiBNUExTIGFwcGxpY2F0aW9ucyAoZS5nLiwgTVBMUy1iYXNlZCBMMlZQ TiBvciBMM1ZQTikgYmV0d2VlbiBhIGdpdmVuIFBFIHBhaXINCj4gd291bGQgYmUgZW5jYXBzdWxh dGVkIHdpdGggdGhlIHNhbWUgSVAgb3IgR1JFIHR1bm5lbCBoZWFkZXIgcHJpb3IgdG8gdHJhdmVy c2luZw0KPiB0aGUgY29yZS4gU2luY2UgdGhlIGVuY2Fwc3VsYXRpbmcgdHJhZmZpYyBpcyBuZWl0 aGVyIFRDUCBub3IgVURQIHRyYWZmaWMsIGNvcmUNCj4gcm91dGVycyBjb3VsZCBvbmx5IHBlcmZv cm0gaGFzaCBjYWxjdWxhdGlvbiBvbiB0aGUgZmllbGRzIGluIHRoZSBJUCBoZWFkZXIgb2YgSVAg b3INCj4gR1JFIHR1bm5lbHMuIEFzIGEgcmVzdWx0LCBjb3JlIHJvdXRlcnMgY291bGQgbm90IGFj aGlldmUgYW4gZWZmZWN0aXZlDQo+IGxvYWQtYmFsYW5jaW5nIGZvciB0aGVzZSB0cmFmZmljIGZs b3dzIGluIHRoZSBuZXR3b3JrIGR1ZSB0byB0aGUgbGFjayBvZiBhZGVxdWF0ZQ0KPiBlbnRyb3B5 IGluZm9ybWF0aW9uLg0KPiANCj4gVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgb25lIGFkZGl0aW9u YWwgSVAtYmFzZWQgZW5jYXBzdWxhdGlvbiB0ZWNobm9sb2d5IGZvcg0KPiBNUExTIHBhY2tldHMg cmVmZXJyZWQgdG8gYXMgTVBMUy1pbi1VRFAsIHdoaWNoIGlzIGludGVuZGVkIHRvIGZhY2lsaXRh dGUNCj4gbG9hZC1iYWxhbmNpbmcgdGhlIHRyYWZmaWMgb2YgdmFyaW91cyBNUExTIGFwcGxpY2F0 aW9ucyBzdWNoIGFzIE1QTFMtYmFzZWQgTDJWUE4NCj4gYW5kIEwzVlBOIGluIHRoZSBjb3JlIG9m IElQLWVuYWJsZWQgUFNOLg0KPiANCj4gQW55IGNvbW1lbnRzIGFyZSB3ZWxjb21lLg0KPiANCj4g QmVzdCByZWdhcmRzLA0KPiBYaWFvaHUNCj4gDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g 5Y+R5Lu25Lq6OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmddDQo+IOWPkemAgeaXtumXtDogMjAxMuW5tDTmnIgyOOaXpSAxMDoxOA0KPiDm lLbku7bkuro6IFh1eGlhb2h1DQo+IOaKhOmAgTogTHVjeSB5b25nOyBtYXJzaGFsbC5ldWJhbmtz QGdtYWlsLmNvbQ0KPiDkuLvpopg6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt eHUtbXBscy1pbi11ZHAtMDAudHh0DQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt eHUtbXBscy1pbi11ZHAtMDAudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseQ0KPiBzdWJtaXR0ZWQg YnkgWGlhb2h1IFh1IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IEZp bGVuYW1lOgkgZHJhZnQteHUtbXBscy1pbi11ZHANCj4gUmV2aXNpb246CSAwMA0KPiBUaXRsZToJ CSBFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQDQo+IENyZWF0aW9uIGRhdGU6CSAyMDEyLTA0LTI4 DQo+IFdHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBOdW1iZXIgb2YgcGFnZXM6IDcN Cj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBvbmUgYWRkaXRp b25hbCBJUC1iYXNlZCBlbmNhcHN1bGF0aW9uDQo+ICAgIHRlY2hub2xvZ3kgZm9yIE1QTFMgcGFj a2V0cyByZWZlcnJlZCB0byBhcyBNUExTLWluLVVEUCwgd2hpY2ggaXMNCj4gICAgaW50ZW5kZWQg dG8gZmFjaWxpdGF0ZSBsb2FkLWJhbGFuY2luZyB0aGUgdHJhZmZpYyBvZiB2YXJpb3VzIE1QTFMN Cj4gICAgYXBwbGljYXRpb25zIHN1Y2ggYXMgTVBMUy1iYXNlZCBMMlZQTiBhbmQgTDNWUE4gaW4g dGhlIGNvcmUgb2YgSVAtDQo+ICAgIGVuYWJsZWQgcGFja2V0IHN3aXRjaCBuZXR3b3Jrcy4NCj4g DQo+IA0KPiANCj4gDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0K From robert@raszuk.net Wed May 9 00:26:43 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2B221F85C4 for ; Wed, 9 May 2012 00:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsrqyXYdH-iD for ; Wed, 9 May 2012 00:26:42 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 37FC021F847C for ; Wed, 9 May 2012 00:26:42 -0700 (PDT) Received: (qmail 8435 invoked by uid 399); 9 May 2012 07:26:41 -0000 Received: from unknown (HELO ?192.168.1.58?) (pbs:m42@mojaklasa.info@178.43.237.61) by mail1310.opentransfer.com with ESMTPM; 9 May 2012 07:26:41 -0000 X-Originating-IP: 178.43.237.61 Message-ID: <4FAA1C30.6090303@raszuk.net> Date: Wed, 09 May 2012 09:26:40 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: keshavaak@huawei.com Subject: Re: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F20BF9@szxeml525-mbs.china.huawei.com> <005a01cd2d9e$900f0ac0$b02d2040$@com> In-Reply-To: <005a01cd2d9e$900f0ac0$b02d2040$@com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, nvo3@ietf.org, l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 07:26:43 -0000 > If switches were to try to distribute GRE flows between two VTEPs > that used a GRE encapsulation, all the traffic would be directed to > use only one link within these Port Channels. Not true. GRE encapsulation is not mandated to use the same src/dst addresses for all flows between given two end points. You do not need to parse deep into packet to enable good load balancing hash across parallel links when you use GRE as an encapsulation technology. And what is nice about IP encapsulation all GRE src/dst addresses can be naturally aggregated so from IGP point of view they still look like a single prefix. Regards, R. From stbryant@cisco.com Wed May 9 02:53:38 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D4D21F85C7; Wed, 9 May 2012 02:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.496 X-Spam-Level: X-Spam-Status: No, score=-110.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7chbzw0dWQg; Wed, 9 May 2012 02:53:37 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1151621F85C6; Wed, 9 May 2012 02:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=1044; q=dns/txt; s=iport; t=1336557217; x=1337766817; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=RySI63kL+6vvAvYlVrjxgjC37AIHAkxRWCAgYf0ysgM=; b=iVMxlGlSVESd4GsLdLRTA9zAQjLw/b08f9mJnLcO7QxU/8t0TA8dvnei msObWRlYVjNrM5z1eA8PgzdDdjHj9bqw/A7NdegJjlSiGaIElwpW+gcPI T8YbHj+uqngH6tP839FBhfcy3NyJdh4fEg8RrYm0zGY0LeQRCgEn4JzaD g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAD89qk+Q/khL/2dsb2JhbABEr3ODW4EHggwBAQEEEgECIz8BARALGAkWBAsJAwIBAgFFEwEHAQEeh2ybIINFEJxYiwyCbIMmBJV9jliBAmeCag X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="137418558" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 09 May 2012 09:53:36 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q499rXvL005956; Wed, 9 May 2012 09:53:36 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q499rUpk002845; Wed, 9 May 2012 10:53:30 +0100 (BST) Message-ID: <4FAA3E9A.7050602@cisco.com> Date: Wed, 09 May 2012 10:53:30 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: robert@raszuk.net Subject: Re: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F20BF9@szxeml525-mbs.china.huawei.com> <005a01cd2d9e$900f0ac0$b02d2040$@com> <4FAA1C30.6090303@raszuk.net> In-Reply-To: <4FAA1C30.6090303@raszuk.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, keshavaak@huawei.com, nvo3@ietf.org, l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 09:53:38 -0000 On 09/05/2012 08:26, Robert Raszuk wrote: > >> If switches were to try to distribute GRE flows between two VTEPs >> that used a GRE encapsulation, all the traffic would be directed to >> use only one link within these Port Channels. > > Not true. GRE encapsulation is not mandated to use the same src/dst > addresses for all flows between given two end points. > > You do not need to parse deep into packet to enable good load > balancing hash across parallel links when you use GRE as an > encapsulation technology. > > And what is nice about IP encapsulation all GRE src/dst addresses can > be naturally aggregated so from IGP point of view they still look like > a single prefix. > > Regards, > R. Robert I think that this needs some serious study rather than assertion, because it is not at all obvious what the LB properties of either method will be in a DC. In the case of the use of multiple GRE addresses there are operational and route scaling issues that also need to be considered. Stewart From robert@raszuk.net Wed May 9 04:01:27 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA7821F85B5 for ; Wed, 9 May 2012 04:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.743, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBCnKSogAOsm for ; Wed, 9 May 2012 04:01:26 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 608E421F8535 for ; Wed, 9 May 2012 04:01:26 -0700 (PDT) Received: (qmail 31241 invoked by uid 399); 9 May 2012 11:01:25 -0000 Received: from unknown (HELO ?192.168.1.91?) (pbs:robert@raszuk.net@83.31.229.80) by mail1310.opentransfer.com with ESMTPM; 9 May 2012 11:01:25 -0000 X-Originating-IP: 83.31.229.80 Message-ID: <4FAA4E84.4090803@raszuk.net> Date: Wed, 09 May 2012 13:01:24 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ivan Pepelnjak Subject: Re: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F20BF9@szxeml525-mbs.china.huawei.com> <005a01cd2d9e$900f0ac0$b02d2040$@com> <4FAA1C30.6090303@raszuk.net> <00fe01cd2dca$85427060$8fc75120$@com> In-Reply-To: <00fe01cd2dca$85427060$8fc75120$@com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, keshavaak@huawei.com, nvo3@ietf.org, l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 11:01:27 -0000 Hi Ivan, > True, but then you need a mechanism to discover all the available > endpoints, whereas with single VTEP per host you can use existing > mechanisms (either learning from source IP address or next-hop > distribution with BGP-like protocols). True. I see few options: - Signal different next hops in BGP for the application which runs across - Treat next hop in BGP as prefix indicator not as host route. In particular next hop resolves in IGP to a prefix which in turn could be used as set of GRE destination addresses - Signal such range explicitly. I think there will be a draft coming up on just that soon. > True, but many existing DC switches that do IP-based load balancing > have no problems load-balancing on UDP 5-tuple. I am positive > there's equipment out there that can do load balancing on GRE keys > (or some other part of GRE header), I just haven't encountered it yet > (or realized it does that), so please fix my ignorance. Indeed. In that case we have nothing to worry about. I think this thread was just about the case where the above does not apply. In fact if we all agree that devices can build hash looking deeper and that those which can not are just a corner case that would be great. Problem solved :) >> And what is nice about IP encapsulation all GRE src/dst addresses >> can be naturally aggregated so from IGP point of view they still >> look like a single prefix. > > ... and you need a new endpoint prefix (or set-of-addresses) > discovery mechanism. I don't need nothing on top on what I need today. I need to advertise reachability to end point prefix anyway. The difference is that I advertise for example /28 rather then /32. Hi Stewart, > I think that this needs some serious study rather than assertion, > because it is not at all obvious what the LB properties of either > method will be in a DC. The claim was much more general and my reply did not actually narrowed it to DC env. I was more talking about WAN. > In the case of the use of multiple GRE addresses there are > operational and route scaling issues that also need to be considered. I do not see any. Smart networking OS of ingress and egress point can do such encapsulation without any operational overhead. Please think in terms of mGRE. Route scaling issues do not apply. You do not need to inject more then one prefix in any case. Regards, R. From Internet-Drafts@ietf.org Thu May 10 13:13:51 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B0021F86E1; Thu, 10 May 2012 13:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZehEYU3hbzWQ; Thu, 10 May 2012 13:13:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E65A21F86DC; Thu, 10 May 2012 13:13:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-mvpn-mib-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120510201351.28302.44508.idtracker@ietfa.amsl.com> Date: Thu, 10 May 2012 13:13:51 -0700 Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 20:13:52 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF. Title : MPLS/BGP Layer 3 VPN Multicast Management Information Base Author(s) : Filename : draft-ietf-l3vpn-mvpn-mib Pages : 31 Date : May 10, 2012 This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor multicast in MPLS/BGP-based Layer-3 VPN (MVPN) on an MVPN router. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-mvpn-mib-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-l3vpn-mvpn-mib"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2012-05-10131351.I-D@ietf.org> --NextPart-- From xuxiaohu@huawei.com Fri May 11 01:59:58 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F1B21F85A8; Fri, 11 May 2012 01:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.837 X-Spam-Level: X-Spam-Status: No, score=-0.837 tagged_above=-999 required=5 tests=[AWL=1.762, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+0tAG6ZrZ4z; Fri, 11 May 2012 01:59:56 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id F13B421F85A2; Fri, 11 May 2012 01:59:55 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGC05597; Fri, 11 May 2012 04:59:55 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 11 May 2012 01:56:25 -0700 Received: from SZXEML439-HUB.china.huawei.com (10.72.61.74) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 11 May 2012 01:56:31 -0700 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.182]) by szxeml439-hub.china.huawei.com ([10.72.61.74]) with mapi id 14.01.0323.003; Fri, 11 May 2012 16:56:20 +0800 From: Xuxiaohu To: "robert@raszuk.net" , Ivan Pepelnjak Subject: re: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Thread-Topic: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Thread-Index: AQHNLdMWxh0NIaZEh0eGnDDg3V8uUpbESnjw Date: Fri, 11 May 2012 08:56:19 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F215E6@szxeml525-mbs.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F20BF9@szxeml525-mbs.china.huawei.com> <005a01cd2d9e$900f0ac0$b02d2040$@com> <4FAA1C30.6090303@raszuk.net> <00fe01cd2dca$85427060$8fc75120$@com> <4FAA4E84.4090803@raszuk.net> In-Reply-To: <4FAA4E84.4090803@raszuk.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.99] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" , Keshava A K , "nvo3@ietf.org" , "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 08:59:58 -0000 DQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBSb2JlcnQgUmFzenVrIFtt YWlsdG86cm9iZXJ0QHJhc3p1ay5uZXRdDQo+IOWPkemAgeaXtumXtDogMjAxMuW5tDXmnIg55pel IDE5OjAxDQo+IOaUtuS7tuS6ujogSXZhbiBQZXBlbG5qYWsNCj4g5oqE6YCBOiBLZXNoYXZhIEEg SzsgbDJ2cG5AaWV0Zi5vcmc7IFh1eGlhb2h1OyBudm8zQGlldGYub3JnOyBsM3ZwbkBpZXRmLm9y Zw0KPiDkuLvpopg6IFJlOiBbbnZvM10gRmFjaWxpdGF0aW5nIHRoZSBsb2FkLWJhbGFuY2luZyBv ZiBMMlZQTi9MM1ZQTiB0cmFmZmljIG92ZXIgSVANCj4gUFNOIHVzaW5nIE1QTFMtaW4tVURQIGVu Y2Fwc3VsYXRpb24vLyBmd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gZHJhZnQt eHUtbXBscy1pbi11ZHAtMDAudHh0DQo+IA0KPiBIaSBJdmFuLA0KPiANCj4gPiBUcnVlLCBidXQg dGhlbiB5b3UgbmVlZCBhIG1lY2hhbmlzbSB0byBkaXNjb3ZlciBhbGwgdGhlIGF2YWlsYWJsZQ0K PiA+IGVuZHBvaW50cywgd2hlcmVhcyB3aXRoIHNpbmdsZSBWVEVQIHBlciBob3N0IHlvdSBjYW4g dXNlIGV4aXN0aW5nDQo+ID4gbWVjaGFuaXNtcyAoZWl0aGVyIGxlYXJuaW5nIGZyb20gc291cmNl IElQIGFkZHJlc3Mgb3IgbmV4dC1ob3ANCj4gPiBkaXN0cmlidXRpb24gd2l0aCBCR1AtbGlrZSBw cm90b2NvbHMpLg0KPiANCj4gVHJ1ZS4NCj4gDQo+IEkgc2VlIGZldyBvcHRpb25zOg0KPiANCj4g LSBTaWduYWwgZGlmZmVyZW50IG5leHQgaG9wcyBpbiBCR1AgZm9yIHRoZSBhcHBsaWNhdGlvbiB3 aGljaCBydW5zIGFjcm9zcw0KPiANCj4gLSBUcmVhdCBuZXh0IGhvcCBpbiBCR1AgYXMgcHJlZml4 IGluZGljYXRvciBub3QgYXMgaG9zdCByb3V0ZS4gSW4NCj4gcGFydGljdWxhciBuZXh0IGhvcCBy ZXNvbHZlcyBpbiBJR1AgdG8gYSBwcmVmaXggd2hpY2ggaW4gdHVybiBjb3VsZCBiZQ0KPiB1c2Vk IGFzIHNldCBvZiBHUkUgZGVzdGluYXRpb24gYWRkcmVzc2VzDQo+IA0KPiAtIFNpZ25hbCBzdWNo IHJhbmdlIGV4cGxpY2l0bHkuIEkgdGhpbmsgdGhlcmUgd2lsbCBiZSBhIGRyYWZ0IGNvbWluZyB1 cA0KPiBvbiBqdXN0IHRoYXQgc29vbi4NCg0KSGkgYWxsLA0KDQpUaGUgZHJhZnQgdGhhdCBSb2Jl cnQgbWVudGlvbmVkIGlzIG5vdyBhdmFpbGFibGUgYXQgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQteHUtaWRyLXR1bm5lbC1hZGRyZXNzLXByZWZpeC0wMC4gIEFueSBjb21tZW50cyBh bmQgc3VnZ2VzdGlvbnMgYXJlIHdlbGNvbWUuDQoNCkJUVywgdGhhbmtzIFJvYmVydCBmb3IgeW91 ciBwcmUtYW5ub3VuY2VtZW50IG9mIHRoaXMgZHJhZnQgOykNCg0KQmVzdCByZWdhcmRzLA0KWGlh b2h1DQoNCg0K From linda.dunbar@huawei.com Tue May 15 12:42:12 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7491411E8087; Tue, 15 May 2012 12:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.396, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSgbhejPeo7R; Tue, 15 May 2012 12:42:12 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id BDB1811E8089; Tue, 15 May 2012 12:42:11 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGF36179; Tue, 15 May 2012 15:42:11 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 15 May 2012 12:40:37 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Tue, 15 May 2012 12:40:35 -0700 From: Linda Dunbar To: "robert@raszuk.net" , Keshava A K Subject: RE: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Thread-Topic: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Thread-Index: AQHNLbX6Q4MUsqOU70u/fPXTAOg5TZbLSJFA Date: Tue, 15 May 2012 19:40:34 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F633931E2C@dfweml506-mbx> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F20BF9@szxeml525-mbs.china.huawei.com> <005a01cd2d9e$900f0ac0$b02d2040$@com> <4FAA1C30.6090303@raszuk.net> In-Reply-To: <4FAA1C30.6090303@raszuk.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.156] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" , "nvo3@ietf.org" , "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 19:42:12 -0000 Robert,=20 When GRE encapsulation uses different SRC/DST addresses for different flows= , it means that same OverlayBoundaryPoint needs multiple addresses. Does it= also mean an IP prefix can be given to a OverlayBoundaryPoint? I guess for= IPv6, there shouldn't be any issues, should it? (well I am not an IPv6 exp= ert).=20 Linda > -----Original Message----- > From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of > Robert Raszuk > Sent: Wednesday, May 09, 2012 2:27 AM > To: Keshava A K > Cc: l2vpn@ietf.org; Xuxiaohu; nvo3@ietf.org; l3vpn@ietf.org > Subject: Re: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN > traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version > Notification for draft-xu-mpls-in-udp-00.txt >=20 >=20 > > If switches were to try to distribute GRE flows between two VTEPs > > that used a GRE encapsulation, all the traffic would be directed to > > use only one link within these Port Channels. >=20 > Not true. GRE encapsulation is not mandated to use the same src/dst > addresses for all flows between given two end points. >=20 > You do not need to parse deep into packet to enable good load balancing > hash across parallel links when you use GRE as an encapsulation > technology. >=20 > And what is nice about IP encapsulation all GRE src/dst addresses can > be > naturally aggregated so from IGP point of view they still look like a > single prefix. >=20 > Regards, > R. > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From linda.dunbar@huawei.com Wed May 16 15:29:59 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752EA11E8080; Wed, 16 May 2012 15:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.402 X-Spam-Level: X-Spam-Status: No, score=-4.402 tagged_above=-999 required=5 tests=[AWL=2.197, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ezjMRyz5r5h; Wed, 16 May 2012 15:29:58 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 66D4D11E8072; Wed, 16 May 2012 15:29:58 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFZ41883; Wed, 16 May 2012 18:29:58 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 16 May 2012 15:26:40 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Wed, 16 May 2012 15:26:37 -0700 From: Linda Dunbar To: AshwoodsmithPeter , Murari Sridharan , "robert@raszuk.net" , Keshava A K Subject: RE: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Thread-Topic: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Thread-Index: AQHNMt2t4REqtqrRU0qCXQhYIdzhqZbM/g0g Date: Wed, 16 May 2012 22:26:36 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F633933704@dfweml506-mbx> References: <7AE6A4247B044C4ABE0A5B6BF427F8E2012DE3C3@dfweml513-mbx.china.huawei.com> In-Reply-To: <7AE6A4247B044C4ABE0A5B6BF427F8E2012DE3C3@dfweml513-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.156] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" , "nvo3@ietf.org" , "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 22:29:59 -0000 Peter,=20 You are absolutely right. I am saying the same thing, i.e. the OverlayBouna= ryPoint has multiple addresses. So that some VMs can be encapsulated in one= SR/DST address and other VMs can be encapsulated with other addresses.=20 I agree with Murari that focusing on entropy values is too narrow. You can = have all the entropy values, but you still will run into in-balanced distri= bution because flow of each VM is different.=20 =20 I have noticed that VMware (in their document) and Microsoft tend to use "h= ost" to indicate "Server" which can support multiple VMs. V.s. in other env= ironment "Host" is referring to "End-Station".=20 Linda > -----Original Message----- > From: AshwoodsmithPeter > Sent: Tuesday, May 15, 2012 4:00 PM > To: Murari Sridharan; Linda Dunbar; robert@raszuk.net; Keshava A K > Cc: l2vpn@ietf.org; nvo3@ietf.org; l3vpn@ietf.org > Subject: RE: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN > traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version > Notification for draft-xu-mpls-in-udp-00.txt >=20 >=20 > Linda, just to clarify, its not the ultimate host addresses (VM) that > need to be multiple, it's the Hyperisor/Vswitch that needs multiple IP > addresses. The hash is on this *outer* IP address and is of course > limited because there are insufficient outer addresses for good entropy. >=20 > You'd use a single IP address for the VM/host but then when > encapsulating you'd pick one of say 32 or more Vswitch addresses for > your SA based on your VM IPs and the UDP/TCP ports. Everywhere there > was a dependency on /32 would have to be made flexible. Not sure if > that's an issue but its possibly hard coded in some places. Routers ARP > table for example? >=20 > The number of outer addresses you use dictates how much entropy you get > when you traverse a LAG which can have quite a few members, but 16 or > 32 is likely not unreasonable. Also if you go through several hops, the > number of bits of entropy puts a strict upper bound on the total number > of different paths you can exercise. So if you have 4 bits you can only > exercise 16 unique paths *end to end*. Since the number of paths grows > exponentially in the path length a small number of bits does limit > spead exponentially quickly. >=20 > This 'trick' is only needed of course if the LAG or ECMP hardware does > not know to look at an NVGRE header or is not capable of generic hash > extensions which some ASICs now can do... (even if they don't support > NVGRE termination/encapsulation) so its likely more a concern between > DC's than inside the DC. >=20 > Peter >=20 > -----Original Message----- > From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of > Murari Sridharan > Sent: Tuesday, May 15, 2012 4:29 PM > To: Murari Sridharan; Linda Dunbar; robert@raszuk.net; Keshava A K > Cc: l2vpn@ietf.org; nvo3@ietf.org; l3vpn@ietf.org > Subject: Re: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN > traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version > Notification for draft-xu-mpls-in-udp-00.txt >=20 > Linda, to clarify the address "assignment" could be setup as a SLAAC > and hosts can generate address from a given prefix etc. >=20 > -----Original Message----- > From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of > Murari Sridharan > Sent: Tuesday, May 15, 2012 1:12 PM > To: Linda Dunbar; robert@raszuk.net; Keshava A K > Cc: l2vpn@ietf.org; nvo3@ietf.org; l3vpn@ietf.org > Subject: Re: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN > traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version > Notification for draft-xu-mpls-in-udp-00.txt >=20 > Whichever entity assigns IP addresses to the host can assign one or > many including 1:1 for every VM in that host. This isn't specific to > IPv6 or IPv4. >=20 > On a general note, devices/appliances etc that want to participate in > NV03 will likely want to understand specific tenant information to > provide richer services. No matter what the encapsulation format is > devices/appliances will need to update if they want to do something > interesting with the flow. I have seen several threads where folks seem > to have a "let's keep switch-ECMP" view of the DC which I think is > narrow. >=20 > Thanks > Murari >=20 > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Linda Dunbar > Sent: Tuesday, May 15, 2012 12:41 PM > To: robert@raszuk.net; Keshava A K > Cc: l2vpn@ietf.org; nvo3@ietf.org; l3vpn@ietf.org > Subject: RE: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN > traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version > Notification for draft-xu-mpls-in-udp-00.txt >=20 > Robert, >=20 > When GRE encapsulation uses different SRC/DST addresses for different > flows, it means that same OverlayBoundaryPoint needs multiple addresses. > Does it also mean an IP prefix can be given to a OverlayBoundaryPoint? > I guess for IPv6, there shouldn't be any issues, should it? (well I am > not an IPv6 expert). >=20 > Linda >=20 > > -----Original Message----- > > From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf > > Of Robert Raszuk > > Sent: Wednesday, May 09, 2012 2:27 AM > > To: Keshava A K > > Cc: l2vpn@ietf.org; Xuxiaohu; nvo3@ietf.org; l3vpn@ietf.org > > Subject: Re: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN > > traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New > Version > > Notification for draft-xu-mpls-in-udp-00.txt > > > > > > > If switches were to try to distribute GRE flows between two VTEPs > > > that used a GRE encapsulation, all the traffic would be directed to > > > use only one link within these Port Channels. > > > > Not true. GRE encapsulation is not mandated to use the same src/dst > > addresses for all flows between given two end points. > > > > You do not need to parse deep into packet to enable good load > > balancing hash across parallel links when you use GRE as an > > encapsulation technology. > > > > And what is nice about IP encapsulation all GRE src/dst addresses can > > be naturally aggregated so from IGP point of view they still look > like > > a single prefix. > > > > Regards, > > R. > > _______________________________________________ > > nvo3 mailing list > > nvo3@ietf.org > > https://www.ietf.org/mailman/listinfo/nvo3 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From wwwrun@rfc-editor.org Fri May 18 10:30:19 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0A321F86B5; Fri, 18 May 2012 10:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.691 X-Spam-Level: X-Spam-Status: No, score=-104.691 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-Fv3ifWQfQv; Fri, 18 May 2012 10:30:17 -0700 (PDT) Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id B59BD21F86B4; Fri, 18 May 2012 10:30:17 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 70BB8B1E009; Fri, 18 May 2012 10:27:27 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 6625 on Wildcards in Multicast VPN Auto-Discovery Routes From: rfc-editor@rfc-editor.org Message-Id: <20120518172727.70BB8B1E009@rfc-editor.org> Date: Fri, 18 May 2012 10:27:27 -0700 (PDT) Cc: l3vpn@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 17:30:19 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6625 Title: Wildcards in Multicast VPN Auto-Discovery Routes Author: E. Rosen, Ed., Y. Rekhter, Ed., W. Hendrickx, R. Qiu Status: Standards Track Stream: IETF Date: May 2012 Mailbox: erosen@cisco.com, yakov@juniper.net, wim.henderickx@alcatel-lucent.be, rayq@huawei.com Pages: 17 Characters: 35348 Updates: RFC6514 I-D Tag: draft-ietf-l3vpn-mvpn-wildcards-02.txt URL: http://www.rfc-editor.org/rfc/rfc6625.txt In Multicast Virtual Private Networks (MVPNs), customer multicast flows are carried in "tunnels" through a service provider's network. The base specifications for MVPN define BGP multicast VPN "auto-discovery routes" and specify how to use an auto-discovery route to advertise the fact that an individual customer multicast flow is being carried in a particular tunnel. However, those specifications do not provide a way to specify, in a single such route, that multiple customer flows are being carried in a single tunnel. Those specifications also do not provide a way to advertise that a particular tunnel is to be used by default to carry all customer flows, except in the case where that tunnel is joined by all the provider edge routers of the MVPN. This document eliminates these restrictions by specifying the use of "wildcard" elements in the customer flow identifiers. With wildcard elements, a single auto-discovery route can refer to multiple customer flows or even to all customer flows. [STANDARDS-TRACK] This document is a product of the Layer 3 Virtual Private Networks Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From petrlapu@microsoft.com Sun May 27 23:11:40 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A532D21F85A2 for ; Sun, 27 May 2012 23:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHA061fxg2Uy for ; Sun, 27 May 2012 23:11:39 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id B96E421F85A1 for ; Sun, 27 May 2012 23:11:39 -0700 (PDT) Received: from mail114-ch1-R.bigfish.com (10.43.68.247) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.23; Mon, 28 May 2012 06:11:20 +0000 Received: from mail114-ch1 (localhost [127.0.0.1]) by mail114-ch1-R.bigfish.com (Postfix) with ESMTP id 70B66240259; Mon, 28 May 2012 06:11:20 +0000 (UTC) X-SpamScore: 0 X-BigFish: VS0(zzzz1202hzzz2fh2a8h668h839h944hd25hf0ah) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail114-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=petrlapu@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail114-ch1 (localhost.localdomain [127.0.0.1]) by mail114-ch1 (MessageSwitch) id 1338185477719785_4927; Mon, 28 May 2012 06:11:17 +0000 (UTC) Received: from CH1EHSMHS001.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.237]) by mail114-ch1.bigfish.com (Postfix) with ESMTP id ABC9B2004B; Mon, 28 May 2012 06:11:17 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS001.bigfish.com (10.43.70.1) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 28 May 2012 06:11:16 +0000 Received: from TK5EX14MBXC299.redmond.corp.microsoft.com ([169.254.2.3]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0298.005; Mon, 28 May 2012 06:11:34 +0000 From: Petr Lapukhov To: "roque@contrailsystems.com" Subject: Re: draft-marques-l3vpn-mcast-edge-00 Thread-Topic: Re: draft-marques-l3vpn-mcast-edge-00 Thread-Index: Ac08lA3DYOhx7LQgSqucCEjD9eI5TQ== Date: Mon, 28 May 2012 06:11:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "derick.winkworth@fisglobal.com" , "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 06:28:49 -0000 Hi Pedro, Thanks for an interesting read! However, I have some concerns regarding the= problem statement in the document: >For Clos topologies with multiple stages native multicast support >within the switching infrastructure is both unnecessary and >undesirable. By definition the Clos network has enough bandwidth to >deliver a packet from any input port to any output port. Native >multicast support would however make it such that the network would >no longer be non-blocking. Bringing with it the need to devise >congestion management procedures. Here they are: 1) Multicast routing over Clos topology could be non-blocking provided that= some criteria on Clos topology dimensions are met and multicast distributi= on tree fan-outs are properly balanced at ingress and middle stages of the = Clos fabric.=20 2) Congestion management in Clos networks would be necessary in any case, d= ue to statistical multiplexing and possibility of (N -> 1) port traffic flo= w. 3) The "ingress unicast replication" in VPN forwarder creates the following= issues: 3.1) If done at software hypervisor level, it will most likely overload phy= sical uplink(s) on the server: N replicas sent as opposed to 1 in case of n= ative multicast 3.2) If done at hardware switch level (edge of physical Clos topology), it = cannot leverage hardware capabilities for multicast replication, and thus c= ould be difficult to implement and will stress the switch internal fabric. 4) If L3 VPN spans WAN for Inter-DC communications, unicast replication mak= es any WAN multicast optimization impossible, unless there is a "translatin= g" WAN gateway that will forward packets as native multicast. 5) Optimizing overlay multicast distribution tree could be difficult, since= underlying network metrics may be hidden from VPN gateways. I'm reviewing the rest of the document, and hopefully can come up with more= comments later. Best regards, Petr Lapukhov Microsoft From pedro.r.marques@gmail.com Mon May 28 20:59:38 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07EA121F87CF for ; Mon, 28 May 2012 20:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+xz4AEUMCDO for ; Mon, 28 May 2012 20:59:37 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC5F21F8797 for ; Mon, 28 May 2012 20:59:37 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so5255447pbc.31 for ; Mon, 28 May 2012 20:59:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:references:to:message-id :mime-version:x-mailer; bh=AToXLkO5UK6KKXU++tRbTv7y7Ol053UOjG2tMroTvY0=; b=rcP6sSX4IC4x7HPneqXWUKYiLvs7YGAmhcnNITTHeYwzIqSJyuU+fFiwNVpoYCMa7J ohhCuU/KBp/jG6m67Q8du0Xfb7amJ1/gX+kXneGyV9IDrSNlYW+to4SNPrGvynDxT+79 e0oGFd5UF2ufQpP/a5KhzBAHM5MSxrYi8S71bySISEjWOypHAiPVoSm0E+gZoBfQ/NFq xutqntHGM4+h+fBrhDohXpIyDxQtfG7Hqnb/Ymt8Ccf0DAU4qirsBHCz6zq+bRhrOD1t jqr4Uuv4A/vQk3P10Rj9OTXQ5c6bqXrZ0t83FjmQhHAdihGdvYKZOIr7WBFyTaJ1mNiR cTzw== Received: by 10.68.238.68 with SMTP id vi4mr11395704pbc.123.1338263976619; Mon, 28 May 2012 20:59:36 -0700 (PDT) Received: from [192.168.1.69] (173-164-176-214-SFBA.hfc.comcastbusiness.net. [173.164.176.214]) by mx.google.com with ESMTPS id qq2sm21384294pbc.27.2012.05.28.20.59.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 May 2012 20:59:35 -0700 (PDT) From: Pedro Roque Marques Content-Type: multipart/alternative; boundary="Apple-Mail=_D19F5E47-21C2-4D21-A288-BC07BBD2683D" Subject: Re: draft-marques-l3vpn-mcast-edge-00 Date: Mon, 28 May 2012 20:59:57 -0700 References: <02A52D67-8614-4299-A301-6D1321ACA185@contrailsystems.com> To: l3vpn@ietf.org Message-Id: <1B7228B9-16E3-465E-90A0-73E406C177ED@gmail.com> Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 03:59:38 -0000 --Apple-Mail=_D19F5E47-21C2-4D21-A288-BC07BBD2683D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Resending from the email address i'm subscribed to... > From: Pedro Marques > Subject: Re: draft-marques-l3vpn-mcast-edge-00 > Date: May 28, 2012 8:57:53 PM PDT > To: Petr Lapukhov > Cc: Yiqun Cai , "derick.winkworth@fisglobal.com" = , "lufang@cisco.com" , = "l3vpn@ietf.org" >=20 >=20 > On May 27, 2012, at 11:11 PM, Petr Lapukhov wrote: >=20 >> Hi Pedro, >=20 > Petr, > Thank you for your comments. Answers inline. >=20 >>=20 >> Thanks for an interesting read! However, I have some concerns = regarding the problem statement in the document: >>=20 >>> For Clos topologies with multiple stages native multicast support >>> within the switching infrastructure is both unnecessary and >>> undesirable. By definition the Clos network has enough bandwidth to >>> deliver a packet from any input port to any output port. Native >>> multicast support would however make it such that the network would >>> no longer be non-blocking. Bringing with it the need to devise >>> congestion management procedures. >>=20 >> Here they are: >>=20 >> 1) Multicast routing over Clos topology could be non-blocking = provided that some criteria on Clos topology dimensions are met and = multicast distribution tree fan-outs are properly balanced at ingress = and middle stages of the Clos fabric. >=20 > Multicast over a CLOS topology creates congestion management issues. = One way to address the problem, in large scale CLOS topologies, is to = eliminate native multicast in the fabric. That is an approach taken in = several networks, including networks that are fully enclosed in a = chassis or set of chassis. >=20 >>=20 >> 2) Congestion management in Clos networks would be necessary in any = case, due to statistical multiplexing and possibility of (N -> 1) port = traffic flow. >=20 > In practice, many networks are running CLOS topologies with no = congestion management support. The assumption is that if hash based load = balancing of flows is "good enough" and if the flows are small compared = to link size, that the fabric is non-blocking. This allows one to build = very large scale CLOS fabrics with off-the-shelf and/or heterogenous = components, where each switch works independently. Congestion management = at large scale is a very torny issue=85 >=20 > I believe that there are several efforts in the IEEE under the = umbrella of "data-center ethernet" in order to bring global congestion = notification/flow control into a heterogenous environment. It is my = understanding that there is a non-trivial number of networks that prefer = to operate with simple hash based mechanism. >=20 >> 3) The "ingress unicast replication" in VPN forwarder creates the = following issues: >>=20 >> 3.1) If done at software hypervisor level, it will most likely = overload physical uplink(s) on the server: N replicas sent as opposed to = 1 in case of native multicast >=20 > This is the main rational for this work. One could have started with = just plain ingress replication. But in that case the ingress would have = to replicate to the full membership of the group. With an edge = replication tree, the number of copies is limited to N. > As with any other network design, it is a question of trade-offs. The = authors believe there is a non-trivial number of applications (e.g. = discovery) where this is a useful approach. >=20 >> 3.2) If done at hardware switch level (edge of physical Clos = topology), it cannot leverage hardware capabilities for multicast = replication, and thus could be difficult to implement and will stress = the switch internal fabric. >=20 > Building hardware with no multicast support can also simplify the = hardware design. >=20 >>=20 >> 4) If L3 VPN spans WAN for Inter-DC communications, unicast = replication makes any WAN multicast optimization impossible, unless = there is a "translating" WAN gateway that will forward packets as native = multicast. >=20 > The document only covers intra-DC scenarios, as of now. For WAN = traffic, we do assume that there are systems that support L3VPN = multicast as defined currently. >=20 >> 5) Optimizing overlay multicast distribution tree could be difficult, = since underlying network metrics may be hidden from VPN gateways. >=20 > In several practical scenarios i aware of, the intra-DC network has 2 = costs points: same rack, different racks. Even in scenarios where there = are multiple metrics, the BGP signaling gateway can be made aware of the = physical topology of the network. My understanding is that the intra-DC = network can be optimized. >=20 >>=20 >> I'm reviewing the rest of the document, and hopefully can come up = with more comments later. >=20 > Thank you very much for your attention. >=20 >>=20 >> Best regards, >>=20 >> Petr Lapukhov >> Microsoft >>=20 >=20 --Apple-Mail=_D19F5E47-21C2-4D21-A288-BC07BBD2683D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
From: Pedro Marques <roque@contrailsystems.com>= ;
Subject: Re: = draft-marques-l3vpn-mcast-edge-00
Date: May 28, 2012 = 8:57:53 PM PDT
To: Petr Lapukhov <petrlapu@microsoft.com>
<= /span>

=

On May 27, 2012, at 11:11 PM, Petr Lapukhov = wrote:

Hi = Pedro,

Petr,
Thank you for your comments. Answers = inline.


Thanks for an interesting read! However, I have some = concerns regarding the problem statement in the = document:

For Clos topologies with multiple stages native multicast = support
within the switching infrastructure is both unnecessary = and
undesirable.  By definition the Clos network has = enough bandwidth to
deliver a packet from any input = port to any output port. =  Native
multicast support would however = make it such that the network = would
no longer be non-blocking.  Bringing with it the need = to devise
congestion management = procedures.

Here they = are:

1) Multicast = routing over Clos topology could be non-blocking provided that some = criteria on Clos topology dimensions are met and multicast distribution = tree fan-outs are properly balanced at ingress and middle stages of the = Clos fabric.

Multicast over a CLOS topology creates = congestion management issues. One way to address the problem, in large = scale CLOS topologies, is to eliminate native multicast in the fabric. = That is an approach taken in several networks, including networks that = are fully enclosed in a chassis or set of chassis.


2) Congestion = management in Clos networks would be necessary in any case, due to = statistical multiplexing and possibility of (N -> 1) port traffic = flow.

In practice, many networks are running CLOS = topologies with no congestion management support. The assumption is that = if hash based load balancing of flows is "good enough" and if the flows = are small compared to link size, that the fabric is non-blocking. This = allows one to build very large scale CLOS fabrics with off-the-shelf = and/or heterogenous components, where each switch works independently. = Congestion management at large scale is a very torny issue=85

I = believe that there are several efforts in the IEEE under the umbrella of = "data-center ethernet" in order to bring global congestion = notification/flow control into a heterogenous environment. It is my = understanding that there is a non-trivial number of networks that prefer = to operate with simple hash based mechanism.

3) The "ingress unicast replication" in VPN forwarder = creates the following issues:

3.1) If done at = software hypervisor level, it will most likely overload physical = uplink(s) on the server: N replicas sent as opposed to 1 in case of = native multicast

This is the main rational for this = work. One could have started with just plain ingress replication. But in = that case the ingress would have to replicate to the full membership of = the group. With an edge replication tree, the number of copies is = limited to N.
As with any other network design, it is a question of = trade-offs. The authors believe there is a non-trivial number of = applications (e.g. discovery) where this is a useful = approach.

3.2) If done at hardware = switch level (edge of physical Clos topology), it cannot leverage = hardware capabilities for multicast replication, and thus could be = difficult to implement and will stress the switch internal = fabric.

Building hardware with no multicast support = can also simplify the hardware design.


4) If L3 VPN = spans WAN for Inter-DC communications, unicast replication makes any WAN = multicast optimization impossible, unless there is a "translating" WAN = gateway that will forward packets as native = multicast.

The document only covers intra-DC = scenarios, as of now. For WAN traffic, we do assume that there are = systems that support L3VPN multicast as defined = currently.

5) Optimizing overlay = multicast distribution tree could be difficult, since underlying network = metrics may be hidden from VPN gateways.

In several = practical scenarios i aware of, the intra-DC network has 2 costs points: = same rack, different racks. Even in scenarios where there are multiple = metrics, the BGP signaling gateway can be made aware of the physical = topology of the network. My understanding is that the intra-DC network = can be optimized.


I'm reviewing = the rest of the document, and hopefully can come up with more comments = later.

Thank you very much for your = attention.


Best regards,

Petr = Lapukhov
Microsoft



= --Apple-Mail=_D19F5E47-21C2-4D21-A288-BC07BBD2683D-- From petrlapu@microsoft.com Mon May 28 22:22:16 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4C821F87B4 for ; Mon, 28 May 2012 22:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.917 X-Spam-Level: X-Spam-Status: No, score=-3.917 tagged_above=-999 required=5 tests=[AWL=-0.917, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPgqI5VJ1kSE for ; Mon, 28 May 2012 22:22:15 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id BDAAB21F8749 for ; Mon, 28 May 2012 22:22:14 -0700 (PDT) Received: from mail251-ch1-R.bigfish.com (10.43.68.247) by CH1EHSOBE012.bigfish.com (10.43.70.62) with Microsoft SMTP Server id 14.1.225.23; Tue, 29 May 2012 05:21:52 +0000 Received: from mail251-ch1 (localhost [127.0.0.1]) by mail251-ch1-R.bigfish.com (Postfix) with ESMTP id 500C51BC0371; Tue, 29 May 2012 05:21:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -41 X-BigFish: VS-41(zz9371I542M1432N98dK11f6Nzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail251-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=petrlapu@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail251-ch1 (localhost.localdomain [127.0.0.1]) by mail251-ch1 (MessageSwitch) id 1338268910341747_6310; Tue, 29 May 2012 05:21:50 +0000 (UTC) Received: from CH1EHSMHS010.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246]) by mail251-ch1.bigfish.com (Postfix) with ESMTP id 51A2618004A; Tue, 29 May 2012 05:21:50 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS010.bigfish.com (10.43.70.10) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 29 May 2012 05:21:50 +0000 Received: from TK5EX14MBXC299.redmond.corp.microsoft.com ([169.254.2.3]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0298.005; Tue, 29 May 2012 05:22:10 +0000 From: Petr Lapukhov To: Pedro Marques Subject: RE: draft-marques-l3vpn-mcast-edge-00 Thread-Topic: draft-marques-l3vpn-mcast-edge-00 Thread-Index: AQHNPU8wsz/GIe5QfES8Lg/mMDpeD5bgMNGA Date: Tue, 29 May 2012 05:22:09 +0000 Message-ID: References: <02A52D67-8614-4299-A301-6D1321ACA185@contrailsystems.com> In-Reply-To: <02A52D67-8614-4299-A301-6D1321ACA185@contrailsystems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "derick.winkworth@fisglobal.com" , "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 05:22:16 -0000 Pedro, Thanks for your response! Firstly, I should have noted that I find the prop= osed multicast "emulation" to be very helpful in some realistic scenarios, = specifically in the cases where multicast could not be easily turned on (e.= g. risking a software problem, since PIM SM is not a nice protocol to imple= ment).=20 I still believe that optimizing multicast routing is "dense" networks is a = separate interesting problem, that does have "some" solutions, and I'm sure= you are well aware of the research done in that field. Of course, in the r= eal world of "custom" Clos fabrics use of regular PIM SM with SPT trees has= obvious optimality implications (e.g. load-sharing the SPT's, optimum fan-= out distribution and so on). For the congestion management in Clos networks - we have observed very high= buffer utilization watermarks on practically all of our "spine" switches (= unicast traffic only), due to peak loads of various compute traffic. Furthe= rmore, experimentation have shown that even a very simple QoS policy with t= wo xWRR queues differentiating bulk and query traffic results in significan= t performance improvements. However, I agree that having multicast flows to= the mix here may create interesting complications in the switch internal f= abrics. My last question was whether there exists an analysis/research on tradeoffs= associated with edge replication using an "overlay" tree - e.g. having re= plicated packets cross the bisection twice as part of the constructed distr= ibution tree. Thank you, Petr Lapukhov Microsoft -----Original Message----- From: Pedro Marques [mailto:roque@contrailsystems.com]=20 Sent: Monday, May 28, 2012 8:58 PM To: Petr Lapukhov Cc: Yiqun Cai; derick.winkworth@fisglobal.com; lufang@cisco.com; l3vpn@ietf= .org Subject: Re: draft-marques-l3vpn-mcast-edge-00 On May 27, 2012, at 11:11 PM, Petr Lapukhov wrote: > Hi Pedro, Petr, Thank you for your comments. Answers inline. >=20 > Thanks for an interesting read! However, I have some concerns regarding t= he problem statement in the document: >=20 >> For Clos topologies with multiple stages native multicast support=20 >> within the switching infrastructure is both unnecessary and=20 >> undesirable. By definition the Clos network has enough bandwidth to=20 >> deliver a packet from any input port to any output port. Native=20 >> multicast support would however make it such that the network would=20 >> no longer be non-blocking. Bringing with it the need to devise=20 >> congestion management procedures. >=20 > Here they are: >=20 > 1) Multicast routing over Clos topology could be non-blocking provided th= at some criteria on Clos topology dimensions are met and multicast distribu= tion tree fan-outs are properly balanced at ingress and middle stages of th= e Clos fabric. Multicast over a CLOS topology creates congestion management issues. One wa= y to address the problem, in large scale CLOS topologies, is to eliminate n= ative multicast in the fabric. That is an approach taken in several network= s, including networks that are fully enclosed in a chassis or set of chassi= s. >=20 > 2) Congestion management in Clos networks would be necessary in any case,= due to statistical multiplexing and possibility of (N -> 1) port traffic f= low. In practice, many networks are running CLOS topologies with no congestion m= anagement support. The assumption is that if hash based load balancing of f= lows is "good enough" and if the flows are small compared to link size, tha= t the fabric is non-blocking. This allows one to build very large scale CLO= S fabrics with off-the-shelf and/or heterogenous components, where each swi= tch works independently. Congestion management at large scale is a very tor= ny issue... I believe that there are several efforts in the IEEE under the umbrella of = "data-center ethernet" in order to bring global congestion notification/flo= w control into a heterogenous environment. It is my understanding that ther= e is a non-trivial number of networks that prefer to operate with simple ha= sh based mechanism. > 3) The "ingress unicast replication" in VPN forwarder creates the followi= ng issues: >=20 > 3.1) If done at software hypervisor level, it will most likely=20 > overload physical uplink(s) on the server: N replicas sent as opposed=20 > to 1 in case of native multicast This is the main rational for this work. One could have started with just p= lain ingress replication. But in that case the ingress would have to replic= ate to the full membership of the group. With an edge replication tree, the= number of copies is limited to N. As with any other network design, it is a question of trade-offs. The autho= rs believe there is a non-trivial number of applications (e.g. discovery) w= here this is a useful approach. > 3.2) If done at hardware switch level (edge of physical Clos topology), i= t cannot leverage hardware capabilities for multicast replication, and thus= could be difficult to implement and will stress the switch internal fabric= . Building hardware with no multicast support can also simplify the hardware = design. >=20 > 4) If L3 VPN spans WAN for Inter-DC communications, unicast replication m= akes any WAN multicast optimization impossible, unless there is a "translat= ing" WAN gateway that will forward packets as native multicast. The document only covers intra-DC scenarios, as of now. For WAN traffic, we= do assume that there are systems that support L3VPN multicast as defined c= urrently. > 5) Optimizing overlay multicast distribution tree could be difficult, sin= ce underlying network metrics may be hidden from VPN gateways. In several practical scenarios i aware of, the intra-DC network has 2 costs= points: same rack, different racks. Even in scenarios where there are mult= iple metrics, the BGP signaling gateway can be made aware of the physical t= opology of the network. My understanding is that the intra-DC network can b= e optimized. >=20 > I'm reviewing the rest of the document, and hopefully can come up with mo= re comments later. Thank you very much for your attention. >=20 > Best regards, >=20 > Petr Lapukhov > Microsoft >=20 From pedro.r.marques@gmail.com Tue May 29 09:05:52 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B80221F8732 for ; Tue, 29 May 2012 09:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SPEC_ROLEX_NOV5B=1.111] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsvFwNIzFNGg for ; Tue, 29 May 2012 09:05:51 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7B67621F8724 for ; Tue, 29 May 2012 09:05:51 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so6056765pbc.31 for ; Tue, 29 May 2012 09:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=JY2Phdih2vhHDc8hxhXp1rhEcBv2MAl/oonDL6biFO8=; b=UZ+wzk+MDhZ1VwQOlHiz6sy52t5zxNS0NAPW116thnpdx6ouszHGYLbckS0fq5fkEW gNHFP60VS3FI+Cx3thcHDC1g8HM3eI7duv/RLHaaAItUKekeojjxRLsASY10I4OKDMWY fE1lcOvd2ht8hVAGkggSOYVh0eXSfJ41+kKKt7HerUQa1jS7L/kfd1In7Id+ssdyOxgk cbNRa1tgyc//3508bRdxwQUB6T16ZipmbKUlpViqXsk4gGrC2WMe4vFujHJYapss7Hvm ruD2kYOMeMbICCPCIiz+kk0lHyr6bks2VhsOr0i3Gxou4O1Wtbhn4TCWbcrzYxZQeORj Y+lw== Received: by 10.68.200.68 with SMTP id jq4mr40231561pbc.42.1338307551097; Tue, 29 May 2012 09:05:51 -0700 (PDT) Received: from [10.1.10.11] (173-164-176-214-SFBA.hfc.comcastbusiness.net. [173.164.176.214]) by mx.google.com with ESMTPS id ub1sm23219952pbc.68.2012.05.29.09.05.47 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 May 2012 09:05:48 -0700 (PDT) Subject: Re: draft-marques-l3vpn-mcast-edge-00 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Pedro Marques In-Reply-To: Date: Tue, 29 May 2012 09:06:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4544C62C-990C-4321-ADD8-3FC077799C8D@gmail.com> References: <02A52D67-8614-4299-A301-6D1321ACA185@contrailsystems.com> To: Petr Lapukhov X-Mailer: Apple Mail (2.1278) Cc: "derick.winkworth@fisglobal.com" , "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 16:05:52 -0000 Petr, On May 28, 2012, at 10:22 PM, Petr Lapukhov wrote: > Pedro, >=20 > Thanks for your response! Firstly, I should have noted that I find the = proposed multicast "emulation" to be very helpful in some realistic = scenarios, specifically in the cases where multicast could not be easily = turned on (e.g. risking a software problem, since PIM SM is not a nice = protocol to implement). With PIM-SM and in an environment where virtual networks are being = deployed to support multi-tenancy and/or per application access groups, = the multicast group information pertains to the virtual networks and can = easily exceed the forwarding capacity of individual switching elements = in the fabric not to mention the operational aspects of having virtual = network signaling within the fabric. I'd expect most network operators to default to ingress replication. = Which was the original design point for multicast support in L3VPN = environments. In my opinion the edge replication solution offers a = different trade-off where the number of replicas that cross a single = uplink is kept to an upper bound and there is no requirement to support = multicast forwarding natively in the fabric. >=20 >=20 > I still believe that optimizing multicast routing is "dense" networks = is a separate interesting problem, that does have "some" solutions, and = I'm sure you are well aware of the research done in that field. In a data-center environment i would expect that multicast would be very = sparse. Many operators are talking about very large data-centers (10k+ = machines each supporting 100+ guests)=85 very few applications would be = "dense" in this environment and those would probably be best advised to = choose a different design point anyway=85 If the multicast membership is sparse, link level multicast replication = may not afford any real benefits. > Of course, in the real world of "custom" Clos fabrics use of regular = PIM SM with SPT trees has obvious optimality implications (e.g. = load-sharing the SPT's, optimum fan-out distribution and so on). >=20 > For the congestion management in Clos networks - we have observed very = high buffer utilization watermarks on practically all of our "spine" = switches (unicast traffic only), due to peak loads of various compute = traffic. There are two approaches that i'm aware of: 1) Increase the ratio between link bandwidth and max rate flow. 2) Deploy a network-wide congestion management algorithm from ingress to = egress. (you can't assume that the buffers in the intermediate nodes are = useful for congestion management). Lots of work has been put on both of these approaches. With very strong = opinion on both sides. Let me just say that from my perspective it would = seem unwise to compound the congestion management approach by attempting = to also cover multicast. > Furthermore, experimentation have shown that even a very simple QoS = policy with two xWRR queues differentiating bulk and query traffic = results in significant performance improvements. No doubt. Instantaneous drop selection can be beneficial. This is = totally different end-to-end congestion avoidance. > However, I agree that having multicast flows to the mix here may = create interesting complications in the switch internal fabrics. Yes. Which is the reason that i would expect most network operators to = choose ingress replication in order to support IP broadcast/multicast = for applications that are discovering membership. >=20 > My last question was whether there exists an analysis/research on = tradeoffs associated with edge replication using an "overlay" tree - = e.g. having replicated packets cross the bisection twice as part of the = constructed distribution tree. The math is rather straightforward. Each "node" in the tree adds = measurable latency. You can assume for analysis that the fabric is = over-provisioned and thus "free". The trade-off is the selection of = replication node-out degree. An higher replication factor increases the = number of packets sent from a single "VPN forwarder" but decreases the = height of the tree. The multicast edge replication document is written such that that degree = can be controlled by the network operator as a result of real = experimentation with the conditions of a particular network. thanks, Pedro. >=20 > Thank you, >=20 > Petr Lapukhov > Microsoft >=20 > -----Original Message----- > From: Pedro Marques [mailto:roque@contrailsystems.com]=20 > Sent: Monday, May 28, 2012 8:58 PM > To: Petr Lapukhov > Cc: Yiqun Cai; derick.winkworth@fisglobal.com; lufang@cisco.com; = l3vpn@ietf.org > Subject: Re: draft-marques-l3vpn-mcast-edge-00 >=20 >=20 > On May 27, 2012, at 11:11 PM, Petr Lapukhov wrote: >=20 >> Hi Pedro, >=20 > Petr, > Thank you for your comments. Answers inline. >=20 >>=20 >> Thanks for an interesting read! However, I have some concerns = regarding the problem statement in the document: >>=20 >>> For Clos topologies with multiple stages native multicast support=20 >>> within the switching infrastructure is both unnecessary and=20 >>> undesirable. By definition the Clos network has enough bandwidth to=20= >>> deliver a packet from any input port to any output port. Native=20 >>> multicast support would however make it such that the network would=20= >>> no longer be non-blocking. Bringing with it the need to devise=20 >>> congestion management procedures. >>=20 >> Here they are: >>=20 >> 1) Multicast routing over Clos topology could be non-blocking = provided that some criteria on Clos topology dimensions are met and = multicast distribution tree fan-outs are properly balanced at ingress = and middle stages of the Clos fabric. >=20 > Multicast over a CLOS topology creates congestion management issues. = One way to address the problem, in large scale CLOS topologies, is to = eliminate native multicast in the fabric. That is an approach taken in = several networks, including networks that are fully enclosed in a = chassis or set of chassis. >=20 >>=20 >> 2) Congestion management in Clos networks would be necessary in any = case, due to statistical multiplexing and possibility of (N -> 1) port = traffic flow. >=20 > In practice, many networks are running CLOS topologies with no = congestion management support. The assumption is that if hash based load = balancing of flows is "good enough" and if the flows are small compared = to link size, that the fabric is non-blocking. This allows one to build = very large scale CLOS fabrics with off-the-shelf and/or heterogenous = components, where each switch works independently. Congestion management = at large scale is a very torny issue... >=20 > I believe that there are several efforts in the IEEE under the = umbrella of "data-center ethernet" in order to bring global congestion = notification/flow control into a heterogenous environment. It is my = understanding that there is a non-trivial number of networks that prefer = to operate with simple hash based mechanism. >=20 >> 3) The "ingress unicast replication" in VPN forwarder creates the = following issues: >>=20 >> 3.1) If done at software hypervisor level, it will most likely=20 >> overload physical uplink(s) on the server: N replicas sent as opposed=20= >> to 1 in case of native multicast >=20 > This is the main rational for this work. One could have started with = just plain ingress replication. But in that case the ingress would have = to replicate to the full membership of the group. With an edge = replication tree, the number of copies is limited to N. > As with any other network design, it is a question of trade-offs. The = authors believe there is a non-trivial number of applications (e.g. = discovery) where this is a useful approach. >=20 >> 3.2) If done at hardware switch level (edge of physical Clos = topology), it cannot leverage hardware capabilities for multicast = replication, and thus could be difficult to implement and will stress = the switch internal fabric. >=20 > Building hardware with no multicast support can also simplify the = hardware design. >=20 >>=20 >> 4) If L3 VPN spans WAN for Inter-DC communications, unicast = replication makes any WAN multicast optimization impossible, unless = there is a "translating" WAN gateway that will forward packets as native = multicast. >=20 > The document only covers intra-DC scenarios, as of now. For WAN = traffic, we do assume that there are systems that support L3VPN = multicast as defined currently. >=20 >> 5) Optimizing overlay multicast distribution tree could be difficult, = since underlying network metrics may be hidden from VPN gateways. >=20 > In several practical scenarios i aware of, the intra-DC network has 2 = costs points: same rack, different racks. Even in scenarios where there = are multiple metrics, the BGP signaling gateway can be made aware of the = physical topology of the network. My understanding is that the intra-DC = network can be optimized. >=20 >>=20 >> I'm reviewing the rest of the document, and hopefully can come up = with more comments later. >=20 > Thank you very much for your attention. >=20 >>=20 >> Best regards, >>=20 >> Petr Lapukhov >> Microsoft >>=20 >=20 >=20 >=20