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