Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document

From: "Vivek Kumar" <[email-masked]>
Date: Sat, 15 Dec 2012 03:09:36 +0000

I support this draft. 

Regards,
vivek

Date: Fri, 14 Dec 2012 10:01:08 +0100
From: Loa Andersson <[email-masked]>
To: "[email-masked]" <[email-masked]>,
	"[email-masked]"
	<[email-masked]>, 	"[email-masked]"
	<[email-masked]>, 	Martin Vigoureux
	<[email-masked]>
Subject: [mpls] poll to see if we have support to make
	draft-xu-mpls-in-udp an mpls working group document
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

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: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 18 Dec 2012 22:36:14 +0000

Support. 

Linda

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Loa Andersson
> Sent: Friday, December 14, 2012 3:01 AM
> To: [email-masked]; [email-masked]; mpls-
> [email-masked]; Martin Vigoureux
> Subject: [mpls] poll to see if we have support to make draft-xu-mpls-
> in-udp an mpls working group document
> 
> Working group,
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Lizhong Jin <[email-masked]>
Date: Sun, 23 Dec 2012 10:44:57 +0800

Hi all,
I think everyone in this thread is very clear that the solution in this
draft is to target NVO3 scenario. It's meaningless to mix it again and
again with the service provider's network scenario. Agree with Pat, and it
is premature to introduce NVO3 solution at this time, and it is also not
the correct process to bypass NVO3 to do this solution.
BTW, MPLS over UDP is already introduced in PWE3 by using MPLS over L2TP,
and I do not see widely deployment in the service provider's network.

Regards
Lizhong

>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 21 Dec 2012 20:49:29 +0000
> From: "Pat Thaler" <[email-masked]>
> To: "Lucy yong" <[email-masked]>, "Andrew G. Malis"
>         <[email-masked]>,    "Shane Amante" <[email-masked]>
> Cc: "[email-masked]"
>         <[email-masked]>, "[email-masked]"
>         <[email-masked]>,        "[email-masked]"
>         <[email-masked]>
> Subject: Re: [mpls] poll to see if we have support to make
> Message-ID:
>         <
> [email-masked]>
>
> Content-Type: text/plain; charset="gb2312"
>
> Lucy,
>
> If your draft is intended to address the NVO3 requirements, then it should
> be considered in NVO3 along with the other proposed solutions rather than
> bypassing that process by submitting it to MPLS.
>
> The NVO charter requires that the preliminary analysis work be completed
> before completing solutions:
> The NVO3 WG will write the following informational RFCs, which
> must have completed Working Group Last Call before rechartering can be
> considered:
>
> Problem Statement
> Framework document
> Control plane requirements document
> Data plane requirements document
> Operational Requirements
> Gap Analysis
>
> Driven by the requirements and consistent with the gap analysis,
> the NVO3 WG may request being rechartered to document solutions
> consisting of one or more data plane encapsulations and
> control plane protocols as applicable.
>
> Based on the NVO3 charter, it is premature to consider solutions at this
> point and suggesting that something should go forward because it supports
> one item in a draft NVO3 requirements document is not justified.
>
> Regards,
> Pat
>
> Lucy yong
> Sent: Friday, December 21, 2012 11:27 AM
> To: Andrew G. Malis; Shane Amante
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [mpls] poll to see if we have support to make
> Andy,
> Here is the text from draft-ietf-nvo3-dataplane-requirements-00.txt
>
>   3.3.2.1. LAG and ECMP
>
>        For performance reasons, multipath over LAG and ECMP paths SHOULD be
>        supported.
>
>        LAG (Link Aggregation Group) [IEEE 802.1AX-2008] and ECMP (Equal
>        Cost Multi Path) are commonly used techniques to perform load-
>        balancing of microflows over a set of a parallel links either at
>        Layer-2 (LAG) or Layer-3 (ECMP). Existing deployed hardware
>        implementations of LAG and ECMP uses a hash of various fields in the
>         encapsulation (outermost) header(s) (e.g. source and destination
> MAC
>        addresses for non-IP traffic, source and destination IP addresses,
>        L4 protocol, L4 source and destination port numbers, etc).
>        Furthermore, hardware deployed for the underlay network(s) will be
>        most often unaware of the carried, innermost L2 frames or L3 packets
>        transmitted by the TS. Thus, in order to perform fine-grained load-
>        balancing over LAG and ECMP paths in the underlying network, the
>        encapsulation MUST result in sufficient entropy to exercise all
>        paths through several LAG/ECMP hops. The entropy information MAY be
>        inferred from the NVO3 overlay header or underlay header.
>
> Our draft provides an advanced solution in this space.
>
> Lucy
>
> From: [email-masked]<mailto:[email-masked]> [mailto:
> [email-masked]]<mailto:[mailto:[email-masked]]> On Behalf
> Of Andrew G. Malis
> Sent: Friday, December 21, 2012 12:32 PM
> To: Shane Amante
> Cc: [email-masked]<mailto:
> [email-masked]>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>
> Subject: Re: [mpls] poll to see if we have support to make
> I've commented earlier on this draft, and like Shane, I remain unconvinced
> of its utility. I still don't think it has any utility at all for core
> backbone networks - just use native MPLS, or if you must tunnel MPLS over
> IP, the GRE or L2TPv3 encapsulations. Regarding data center applications, I
> guess I could be convinced, but I would like to see a clear justification
> in the form of requirements from nvo3 that could only be met by this draft.
>
> Thanks,
> Andy
>
> On Wed, Dec 19, 2012 at 9:38 AM, Shane Amante <[email-masked]
> <mailto:[email-masked]>> wrote:
> Xiaohu,
>
> On Dec 18, 2012, at 11:50 PM, Xuxiaohu <[email-masked]<mailto:
> [email-masked]>> wrote:
> -----????-----
> >> ???: Shane Amante [mailto:[email-masked]<mailto:
> [email-masked]>]
> >> ????: 2012?12?19? 11:58
> >> ???: Rogers, Josh
> >> ??: Shahram Davari; Xuxiaohu; [email-masked]
> <mailto:[email-masked]>;
> >> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:
> [email-masked]>
> >> ??: Re: [mpls] poll to see if we have support to make
> draft-xu-mpls-in-udp an
> >> On Dec 18, 2012, at 8:50 AM, "Rogers, Josh" <[email-masked]
> <mailto:[email-masked]>>
> >> 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.
>
>
> > 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?
>
> 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).
> 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 ...
> 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" <[email-masked]<mailto:
> [email-masked]>> 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" <[email-masked]<mailto:
> [email-masked]>> 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
> >>>>>
> >>>>>> -----????-----
> >>>>>> ???: [email-masked]<mailto:[email-masked]> [mailto:
> [email-masked]<mailto:[email-masked]>] ??
> >> S.
> >>>>>> Davari
> >>>>>> ????: 2012?12?15? 13:34
> >>>>>> ???: Loa Andersson
> >>>>>> ??: [email-masked]<mailto:
> [email-masked]>; [email-masked]<mailto:[email-masked]>;
> >>>>>> [email-masked]<mailto:[email-masked]>
> >>>>>> ??: Re: [mpls] poll to see if we have support to make
> >>>>>> draft-xu-mpls-in-udp an
> >>>>>> 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 <[email-masked]<mailto:
> [email-masked]>> wrote:
> >>>>>>
> >>>>>>> Working group,
> >>>>>>>
> >>>>>>> group mailing list (mpls at ietf.org<http://ietf.org>). Please
> give an technical
> >>>>>>> Loa Andersson                         email:
> >>>>>> [email-masked]<mailto:[email-masked]>
> >>>>>>> Sr Strategy and Standards Manager            [email-masked]<mailto:
> [email-masked]>
> <tel:%2B46%2010%20717%2052%2013>
> >>>>>>>                                          +46 767 72 92 13
> <tel:%2B46%20767%2072%2092%2013>