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

["Andrew G. Malis" <[e-mail]>]

Lucy,

Sure, but it could be satisfied by MPLS over L2TP over UDP, or hashing on
the GRE key for MPLS over GRE.

Cheers,
Andy


On Fri, Dec 21, 2012 at 2:27 PM, Lucy yong <[e-mail]> wrote:

>  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:* [e-mail] [mailto:[e-mail]] *On Behalf
> Of *Andrew G. Malis
> *Sent:* Friday, December 21, 2012 12:32 PM
> *To:* Shane Amante
> *Cc:* [e-mail]; [e-mail];
> [e-mail]
> *Subject:* Re: [mpls] poll to see if we have support to make
> draft-xu-mpls-in-udp an mpls working group document****
>
> ** **
>
> 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 <[e-mail]>
> wrote:****
>
> Xiaohu,****
>
>
> On Dec 18, 2012, at 11:50 PM, Xuxiaohu <[e-mail]> wrote:
> -----邮件原件-----
> >> 发件人: Shane Amante [mailto:[e-mail]]
> >> 发送时间: 2012年12月19日 11:58
> >> 收件人: Rogers, Josh
> >> 抄送: Shahram Davari; Xuxiaohu; [e-mail];
> >> [e-mail]; [e-mail]
> >> 主题: 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" <[e-mail]>
> >> 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" <[e-mail]> 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" <[e-mail]> 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
> >>>>>
> >>>>>> -----邮件原件-----
> >>>>>> 发件人: [e-mail] [mailto:[e-mail]] 代表
> >> S.
> >>>>>> Davari
> >>>>>> 发送时间: 2012年12月15日 13:34
> >>>>>> 收件人: Loa Andersson
> >>>>>> 抄送: [e-mail]; [e-mail];
> >>>>>> [e-mail]
> >>>>>> 主题: 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 <[e-mail]> 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:
> >>>>>> [e-mail]
> >>>>>>> Sr Strategy and Standards Manager            [e-mail]
> >>>>>>> Ericsson Inc                          phone: [phone]
> >>>>>>>                                          [phone]
> >>>>>>> _______________________________________________
> >>>>>>> mpls mailing list
> >>>>>>> [e-mail]
> >>>>>>> https://www.ietf.org/mailman/listinfo/mpls
> >>>>>> _______________________________________________
> >>>>>> mpls mailing list
> >>>>>> [e-mail]
> >>>>>> https://www.ietf.org/mailman/listinfo/mpls
> >>>>> _______________________________________________
> >>>>> mpls mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/mpls
> >>>> _______________________________________________
> >>>> mpls mailing list
> >>>> [e-mail]
> >>>> 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
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/mpls
> >>
> >
>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls****
>
> ** **
>