Re: [mpls] MPLS client layer over an IGP underlying network

[Lucy yong <[e-mail]>]

Network virtualization overlay is discussed under nvo3 WG. This does not mean that nvo3 WG has to design a new protocol for a underlying network or a new protocol for a overlay network. In fact, people there aim on leverage standard network protocols to accomplish them. IMO: these expansions on an existing standard protocol have to be worked out in the protocol WG group, it should not give nvo3 WG free right to enhance these protocols. For a brand new protocol for network virtualization overlay, nvo3 WG may be the place to start.

Lucy  

> -----Original Message-----
> From: Shahram Davari [mailto:[e-mail]]
> Sent: Thursday, December 20, 2012 10:34 AM
> To: Lucy yong
> Cc: Shane Amante; [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: [mpls] MPLS client layer over an IGP underlying network
> 
> Network virtualization overlay must be discussed and consented  in NVO3
> WG.
> 
> Regards,
> Shahram
> 
> 
> On Dec 20, 2012, at 7:39 AM, "Lucy yong" <[e-mail]> wrote:
> 
> > Hi Shane,
> >
> > I understand operator concern on a new encapsulation to an existing
> network.
> >
> > However, MPLS-in-UDP does not aim on changing existing SP IP/MPLS
> network at all.
> > MPLS-in-UDP is to enable MPLS client layer to be decoupled from MPLS
> server layer and use MPLS client layer as overlay network and an IGP as
> a underlying network for transport. Such application is for DC. You may
> argue why not use the GRE which is for MPLS layer over an IGP underling
> network. We have pointed out in the draft that current routers in DC
> barely support GRE based load balancing and MPLS-in-GRE are barely used
> in SP networks too. Most of routers in DC perform upd port based load
> balancing now.
> >
> > From the architecture perspective, the UDP encapsulation has
> advantage over GRE encapsulation too. In UDP encapsulation, the frame
> header decouples the overlay and underlying network clearly, i.e. outer
> header and overlay header. UDP belongs to outer header, which
> underlying network uses only. However, GRE header has the fields for
> the overlay network and uses the key field for flow entropy. For load
> balancing, it requires the underlying network uses GRE header too. In
> short, GRE ties the overlay and underlying networks together. Since it
> has not used a lot, people are not aware of the disadvantage of such
> coupling.
> >
> > As the industry moves toward network virtualization overlay and
> decouples overlay networks from the underlying network. A clear
> separation of overlay header and underlying header is a "MUST" in my
> opinion. If we count GRE as the overlay header, then for IPv4
> underlying network, there is no field for the flow entropy. This is the
> reason we propose the UDP encapsulation: for an IGP based underlying
> network. In fact, it can support any overlay network beside MPLS client
> layer (e.g. VXLAN, L2TP-in-UDP, etc).
> >
> > You point out using MPLS-in-L2TP-in-UDP instead. Yes, MPLS-in-L2TP-
> in-UDP schema also provides a overlay (L2TP) and underlying (IP)
> network decoupling. L2TP protocol (rfc3931) provides good security
> mechanism and has the embedded control function too. Therefore, someone
> can use it for MPLS client layer over Internet. To have MPLS client
> layer over an IGP underling network, IMO: MPLS-in-L2TP-in-UDP is a
> overkill and too complex. Here we need a schema to support IGP
> underlying transport without touching a overlay header. UDP
> encapsulation is the best choice to accomplish that and minimize the
> changes on existing routers, e.g. change at edge routers, no change on
> transit routers.
> >
> > Regards,
> > Lucy
> >
> >
> >
> >> -----Original Message-----
> >> From: Xuxiaohu [mailto:[e-mail]]
> >> Sent: Thursday, December 20, 2012 4:14 AM
> >> To: Shane Amante
> >> Cc: Rogers, Josh; Shahram Davari; draft-xu-mpls-in-
> [e-mail];
> >> [e-mail]; [e-mail]
> >> Subject: Discussion on how to transport MPLS over UDP tunnels
> >>
> >> 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:[e-mail]]
> >>> 发送时间: 2012年12月19日 22:38
> >>> 收件人: Xuxiaohu
> >>> 抄送: Rogers, Josh; Shahram Davari; draft-xu-mpls-in-
> >> [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
> >>>
> >>> 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; draft-xu-mpls-in-
> >> [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.
> >>
> >> 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" <[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]
> 13
> >>>>>>>>>>                                         [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