[mpls] Discussion on how to transport MPLS over UDP tunnels
Xuxiaohu <xuxiaohu@huawei.com> Thu, 20 December 2012 10:15 UTC
Return-Path: <xuxiaohu@huawei.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B53C721F8502 for <mpls@ietfa.amsl.com>; Thu, 20 Dec 2012 02:15:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.43
X-Spam-Level:
X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=-0.973, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrwCaXzJ6hjP for <mpls@ietfa.amsl.com>; Thu, 20 Dec 2012 02:15:08 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 124C621F8CCE for <mpls@ietf.org>; Thu, 20 Dec 2012 02:15:04 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOA06729; Thu, 20 Dec 2012 10:15:04 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Dec 2012 10:14:34 +0000
Received: from SZXEML429-HUB.china.huawei.com (10.72.61.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Dec 2012 10:14:38 +0000
Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.152]) by SZXEML429-HUB.china.huawei.com ([10.72.61.37]) with mapi id 14.01.0323.003; Thu, 20 Dec 2012 18:13:59 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: Shane Amante <shane@castlepoint.net>
Thread-Topic: Discussion on how to transport MPLS over UDP tunnels
Thread-Index: AQHN3pq6dxmEvHStBkqLkCyKFyfQFw==
Date: Thu, 20 Dec 2012 10:13:59 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758953D@szxeml525-mbs.china.huawei.com>
References: <CCF5EC8E.2A183%josh.rogers@twcable.com> <E4CD1048-4DB1-4F78-880B-9E62626E370A@castlepoint.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> <D3780485-FC2B-4B85-BA87-2BAC24C53B9F@castlepoint.net>
In-Reply-To: <D3780485-FC2B-4B85-BA87-2BAC24C53B9F@castlepoint.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.98.130]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "draft-xu-mpls-in-udp@tools.ietf.org" <draft-xu-mpls-in-udp@tools.ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>
Subject: [mpls] Discussion on how to transport MPLS over UDP tunnels
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Dec 2012 10:15:09 -0000
Hi Shane, Thanks for your further comments and please see my response inline. Note: I changed the subject line according to Loa's suggestion. > -----邮件原件----- > 发件人: Shane Amante [mailto:shane@castlepoint.net] > 发送时间: 2012年12月19日 22:38 > 收件人: Xuxiaohu > 抄送: Rogers, Josh; Shahram Davari; draft-xu-mpls-in-udp@tools.ietf.org; > mpls@ietf.org; mpls-chairs@tools.ietf.org > 主题: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an > mpls working group document > > Xiaohu, > > On Dec 18, 2012, at 11:50 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote: > -----邮件原件----- > >> 发件人: Shane Amante [mailto:shane@castlepoint.net] > >> 发送时间: 2012年12月19日 11:58 > >> 收件人: Rogers, Josh > >> 抄送: Shahram Davari; Xuxiaohu; draft-xu-mpls-in-udp@tools.ietf.org; > >> mpls@ietf.org; mpls-chairs@tools.ietf.org > >> 主题: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp > an > >> mpls working group document > >> > >> > >> On Dec 18, 2012, at 8:50 AM, "Rogers, Josh" <josh.rogers@twcable.com> > >> wrote: > >>> I share your SP perspective, and do not see the problem this solution > >>> addresses in practice any longer. > >> > >> +1. Please do not define yet another MPLS-over-IP encapsulation. The > IETF > >> already standardized MPLS over GRE. The IETF has also standardized > MPLS > >> over L2TPv3/UDP/IP, which had seen some deployment in at least one, very > >> large operator network that I'm aware of to support carriage of L3VPN over > an > >> IP-only network. > > > > Hi Shane, > > > > Thank you for telling us there are actual deployments of MPLS over IP in at > least one, very large operator network. This fact must be very valuable to those > people who had believed there is no application of MPLS over IP in today's SP > networks. > > > >> See: RFC's 4454, 4719, 4591, 4349 for PWE3 over L2TPv3 > >> [NOTE: the dates the above were published was back in the 2006 > timeframe!] > >> RFC 4665 for requirements related to VPLS that say that VPLS may be > >> carried over L2TPv3 > >> And, here's evidence showing that at least one vendor has > implemented > >> IPVPN's over L2TPv3: > >> http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/csgl3vpn.html > > > > Thanks again for sharing the above information. As mentioned in this draft > AND other drafts, the mechanism of performing hash calculation on the Session > ID field in the L2TPv3 header or the Key field in the GRE header as defined in > [RFC 5640] is not widely supported by existing core routers so far. > > FWIW, I have had success, in the relatively recent past, in requesting a core > router vendor to support changes to the input-keys used in hash calculations in > _existing_ hardware, already deployed (extensively) throughout my network. > Further, I suspect that most large network operators are savvy folks and > understand the internal architecture of their HW fairly well. As a result, those > same operators know what is and is not technically possible in this regard. > Thus, it may be a question of "methods" necessary to convince their HW > supplier(s) to make appropriate changes in their equipment to achieve their > business goals. :-) However, this may not even be necessary ... see below. Could you please briefly explain how to make the above change in EXISTING hardware of already deployed core routers? > > In contrast, most existing core routers are already capable of balancing IP > traffic flows based on the hash of the five-tuple of UDP packets. By using the > MPLS-in-UDP encapsulation, the already available load-balancing capability of > most existing core routers can be leveraged without requiring any change to > them. That is the major motivation of this draft. > > If this is a concern, then why not encapsulate the traffic in MPLS/L2TPv3, which > uses UDP/IP, in the first place? If I understand it correctly, you prefer to use MPLS-in-L2TPv3-in-UDP instead of MPLS-in-UDP, right? > IMHO, a better proposal may be to consider a [minor] (?) change to RFC 3931, > which would allow the connection used for data packets (not control packets) > to use a varying set of source ports (or, source IP addresses), based on a hash > calculation, to achieve better load-balancing over existing equipment in an > IP-only core. L2TP end-system implementations would be better off just using > the "Session ID" (and "Cookie") fields as the demultiplexor to associate > incoming packets with the associated L2TP Control Channel. In fact, it's not > clear to me that existing implementations may /already/ do this, making any > "check" on the incoming source port unnecessary for L2TP end-system > implementations. > > The beauty of the above approach is: > 1) I would think that the above is most likely a change that is limited to the > "control channel" (software) of existing L2TP end-system implementations. > Heck, it may even be backwards compatible with existing L2TPv3 > implementations. (L2TPv3 implementors would need to comment on that). IMHO, no matter MPLS-in-L2TPv3-in-UDP or MPLS-in-UDP, the hardware of PE routers needs to be upgraded, e.g., ingress PE routers need to fill in an entropy value in the source port field of UDP headers. > 2) There is a substantial added security one gets by using "Session ID" and > "Cookie" fields to ensure the received L2TPv3 packet is intended for the > identified session. Quoting from Section 8.2 of RFC 3931: > ---snip--- > L2TPv3 provides traffic separation for its VPNs via a 32-bit Session > ID in the L2TPv3 data header. When present, the L2TPv3 Cookie > (described in Section 4.1), provides an additional check to ensure > that an arriving packet is intended for the identified session. > Thus, use of a Cookie with the Session ID provides an extra guarantee > that the Session ID lookup was performed properly and that the > Session ID itself was not corrupted in transit. > ---snip--- > ... in regard to this question alone, I know the Security Area folks have, in the > past, had /substantial/ concerns about encapsulation of MPLS over IP transport. > In fact, this is why you see text in Section 7.6, "Security", of RFC 4665. > (There's likely similar language in other drafts that use MPLS for transport). > While I'm not sure that Security Area folks pay much attention to daily traffic on > the MPLS WG mailing list, I'm fairly confident this concern will arise if/when this > draft goes to the IESG ... If I understand it correctly, the reason for your preference of MPLS-in-L2TPv3-in-UDP is that it has an added security feature. If that is so concerned, can you explain why MPLS-in-GRE is far more popular than MPLS-in-L2TP in practice? Best regards, Xiaohu > 3) Finally, this approach only affects the end-systems that implement L2TP, for > tunneling of MPLS/IP, and does not require an entire industry to support > MPLS/UDP encapsulation in their product lines. > > -shane > > > > > > Best regards, > > Xiaohu > > > >> If there was market demand for MPLS over IP, then clearly it would have > been > >> more widely implemented by equipment vendors, with either MPLS over > GRE or > >> MPLS over L2TPv3. (Where there's a will, there's a way). I would note > that > >> the most likely reasons this did not pan out was there are several, practical > >> operational benefits one gets from going with native MPLS > >> encapsulation/switching within the data plane, namely: > >> - MPLS Fast Re-Route > >> - MPLS Traffic Engineering > >> ... to name, but a few. Those have tended to be quite compelling > arguments > >> to 'upgrade' network HW to support MPLS encapsulation/switching. > >> > >> -shane > >> > >> > >>> -Josh > >>> > >>> > >>> On 12/18/12 12:31 AM, "Shahram Davari" <davari@broadcom.com> > wrote: > >>> > >>>> For service provider domain, MPLS over IP is legacy and there is no need > >>>> to improve it. > >>>> > >>>> Regards, > >>>> Shahram > >>>> > >>>> > >>>> On Dec 17, 2012, at 8:02 PM, "Xuxiaohu" <xuxiaohu@huawei.com> > wrote: > >>>> > >>>>> Shahram, > >>>>> > >>>>> This draft is ONLY intended to provide a MPLS-over-IP encapsulation > >>>>> method with a better load-balancing applicability so far to those > >>>>> operators who happen to require transporting MPLS application traffic > >>>>> across IP networks. I believe MPLS-based VPN over IP, NVGRE and > VXLAN > >>>>> each have their own advocators and use cases. If you absolutely believe > >>>>> it's meaningless of transporting MPLS application traffic across IP > >>>>> networks and therefore those existing RFCs related to MPLS over IP > >>>>> tunneling mechanisms should be moved to Historic status, please say > so. > >>>>> > >>>>> By the way, it seems this > >>>>> (http://www.ietf.org/mail-archive/web/nvo3/current/msg01864.html) is > >>>>> just the right thread suitable for you to make the following argument > >>>>> (i.e., whether or not MPLS-based VPN is applicable to data centers). I > >>>>> had thought you would speak up at that time. Sadly, surprisingly silent > >>>>> till now. > >>>>> > >>>>> Sigh, I didn't intend to say the above otherwise. > >>>>> > >>>>> Xiaohu > >>>>> > >>>>>> -----邮件原件----- > >>>>>> 发件人: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] 代表 > >> S. > >>>>>> Davari > >>>>>> 发送时间: 2012年12月15日 13:34 > >>>>>> 收件人: Loa Andersson > >>>>>> 抄送: draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org; > >>>>>> mpls-chairs@tools.ietf.org > >>>>>> 主题: Re: [mpls] poll to see if we have support to make > >>>>>> draft-xu-mpls-in-udp an > >>>>>> mpls working group document > >>>>>> > >>>>>> I don't support this draft since it has no application in today's > >>>>>> modern metro > >>>>>> and core, where MPLS is dominant, and its only practical application > >>>>>> in in data > >>>>>> center, which already is crowded with other solutions such as NVGRE > and > >>>>>> VXLAN. > >>>>>> > >>>>>> It seems the authors are trying to bypass the NVO3 solution selection > >>>>>> process > >>>>>> by advancing the draft in MPLS WG. > >>>>>> > >>>>>> Regards, > >>>>>> Shahram > >>>>>> > >>>>>> > >>>>>> On Dec 14, 2012, at 1:01 AM, Loa Andersson <loa@pi.nu> wrote: > >>>>>> > >>>>>>> Working group, > >>>>>>> > >>>>>>> This is to start a "two week" poll on adopting > >>>>>>> draft-xu-mpls-in-udp-06 as an MPLS working group document. > >>>>>>> Due to the holiday season this poll has been extended with one week. > >>>>>>> > >>>>>>> Please send your comments (support/not support) to the mpls > working > >>>>>>> group mailing list (mpls at ietf.org) Please give an technical > >>>>>>> motivation for your support/not support, especially if you think that > >>>>>>> the document should not be adopted as a working group document. > >>>>>>> > >>>>>>> This poll ends January 07, 2013. > >>>>>>> > >>>>>>> There is one IPR claim against this document - > >>>>>>> https://datatracker.ietf.org/ipr/1941/ . > >>>>>>> > >>>>>>> All the active co-authors has stated on the working group mailing list > >>>>>>> that they are not aware of any other IPR claims than those already > >>>>>>> disclosed. > >>>>>>> > >>>>>>> However, up to version -03 (the document that we used for the IPR > >>>>>>> poll) > >>>>>>> Marshall Eubanks was listed as one of the authors. Marshall has > >>>>>>> discontinued all interactions with the IETF, including the author team > >>>>>>> of draft-xu-mpls-in-udp-06. The working group chairs has tried to > >>>>>>> contact Marshall by other means, to try get a response on the IPR > >>>>>>> poll. > >>>>>>> We have had no success in this. > >>>>>>> > >>>>>>> From version -04 the authors decided to remove Marshall as a > >>>>>>> co-author. > >>>>>>> > >>>>>>> /Loa > >>>>>>> (mpls wg co-chair) > >>>>>>> -- > >>>>>>> > >>>>>>> > >>>>>>> Loa Andersson email: > >>>>>> loa.andersson@ericsson.com > >>>>>>> Sr Strategy and Standards Manager loa@pi.nu > >>>>>>> Ericsson Inc phone: +46 10 717 52 13 > >>>>>>> +46 767 72 92 13 > >>>>>>> _______________________________________________ > >>>>>>> mpls mailing list > >>>>>>> mpls@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/mpls > >>>>>> _______________________________________________ > >>>>>> mpls mailing list > >>>>>> mpls@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mpls > >>>>> _______________________________________________ > >>>>> mpls mailing list > >>>>> mpls@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mpls > >>>> _______________________________________________ > >>>> mpls mailing list > >>>> mpls@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mpls > >>> > >>> > >>> This E-mail and any of its attachments may contain Time Warner Cable > >> proprietary information, which is privileged, confidential, or subject to > >> copyright belonging to Time Warner Cable. This E-mail is intended solely for > the > >> use of the individual or entity to which it is addressed. If you are not the > >> intended recipient of this E-mail, you are hereby notified that any > dissemination, > >> distribution, copying, or action taken in relation to the contents of and > >> attachments to this E-mail is strictly prohibited and may be unlawful. If you > >> have received this E-mail in error, please notify the sender immediately and > >> permanently delete the original and any copy of this E-mail and any printout. > >>> _______________________________________________ > >>> mpls mailing list > >>> mpls@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mpls > >> > > >
- [mpls] poll to see if we have support to make dra… Loa Andersson
- Re: [mpls] poll to see if we have support to make… Lucy yong
- Re: [mpls] poll to see if we have support to make… Vivek Kumar
- Re: [mpls] poll to see if we have support to make… S. Davari
- Re: [mpls] poll to see if we have support to make… Kireeti Kompella
- Re: [mpls] poll to see if we have support to make… Sam Aldrin
- Re: [mpls] poll to see if we have support to make… Mach Chen
- Re: [mpls] poll to see if we have support to make… Xuxiaohu
- Re: [mpls] poll to see if we have support to make… Dhruv Dhody
- Re: [mpls] poll to see if we have support to make… Nischal Sheth
- Re: [mpls] poll to see if we have support to make… Puneet Agarwal
- Re: [mpls] poll to see if we have support to make… Xuxiaohu
- Re: [mpls] poll to see if we have support to make… Shahram Davari
- Re: [mpls] poll to see if we have support to make… Rogers, Josh
- Re: [mpls] poll to see if we have support to make… Linda Dunbar
- Re: [mpls] poll to see if we have support to make… Shane Amante
- Re: [mpls] poll to see if we have support to make… Xuxiaohu
- Re: [mpls] poll to see if we have support to make… Xuxiaohu
- Re: [mpls] poll to see if we have support to make… Loa Andersson
- Re: [mpls] poll to see if we have support to make… Shane Amante
- [mpls] Discussion on how to transport MPLS over U… Xuxiaohu
- Re: [mpls] MPLS client layer over an IGP underlyi… Adrian Farrel
- [mpls] MPLS client layer over an IGP underlying n… Lucy yong
- Re: [mpls] MPLS client layer over an IGP underlyi… Shahram Davari
- Re: [mpls] MPLS client layer over an IGP underlyi… Lucy yong
- Re: [mpls] MPLS client layer over an IGP underlyi… Shahram Davari
- Re: [mpls] MPLS client layer over an IGP underlyi… Lucy yong
- Re: [mpls] MPLS client layer over an IGP underlyi… Lucy yong
- Re: [mpls] Discussion on how to transport MPLS ov… Carlos Pignataro (cpignata)
- Re: [mpls] MPLS client layer over an IGP underlyi… Lucy yong
- Re: [mpls] MPLS client layer over an IGP underlyi… Xuxiaohu
- Re: [mpls] MPLS client layer over an IGP underlyi… Xuxiaohu
- Re: [mpls] MPLS client layer over an IGP underlyi… S. Davari
- Re: [mpls] poll to see if we have support to make… Andrew G. Malis
- Re: [mpls] poll to see if we have support to make… Lucy yong
- Re: [mpls] poll to see if we have support to make… Andrew G. Malis
- Re: [mpls] poll to see if we have support to make… Pat Thaler
- Re: [mpls] poll to see if we have support to make… Lucy yong
- Re: [mpls] MPLS client layer over an IGP underlyi… Lucy yong
- Re: [mpls] MPLS client layer over an IGP underlyi… S. Davari
- Re: [mpls] poll to see if we have support to make… Lizhenbin
- Re: [mpls] poll to see if we have support to make… Lizhong Jin
- Re: [mpls] MPLS client layer over an IGP underlyi… Xuxiaohu
- Re: [mpls] poll to see if we have support to make… Xuxiaohu
- Re: [mpls] MPLS client layer over an IGP underlyi… Shahram Davari
- Re: [mpls] poll to see if we have support to make… Xuxiaohu
- Re: [mpls] MPLS client layer over an IGP underlyi… Xuxiaohu
- [mpls] MPLS over L2TP over UDP//re: poll to see i… Xuxiaohu
- Re: [mpls] poll to see if we have support to make… Lucy yong
- Re: [mpls] MPLS client layer over an IGP underlyi… Lucy yong
- Re: [mpls] poll to see if we have support to make… Pat Thaler
- Re: [mpls] poll to see if we have support to make… Pat Thaler
- [mpls] Poll ended - poll to see if we have suppor… Loa Andersson