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

From: Loa Andersson <[email-masked]>
Date: Fri, 14 Dec 2012 10:01:08 +0100

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: Lucy yong <[email-masked]>
Date: Fri, 14 Dec 2012 15:56:42 +0000

Support as one of co-authors.

Lucy

> -----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: "S. Davari" <[email-masked]>
Date: Fri, 14 Dec 2012 21:34:18 -0800

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

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 14 Dec 2012 23:52:13 -0800

Support. 

> It seems the authors are trying to bypass the NVO3 solution selection process by advancing the draft in MPLS WG.

That's completely uncalled for. If it's your opinion that this draft has a better fit in the NVO3 WG, just say so.

This draft is about MPLS and should be dealt with in the MPLS WG. That's my opinion, but I'm happy to defer to the WG chairs and ADs.

Kireeti

---

From: Sam Aldrin <[email-masked]>
Date: Sat, 15 Dec 2012 00:13:25 -0800

Support.

-Sam

Sent from my iPad

---

From: Mach Chen <[email-masked]>
Date: Mon, 17 Dec 2012 00:51:17 +0000

Support.

Best regards,
Mach

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa
> Andersson
> Sent: Friday, December 14, 2012 5:01 PM
> To: [email-masked]; [email-masked];
> [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,
>

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 17 Dec 2012 01:23:40 +0000

Support as a co-author.

Xiaohu

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Loa
> Andersson
> 发送时间: 2012年12月14日 17:01
> 收件人: [email-masked]; [email-masked];
> 主题: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 17 Dec 2012 11:35:41 +0530

Support.

On Fri, Dec 14, 2012 at 2:31 PM, Loa Andersson <[email-masked]> wrote:

> https://datatracker.ietf.org/**ipr/1941/<https://datatracker.ietf.org/ipr/1941/>.
>
> ______________________________**_________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/mpls<https://www.ietf.org/mailman/listinfo/mpls>
>

---

From: Nischal Sheth <[email-masked]>
Date: Sun, 16 Dec 2012 22:38:04 -0800

Support as a co-author.

-Nischal

---

From: "Puneet Agarwal" <[email-masked]>
Date: Mon, 17 Dec 2012 20:14:53 +0000

I do not support this draft.

There are already solutions under consideration in nvo3 (vxlan and nvgre) - do not see the need another solution.

Thanks.
 
-Puneet

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Friday, December 14, 2012 1:01 AM
To: [email-masked]; [email-masked]; [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,

/Loa
(mpls wg co-chair)
--

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 18 Dec 2012 04:01:59 +0000

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]] 代表 S.
> Davari
> 发送时间: 2012年12月15日 13:34
> 收件人: Loa Andersson
> 抄送: [email-masked]; [email-masked];
> [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.
>

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 18 Dec 2012 06:31:44 +0000

For service provider domain, MPLS over IP is legacy and there is no need to improve it.

Regards,
Shahram

---

From: "Rogers, Josh" <[email-masked]>
Date: Tue, 18 Dec 2012 10:50:47 -0500

I share your SP perspective, and do not see the problem this solution
addresses in practice any longer.

-Josh

On 12/18/12 12:31 AM, "Shahram Davari" <[email-masked]> wrote:

>> 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.
>>
>>> It seems the authors are trying to bypass the NVO3 solution selection
>>>process
>>> by advancing the draft in MPLS WG.
>>>
>>> Regards,
>>> Shahram
>>>
>>>

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.

---

From: Shane Amante <[email-masked]>
Date: Tue, 18 Dec 2012 20:57:44 -0700

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

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

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

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 19 Dec 2012 06:50:13 +0000

> -----邮件原件-----
> 发件人: Shane Amante [mailto:[email-masked]]
> 发送时间: 2012年12月19日 11:58
> 收件人: Rogers, Josh
> 抄送: Shahram Davari; Xuxiaohu; [email-masked];
> [email-masked]; [email-masked]
> +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.

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

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
> ... to name, but a few.  Those have tended to be quite compelling arguments
> to 'upgrade' network HW to support MPLS encapsulation/switching.
> 
> -shane
> 
> 
> > -Josh
> >
> >
> > 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.

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 19 Dec 2012 07:22:12 +0000

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

By the way, I guess this may also be the motivation for LISP to use UDP as a tunneling technology later (See http://psg.com/lists/rrg/2007/msg00802.html).

Best regards,
Xiaohu

---

From: Loa Andersson <[email-masked]>
Date: Wed, 19 Dec 2012 08:27:28 +0100

Folks,

The working group chairs appreciate discussion on working group drafts
or drafts intended for the working group, plese continue this
discussion!

However the subject line refers to an an ongoing poll, when the
discussion is continued please change the subject line.

/Loa
for the wg chairs

--

---

From: Shane Amante <[email-masked]>
Date: Wed, 19 Dec 2012 07:38:26 -0700

Xiaohu,

On Dec 18, 2012, at 11:50 PM, Xuxiaohu <[email-masked]> wrote:
-----邮件原件-----
> 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

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 20 Dec 2012 10:13:59 +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.

> 发送时间: 2012年12月19日 22:38
> 收件人: Xuxiaohu
> 抄送: Rogers, Josh; Shahram Davari; [email-masked];
> > 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.
> >
> > 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 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.
> 
> 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---
> ... 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
> >

---

From: Lucy yong <[email-masked]>
Date: Thu, 20 Dec 2012 15:38:49 +0000

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 

> From: Xuxiaohu [mailto:[email-masked]]
> Sent: Thursday, December 20, 2012 4:14 AM
> To: Shane Amante
> Cc: Rogers, Josh; Shahram Davari; [email-masked];
> Subject: Discussion on how to transport MPLS over UDP tunnels
> 
> Hi Shane,
> 
> > >> 主题: 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]>
> > >> wrote:
> > >> +1.  Please do not define yet another MPLS-over-IP encapsulation.
> The
> > IETF
> > >> already standardized MPLS over GRE.  The IETF has also
> standardized
> > MPLS
> > >> large operator network that I'm aware of to support carriage of
> L3VPN over
> > an
> > >> IP-only network.
> > >
> > > Hi Shane,
> > >
> > >>     RFC 4665 for requirements related to VPLS that say that VPLS
> may be
> > >> carried over L2TPv3
> Could you please briefly explain how to make the above change in
> EXISTING hardware of already deployed core routers?
> 
> > If this is a concern, then why not encapsulate the traffic in
> MPLS/L2TPv3, which
> > uses UDP/IP, in the first place?
> 
> 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.
> 
> 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
> 
> > >> 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
> > >>>> For service provider domain, MPLS over IP is legacy and there is
> no need
> > >>>> to improve it.
> > >>>>
> > >>>> Regards,
> > >>>> Shahram
> > >>>>
> > >>>>
> > >>>>> tunneling mechanisms should be moved to Historic status, please
> say
> > so.
> > >>>>>
> > >>>>> (http://www.ietf.org/mail-
> archive/web/nvo3/current/msg01864.html) is
> > >>>>>> 发件人: [email-masked] [mailto:[email-masked]] 代
> 表
> > >> S.
> > >>>>>> Davari
> > >>>>>> 发送时间: 2012年12月15日 13:34
> > >>>>>> 收件人: Loa Andersson
> > >>>>>> 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.
> > >>>>>>
> > >>>>>>> However, up to version -03 (the document that we used for the
> IPR
> > >>>>>>> poll)
> > >>>>>>> contact Marshall by other means, to try get a response on the
> IPR
> > >>>>>>> poll.
> > >> copyright belonging to Time Warner Cable. This E-mail is intended
> solely for
> > the
> > >> intended recipient of this E-mail, you are hereby notified that
> any
> > dissemination,

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 20 Dec 2012 16:33:31 +0000

Network virtualization overlay must be discussed and consented  in NVO3 WG.

Regards,
Shahram

On Dec 20, 2012, at 7:39 AM, "Lucy yong" <[email-masked]> wrote:

>> mpls-in-udp an

---

From: Lucy yong <[email-masked]>
Date: Thu, 20 Dec 2012 16:55:24 +0000

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  

> From: Shahram Davari [mailto:[email-masked]]
> Sent: Thursday, December 20, 2012 10:34 AM
> To: Lucy yong
> Cc: Shane Amante; [email-masked]; [email-masked];
> Subject: Re: [mpls] MPLS client layer over an IGP underlying network
> 
> > 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
> >
> >
> >
> >>>>> over L2TPv3/UDP/IP, which had seen some deployment in at least
> one,
> >> very
> >>> AND other drafts, the mechanism of performing hash calculation on
> the
> >> Session
> >>> Further, I suspect that most large network operators are savvy
> folks
> >> and
> >>> supplier(s) to make appropriate changes in their equipment to
> achieve
> >> their
> >>> business goals.  :-)  However, this may not even be necessary ...
> see
> >> below.
> >>
> >>> traffic flows based on the hash of the five-tuple of UDP packets.
> By
> >> using the
> >> If I understand it correctly, you prefer to use MPLS-in-L2TPv3-in-
> UDP
> >> instead of MPLS-in-UDP, right?
> >>
> >>> 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
> >>> "Cookie" fields to ensure the received L2TPv3 packet is intended
> for
> >> the
> >>> ... 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.
> >>> 3) Finally, this approach only affects the end-systems that
> implement
> >> L2TP, for
> >>>>> the most likely reasons this did not pan out was there are
> several,
> >> practical
> >>>>>>>> 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
> >>>>>>>> networks and therefore those existing RFCs related to MPLS
> over
> >> IP
> >>>>> distribution, copying, or action taken in relation to the
> contents
> >> of and

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 20 Dec 2012 17:30:55 +0000

Please don't mix up things. The MPLS protocol design I agree must be done by MPLS WG. But the question is whether your proposal meets the network virtualization requirements. 

The NVO3 task is to document the issues, requirements and framework for NvO3. Then if MPLS over IP looks like a suitable solution that meets the requirements such as the scale, mobility, etc, then they will ask MPLS WG for protocol design.

So before proceeding this draft, I think you should take it to NVO3 WG and convince them this solution meets their requirements and framework. 

We don't want IETF do design N number of solutions for the same problem, do we?

-Shahram

Regards,
Shahram

---

From: Lucy yong <[email-masked]>
Date: Thu, 20 Dec 2012 17:47:55 +0000

IMO: this proposal are well alien with nvo3 framework and data plane requirement.

 http://datatracker.ietf.org/doc/draft-ietf-nvo3-dataplane-requirements/

http://datatracker.ietf.org/doc/draft-ietf-nvo3-framework/

Please let me know if you think this proposal does not fit into nvo3 framework or data plane requirement.

Please also aware there are already two solution draft in nvo3 that can use this approach.

Lucy

> Sent: Thursday, December 20, 2012 11:31 AM
> To: Lucy yong
> Please don't mix up things. The MPLS protocol design I agree must be
> done by MPLS WG. But the question is whether your proposal meets the
> network virtualization requirements.
> 
> The NVO3 task is to document the issues, requirements and framework for
> NvO3. Then if MPLS over IP looks like a suitable solution that meets
> the requirements such as the scale, mobility, etc, then they will ask
> MPLS WG for protocol design.
> 
> So before proceeding this draft, I think you should take it to NVO3 WG
> and convince them this solution meets their requirements and framework.
> 
> > 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
> >
> >> Network virtualization overlay must be discussed and consented  in
> NVO3
> >> WG.
> >>
> >> Regards,
> >> Shahram
> >>
> >>
> >>>>>> Thank you for telling us there are actual deployments of MPLS
> over
> >>>> IP in at
> >>>>> people who had believed there is no application of MPLS over IP
> in
> >>>> today's SP
> >>>>> networks.
> >>>>>>
> >>>>> ID field in the L2TPv3 header or the Key field in the GRE header
> as
> >>>> defined in
> >>>>> 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
> >>>>> 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)
> >>>>> IP-only core.  L2TP end-system implementations would be better
> off
> >>>> just using
> >>>>> incoming packets with the associated L2TP Control Channel.  In
> fact,
> >>>> it's not
> >>>> IMHO, no matter MPLS-in-L2TPv3-in-UDP or MPLS-in-UDP,  the
> hardware
> >> of
> >>>>> 2) There is a substantial added security one gets by using
> "Session
> >>>> ID" and
> >>>>> (There's likely similar language in other drafts that use MPLS
> for
> >>>> transport).
> >>>>>>> ... to name, but a few.  Those have tended to be quite
> compelling
> >>>>> arguments
> >>>>>>>>>> operators who happen to require transporting MPLS
> application
> >>>> traffic
> >>>>>>>>>>>> Please send your comments (support/not support) to the
> mpls
> >>>>> working
> >>>>>>>>>>>> Marshall Eubanks was listed as one of the authors.
> Marshall
> >>>> has
> >>>>>>>>>>>> From version -04 the authors decided to remove Marshall as
> a
> >>>>>>>>>>>> co-author.
> >>>>>>>>>>>>
> >>>>>>>>>>>> /Loa
> >>>>>>>>>>>> (mpls wg co-chair)
> >>>>>>>>>>>> --
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Loa Andersson                         email:
> >>>>>>> use of the individual or entity to which it is addressed. If
> you
> >>>> are not the

---

From: Lucy yong <[email-masked]>
Date: Thu, 20 Dec 2012 17:58:46 +0000

> We don't want IETF do design N number of solutions for the same problem,
[Lucy] Do you see that NVO3 solve the same problem that IETF already solves? 
BTW, I agree that we don't want IETF design N number of solutions for the same problem. Each BOF was controlled by AD very carefully to determine if the target problem is a new problem. The point is that, even a new problem, does not mean we need a brand new protocol to do it. The light expansion of IETF standard protocol to solve the new problem is what we are working on here, which is the way for the network evolution and protocol evolution.

Lucy

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 20 Dec 2012 18:29:37 +0000

Please find inline a couple of technical comments on this additional proposal.

On Dec 20, 2012, at 11:27 AM, Shane Amante <[email-masked]<mailto:[email-masked]>> wrote:

Hi Xiaohu,

On Dec 20, 2012, at 3:13 AM, Xuxiaohu <[email-masked]<mailto:[email-masked]>> wrote:
Hi Shane,

-----邮件原件-----
发件人: Shane Amante [mailto:[email-masked]<mailto:[email-masked]>]
发送时间: 2012年12月19日 22:38
收件人: Xuxiaohu
抄送: Rogers, Josh; Shahram Davari; [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
mpls working group document

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
mpls working group document

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,

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

Firmware upgrades?

If this is a concern, then why not encapsulate the traffic in MPLS/L2TPv3, which
uses UDP/IP, in the first place?

Actually, my first preference would be native MPLS switching edge-to-edge, (which means enabling MPLS throughout the network).  My second preference would be that for the cases where that's impractical to use native MPLS switching end-to-end, then (edge) devices -- not necessarily routers, (see below) -- would have to perform MPLS-in-L2TPv3-in-UDP encapsulation/de-encapsulation.

IP-only core.

You mention RFC 3931 -- L2TPv3 defines L2TP directly over IP (IP Protocol number 115) as a MUST, and L2TP over UDP as a SHOULD. Implementations might not support L2TPv3 over UDP.

http://tools.ietf.org/html/rfc3931#section-4.1

   L2TP may operate over a variety of PSNs.  There are two modes
   described for operation over IP, L2TP directly over IP (see Section<http://tools.ietf.org/html/rfc3931#section-4.1.1>
   4.1.1<http://tools.ietf.org/html/rfc3931#section-4.1.1>) and L2TP over UDP (see Section 4.1.2<http://tools.ietf.org/html/rfc3931#section-4.1.2>).  L2TPv3 implementations
   MUST support L2TP over IP and SHOULD support L2TP over UDP for better
   NAT and firewall traversal, and for easier migration from L2TPv2.

 L2TP end-system implementations would be better off just using

Also, L2TPv3 (over any PSN) uses the Session ID as the session demultiplexer (the Cookie is not a demux):

http://tools.ietf.org/html/rfc3931#page-27

   It is important for implementers to
   note that the Cookie field check occurs after looking up the session
   context by the Session ID, and as such, consists merely of a value
   match of the Cookie field and that stored in the retrieved context.
   There is no need to perform a lookup across the Session ID and Cookie
   as a single value.

And the Session ID associates context with a Session, not with a Control Channel. THe UDP "connection" associates with the Control Connection:
http://tools.ietf.org/html/rfc3931#section-4.1.2.2

I suppose the answer is "it depends" on the HW architecture of PE's -- NPU vs. ASIC -- and whether one needs "PE's" in the traditional sense, as well.  As one example, there is the following open source implementation of L2TP:
http://www.openl2tp.org

Note that the OpenL2TP project implements L2TPv2, RFC2661.

As that Web page notes, OpenL2TP has been integrated into the Linux 2.6.23 kernel.  FWIW, I am aware that Microsoft -- and, other Operating Systems -- have an L2TP stack for several years now, (to support L2TP/IPSec for VPN's), as well.

Regardless, if the main desire for MPLS-over-IP encapsulation is for DataCenters and/or NVO3 ... then, I would think it would be possible to consider /enabling/ OpenL2TP within the Hypervisor of the existing servers, (since they likely already run Linux), and you likely get the best of all worlds: no need to upgrade any "hardware" in the network, just upgrade software (if necessary!) on your servers.  If I were in this situation, that is the direction I would look at, since it seems that such Hypervisor upgrades may be necessary anyway, depending of course on the outcome of the work in NVO3, both in it's choice(s) for data plane encapsulations and "control plane" signaling, as well.

---snip---

Would you care to cite a source for the above assertion that MPLS-in-GRE is far more popular in _deployments_ than MPLS-in-L2TP?

+1.

Regardless, I would note that IETF specifications are only recommendations, based on the knowledge and experience of its participants.  The IETF does not enforce what operators actually deploy in their network.  Operators may make (and, often do make) different choices than what the IETF recommends, because operators understand their networks, services and applications better and the trade-offs and the risks involved.  Specifically, in the context of this discussion, it may be that MPLS-in-GRE is more widely used due to a number of factors.  However, one potential reason that they may use MPLS-in-GRE is it is only used within the confines of a private network (Enterprise LAN/WAN?, IPVPN?), thus the _perception_ of risk of MiTM attacks -- which is the main concern of using MPLS-in-GRE without GRE keys -- is considered by the operator to be "low".  For better or worse, IETF recommendations /need/ to consider all types of networks, e.g.: public and private networks, and thus ha!
ve a tendency to recommend more, rather than less, "security" in those recommendations.

Thus, *if* this WG draft is adopted (and, before it gets sent to the IESG) I think the co-authors should spend some time with the Security Area to understand the concerns they would most certainly raise during the development of this draft or, worse, during the final stages of its publication (IESG review).  :-)  Namely:
1)  In my past experience merely saying that a given protocol is only /supposed to/ be deployed a given environment has not been successful, given the reason I stated above -- you can't predict where a given technology will get deployed due to operators (like me :-) "disobeying" (or, not reading) advice in IETF drafts/RFCs.
2)  The current "Security Considerations" section recommends using IPSec Transport Mode, but lacks sufficient details beyond that, namely:
   a)  IPSec Transport Mode with AH and/or ESP?
   b)  More concerning in the context of this draft is that the way IPSec works will kill the effectiveness of this draft.  Specifically, you may wish to review RFCs 4302 and 4303 (AH and ESP, respectively).  Namely, the way and IPSec Transport Mode packet will look on the wire is as follows, (from Sections 3.1.1 of both RFCs):

                  AFTER APPLYING AH
            -------------------------------------------------------
      IPv4  |original IP hdr (any options) | AH | TCP |    Data   |
            -------------------------------------------------------
            |<- mutable field processing ->|<- immutable fields ->|
            |<----- authenticated except for mutable fields ----->|

                 AFTER APPLYING ESP
            -------------------------------------------------
      IPv4  |orig IP hdr  | ESP |     |      |   ESP   | ESP|
            |(any options)| Hdr | TCP | Data | Trailer | ICV|
            -------------------------------------------------
                                |<---- encryption ---->|
                          |<-------- integrity ------->|

In summary, *when* IPSec Transport Mode is applied, only the outermost 2-tuple {src_ip, dst_ip} will be "readily" visible to intermediate nodes.  Unfortunately, the original (outermost) IP header will have IP protocol 50 or 51 (AH or ESP, respectively) pointing that what immediately follows the IP header is an AH or ESP header ... thus, I would bet (better yet, I *know*) that "existing core routers" will **NOT** inspect the IP header further by attempting to 'skip' past the AH/ESP header and find a TCP/UDP or other Layer-4 header in which it could extract {src_port, dst_port} input-keys to use in it's hash algorithm for LAG/ECMP component-link determination.  Given the whole point of this draft is to allow core routers to inspect the UDP src_port in order to provide substantial 'entropy' to such hash-algorithms and, thus, even distribution of flows over component-links in LAG/ECMP paths ... that's not possible when IPSec (even, Transport mode) will be required to mitigate Se!
curity concerns.

Thanks,

-shane

Thanks,

-- Carlos.

Best regards,
Xiaohu

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

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

Regards,
Shahram

On Dec 14, 2012, at 1:01 AM, Loa Andersson <[email-masked]<mailto:[email-masked]>> wrote:

Working group,

Please send your comments (support/not support) to the mpls
working
group mailing list (mpls at ietf.org<http://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.

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]<mailto:[email-masked]>
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                       +46 767 72 92 13
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 20 Dec 2012 18:37:47 -0000

Hi Lucy,

Can you clarify something for me.
The I-D is pretty open about the use cases. It cites DC interconnect as an
example, but focuses the main motivation as providing entropy in a non-MPLS IP
network that carries MPLS traffic through encapsulation.
Yet in your email below you say: 
> 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.

Now, it is important, in my opinion to understand whether you are attempting to
solve a general MPLS-in-IP entropy problem, or attempting to solve a specific DC
interconnect problem for connectivity over non-MPLS cores. In the former case,
it would not be unreasonable for us to try to work out what the demand is: the
problem is understandable from an academic point of view, but are people
carrying MPLS over IP today, and if so, do they see this problem? In the latter
case, it is sensible to discuss with NVO3 whether this is addressing the DC
interconnect (L3 overlay) problem in a meaningful way.

Thanks,
Adrian

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Lucy
> yong
> Sent: 20 December 2012 15:39
> To: Shane Amante
> Cc: [email-masked]; [email-masked]; mpls-
> [email-masked]
> Subject: [mpls] MPLS client layer over an IGP underlying network
> 
> Hi Shane,
> 
> 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
> 
> 
> 
> > > >>>>>> [email-masked]

---

From: Lucy yong <[email-masked]>
Date: Thu, 20 Dec 2012 19:14:01 +0000

Hi Adrian,

Personally, I do not see that DC interconnection is an application of this yet. To me, using MPLS client layer (e.g. EVPN, IPVPN) inside DC (e.g. IGP) for network virtualization overlay is the potential application of this.

Personally, I have not seen a request from service provider who want MPLS over WAN IP in general. Other co-authors may have. Whether this is applicable for DC interconnection, I first ask why do it, if Service providers have deployed IP/MPLS transport networks in WAN, what is wrong to use it for DC interconnection? In fact, this is what SPs do today. 

Something I can foresee is that a service provider may also have Data Centers, or DC providers have some a WAN network, in this case, if they want both networks use the same underlying network and overlay network mechanism. This can provide a general solution for this area. Again, this is my view, not from a service provider or DC provider.

In short, the potential application I think is different from two you point out here (or the draft state). I'll work with co-authors on that.

Thanks,
Lucy 

> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Thursday, December 20, 2012 12:38 PM
> To: Lucy yong
> Cc: [email-masked]; [email-masked]
> Subject: RE: [mpls] MPLS client layer over an IGP underlying network
> 
> Hi Lucy,
> 
> > However, MPLS-in-UDP does not aim on changing existing SP IP/MPLS
> network at
> > all.
> server
> advantage over
> decouples
> in-UDP
> changes
> > > > >>>>> just the right thread suitable for you to make the
> following
> > > argument
> > > > >>>>>> It seems the authors are trying to bypass the NVO3
> solution
> > > selection
> > > > >>>>>> process
> > > > >>>>>>> Due to the holiday season this poll has been extended
> with
> > > one week.
> > > > >>>>>>>
> > > > >>>>>>> motivation for your support/not support, especially if
> you
> > > think that
> > > > >>>>>>> that they are not aware of any other IPR claims than
> those
> > > already
> > > > >>>>>>> disclosed.
> > > > >>>>>>>
> > > > >>>>>>> discontinued all interactions with the IETF, including
> the
> > > author team
> > > > >>> This E-mail and any of its attachments may contain Time
> Warner
> > > Cable
> > > > >> permanently delete the original and any copy of this E-mail
> and
> > > any printout.

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 21 Dec 2012 01:44:49 +0000

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表
> Shahram Davari
> 发送时间: 2012年12月21日 0:34
> 收件人: Lucy yong
> 抄送: [email-masked]; [email-masked];
> [email-masked]
> 主题: Re: [mpls] MPLS client layer over an IGP underlying network
> 

If so, can you tell us what L2VPN, L3VPN and even PWE3 WGs have done before?
 
Xiaohu

> network at all.
> 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.
> >
> 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).
> >
> 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
> >
> >
> >
> >>>>>>>>>>                                         +46 767 72 92
> 13

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 21 Dec 2012 01:56:23 +0000

> 发送时间: 2012年12月21日 1:31
> Please don't mix up things. The MPLS protocol design I agree must be done by
> MPLS WG. But the question is whether your proposal meets the network
> virtualization requirements.

Can you tell us where MPLS-in-GRE/IP [RFC4023] and other MPLS over IP encapsulation mechanisms have been discussed before?

Since MPLS-in-UDP is just intended to be used in the scenarios where MPLS-in-GRE/IP has been used and is to be used, MPLS-in-UDP should be discussed in the same WG where MPLS-in-GRE/IP has been discussed.

Xiaohu

> NvO3. Then if MPLS over IP looks like a suitable solution that meets the
> requirements such as the scale, mobility, etc, then they will ask MPLS WG for
> protocol design.
> 
> So before proceeding this draft, I think you should take it to NVO3 WG and
> convince them this solution meets their requirements and framework.
> 
> > 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
> >
> >>>>>>>>>>>> Ericsson Inc                          phone: +46 10 717
> 52
> >> 13
> >>>>>>>>>>>>                                        +46 767 72 92
> 13

---

From: "S. Davari" <[email-masked]>
Date: Fri, 21 Dec 2012 00:10:03 -0800 (PST)

Hi,

I think we are in a vicious cycle. Could you please clarify which network operator is asking for MPLS over UDP and what is the application.  Also how do you plan to address the MPLS Multicast (which is probably more important than improving the load balancing), given that RFC4023 does not support Multicast.

Thanks,
Shahram

________________________________
 From: Xuxiaohu <[email-masked]>
To: Shahram Davari <[email-masked]>; Lucy yong <[email-masked]> 
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Thursday, December 20, 2012 5:56:23 PM
Subject: Re: [mpls] MPLS client layer over an IGP underlying network

Xiaohu

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 21 Dec 2012 13:32:13 -0500

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]> wrote:

> > 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.
> >
> > 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.
>
> 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.
>
> 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---
> ... 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
> >
> solely for the

---

From: Lucy yong <[email-masked]>
Date: Fri, 21 Dec 2012 19:27:28 +0000

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]] On Behalf Of Andrew G. Malis
Sent: Friday, December 21, 2012 12:32 PM
To: Shane Amante
Cc: [email-masked]; [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Xiaohu,

---snip---

-shane

>>> On 12/18/12 12:31 AM, "Shahram Davari" <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>> On Dec 17, 2012, at 8:02 PM, "Xuxiaohu" <[email-masked]<mailto:[email-masked]>> wrote:
>>>>
>>>>> Shahram,
>>>>>
>>>>>>> Sr Strategy and Standards Manager            [email-masked]<mailto:[email-masked]>
>>>>>>> Ericsson Inc                          phone: +46 10 717 52 13<tel:%2B46%2010%20717%2052%2013>
>>>>>>>                                          +46 767 72 92 13<tel:%2B46%20767%2072%2092%2013>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 21 Dec 2012 14:52:59 -0500

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 <[email-masked]> 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 ****
>
> ****
>        L4 protocol, L4 source and destination port numbers, etc). ****
>
> ****
>        most often unaware of the carried, innermost L2 frames or L3
> packets ****
>
> ****
>        balancing over LAG and ECMP paths in the underlying network, the **
> **
>
>        encapsulation MUST result in sufficient entropy to exercise all ***
> *
>
> ****
>        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]] *On Behalf
> Of *Andrew G. Malis
> *Sent:* Friday, December 21, 2012 12:32 PM
> *To:* Shane Amante
> *Cc:* [email-masked]; [email-masked];
> *Subject:* Re: [mpls] poll to see if we have support to make
> draft-xu-mpls-in-udp an mpls working group document****
>
> ** **
>
> Andy****
> ** **
> On Wed, Dec 19, 2012 at 9:38 AM, Shane Amante <[email-masked]>
> wrote:****
>
> Xiaohu,****
>
>
> far.****
> this may not even be necessary ... see below.****
>
>
>
> any change to them. That is the major motivation of this draft.****
>
> -shane****
> https://www.ietf.org/mailman/listinfo/mpls****
>
> ** **
>

---

From: "Pat Thaler" <[email-masked]>
Date: Fri, 21 Dec 2012 20:49:29 +0000

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of 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 draft-xu-mpls-in-udp an mpls working group document

Andy,

  3.3.2.1. LAG and ECMP

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 draft-xu-mpls-in-udp an mpls working group document

Thanks,
Andy

---snip---

-shane

---

From: Lucy yong <[email-masked]>
Date: Fri, 21 Dec 2012 21:38:05 +0000

Yes, but require either implement L2TP overlay or to update all the network devices.

Lucy

From: Andrew G. Malis [mailto:[email-masked]]
Sent: Friday, December 21, 2012 1:53 PM
To: Lucy yong
Cc: Shane Amante; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document

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 <[email-masked]<mailto:[email-masked]>> wrote:
Andy,

  3.3.2.1. LAG and ECMP

Lucy

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<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 draft-xu-mpls-in-udp an mpls working group document

Thanks,
Andy

---snip---

-shane

---

From: Lucy yong <[email-masked]>
Date: Fri, 21 Dec 2012 21:55:10 +0000

Shahram,

Please see inline.

From: S. Davari [mailto:[email-masked]]
Sent: Friday, December 21, 2012 2:10 AM
To: Xuxiaohu; Shahram Davari; Lucy yong
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] MPLS client layer over an IGP underlying network

Hi,

I think we are in a vicious cycle. Could you please clarify which network operator is asking for MPLS over UDP and what is the application.
[Lucy] it is indicated in the draft.
Also how do you plan to address the MPLS Multicast (which is probably more important than improving the load balancing), given that RFC4023 does not support Multicast.
[Lucy] MPLS Client Layer is responsible to map multicast traffic to underlying transport, which is specified in EVPN and IP VPN. This proposal just requests ingress PE to fill the flow entropy into UDP source port, in which the flow can be unicast or multicast.

Regards,
Lucy

Thanks,
Shahram

> 抄送: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;

Xiaohu

> On Dec 20, 2012, at 8:56 AM, "Lucy yong" <[email-masked]<mailto:[email-masked]>> wrote:
>
> >> From: Shahram Davari [mailto:[email-masked]<mailto:[email-masked]>]
> >> Cc: Shane Amante; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> >> On Dec 20, 2012, at 7:39 AM, "Lucy yong" <[email-masked]<mailto:[email-masked]>> wrote:
> >>
> >>> Hi Shane,
> >>>
> >>>> From: Xuxiaohu [mailto:[email-masked]<mailto:[email-masked]>]
> >>>> Cc: Rogers, Josh; Shahram Davari; draft-xu-mpls-in-
> >> [email-masked]<mailto:[email-masked]>;
> >>>>> 抄送: Rogers, Josh; Shahram Davari; draft-xu-mpls-in-
> >>>> [email-masked]<mailto:[email-masked]>;
> >>>>>>> 抄送: Shahram Davari; Xuxiaohu; draft-xu-mpls-in-
> >>>> [email-masked]<mailto:[email-masked]>;
> >>>> <[email-masked]<mailto:[email-masked]>>
> >>>>>>> wrote:
> >>>>>>>>>>> 发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
> >> 代
> >>>> 表
> >>>>>>> S.
> >>>>>>>>>>> Davari
> >>>>>>>>>>> 发送时间: 2012年12月15日 13:34
> >>>>>>>>>>> 收件人: Loa Andersson

---

From: "S. Davari" <[email-masked]>
Date: Fri, 21 Dec 2012 14:40:21 -0800 (PST)

Lucy,

I can only see China Telecom as co-author, and the Applicability section says L2VPN and L3VPN. So is China Telecom using it for their Enterprise VPN service? but your earlier emails suggests that this is not the intended usage rather it is for Data Center. So which one is it? Why isn't China Telecom speaking on the list and explaining their usage model?

Also regarding Multicast, this means you need to map Multicast traffic to P2P PW, which is inferior to other methods such as NVGRE and VXLAN since they natively support efficient Multicast.

Thanks,
Shahram

________________________________
 From: Lucy yong <[email-masked]>
To: S. Davari <[email-masked]>; Xuxiaohu <[email-masked]>; Shahram Davari <[email-masked]> 
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Friday, December 21, 2012 1:55:10 PM
Subject: RE: [mpls] MPLS client layer over an IGP underlying network

Shahram,
 
Please see inline.
 
From:S. Davari [mailto:[email-masked]] 
 
Hi,

Regards,
Lucy

Thanks,
Shahram

From:Xuxiaohu <[email-masked]>

> 发送时间: 2012年12月21日1:31

Xiaohu

> >> [email-masked];
> >>>>> 发送时间: 2012年12月19日22:38
> >>>> [email-masked];
> >>>>>>> 发送时间: 2012年12月19日11:58
> >>>> [email-masked];
> >>>>>>>>>>> 发送时间: 2012年12月15日13:34

---

From: Lizhenbin <[email-masked]>
Date: Sat, 22 Dec 2012 03:46:04 +0000

Support as a co-author

Zhenbin

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Loa Andersson
发送时间: 2012年12月14日 17:01
收件人: [email-masked]; [email-masked]; [email-masked]; Martin Vigoureux
主题: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document

Working group,

/Loa
(mpls wg co-chair)
--

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 24 Dec 2012 02:30:59 +0000

发件人: S. Davari [mailto:[email-masked]]
发送时间: 2012年12月22日 6:40
收件人: Lucy yong; Xuxiaohu; Shahram Davari
抄送: [email-masked]; [email-masked]; [email-masked]
主题: Re: [mpls] MPLS client layer over an IGP underlying network

Lucy,

[Xiaohu] Yes, the Applicability section says L2VPN and L3VPN, but there is no limit that these technologies could only be used by service providers?  Enterprises themselves could adopt these technologies to interconnect their multiple sites and data center operators could use them within or even across data centers as well if they would like. Let me iterate that MPLS-based VPN over IP can be used in SP networks, enterprise networks and even data centers and therefore MPLS-in-UDP is applicable to any of the above scenario as well.

[Xiaohu] First, remember that MPLS-in-UDP is not only suitable for MPLS-based L2VPN but also suitable for L3VPN. Second, MPLS-based VPN can support both ingress replication mode and multicast tree mode.

Thanks,
Shahram

Shahram,

Please see inline.

Hi,

Regards,
Lucy

Thanks,
Shahram

Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 24 Dec 2012 02:38:59 +0000

Hi Pat,

This MPLS-in-UDP technology is intended to be used in the scenarios where existing MPLS over IP technologies (e.g., MPLS over GRE) have been used and are to be used. Data center is just one scenario but not the only one.

Xiaohu

发件人: Pat Thaler [mailto:[email-masked]]
发送时间: 2012年12月22日 4:49
收件人: Lucy yong; Andrew G. Malis; Shane Amante
抄送: [email-masked]; [email-masked]; [email-masked]
主题: RE: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document

Lucy,

Problem Statement
Framework document

Regards,
Pat

Andy,

  3.3.2.1. LAG and ECMP

Lucy

Thanks,
Andy

---snip---

-shane

---

From: "Shahram Davari" <[email-masked]>
Date: Mon, 24 Dec 2012 02:46:46 +0000

MPLS based VPN supports multicast Tree, but only when Transport is MPLS and not IP. MPLS over IP does not support Multicast tree.

Regards,
Shahram

On Dec 23, 2012, at 6:32 PM, "Xuxiaohu" <[email-masked]<mailto:[email-masked]>> wrote:

发件人: S. Davari [mailto:[email-masked]]
发送时间: 2012年12月22日 6:40
收件人: Lucy yong; Xuxiaohu; Shahram Davari
抄送: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: Re: [mpls] MPLS client layer over an IGP underlying network

Lucy,

[Xiaohu] First, remember that MPLS-in-UDP is not only suitable for MPLS-based L2VPN but also suitable for L3VPN. Second, MPLS-based VPN can support both ingress replication mode and multicast tree mod

Thanks,
Shahram

________________________________
From: Lucy yong <[email-masked]<mailto:[email-masked]>>
To: S. Davari <[email-masked]<mailto:[email-masked]>>; Xuxiaohu <[email-masked]<mailto:[email-masked]>>; Shahram Davari <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Friday, December 21, 2012 1:55:10 PM
Subject: RE: [mpls] MPLS client layer over an IGP underlying network

Shahram,

Please see inline.

Hi,

Regards,
Lucy

Thanks,
Shahram

________________________________
From: Xuxiaohu <[email-masked]<mailto:[email-masked]>>
To: Shahram Davari <[email-masked]<mailto:[email-masked]>>; Lucy yong <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, December 20, 2012 5:56:23 PM
Subject: Re: [mpls] MPLS client layer over an IGP underlying network

Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 24 Dec 2012 02:53:39 +0000

Hi Andy,

As discussed before, “performing hash calculation on the "load-balancing" field contained in the tunnel encapsulation headers (i.e., the Session ID field in the L2TPv3 header or the Key field in the GRE header) means a non-trivial change to the date plane of many existing core routers and therefore not widely supported by most existing core routers yet.”

By the way, you may has missed a previous comment made by Carlos (see http://www.ietf.org/mail-archive/web/mpls/current/msg09258.html), it said “You mention RFC 3931 -- L2TPv3 defines L2TP directly over IP (IP Protocol number 115) as a MUST, and L2TP over UDP as a SHOULD. Implementations might not support L2TPv3 over UDP.”

Best regards,
Xiaohu

发件人: [email-masked] [mailto:[email-masked]] 代表 Andrew G. Malis
发送时间: 2012年12月22日 3:53
收件人: Lucy yong
抄送: [email-masked]; [email-masked]; [email-masked]
主题: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document

Lucy,

  3.3.2.1. LAG and ECMP

Lucy

Thanks,
Andy

---snip---

-shane

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 24 Dec 2012 03:12:06 +0000

It seems that you are struggling to fight against any MPLS over IP encapsulation method, but not just MPLS-in-UDP. If you do believe there is no application of any MPLS over IP encapsulation method, the best thing to do is to request moving all existing MPLS over IP related RFCs to Historic status.

Xiaohu

发件人: Shahram Davari [mailto:[email-masked]]
发送时间: 2012年12月24日 10:47
收件人: Xuxiaohu
抄送: S. Davari; Lucy yong; [email-masked]; [email-masked]; [email-masked]
主题: Re: [mpls] MPLS client layer over an IGP underlying network

Regards,
Shahram

Lucy,

Thanks,
Shahram

Shahram,

Please see inline.

Hi,

Regards,
Lucy

Thanks,
Shahram

Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 24 Dec 2012 10:17:51 +0000

Hi Andy,

By the way, according to the following statement quoted from L2TPv3 specification [RFC3931], it seems that the UDP ports in the MPLS over L2TP over UDP case are not sufficient for fine-grained load-balancing.
4.1.2.2<http://tools.ietf.org/html/rfc3931#section-4.1.2.2>.  UDP Port Selection

   The method for UDP Port Selection defined in this section is
   identical to that defined for L2TPv2 [RFC2661<http://tools.ietf.org/html/rfc2661>].

   When negotiating a control connection over UDP, control messages MUST
   be sent as UDP datagrams using the registered UDP port 1701
   [RFC1700<http://tools.ietf.org/html/rfc1700>].  The initiator of an L2TP control connection picks an
   available source UDP port (which may or may not be 1701) and sends to
   the desired destination address at port 1701.  The recipient picks a
   free port on its own system (which may or may not be 1701) and sends
   its reply to the initiator's UDP port and address, setting its own
   source port to the free port it found.

Lau, et al.                 Standards Track                    [Page 19]
<http://tools.ietf.org/html/rfc3931#page-20>
RFC 3931<http://tools.ietf.org/html/rfc3931>                         L2TPv3                       March 2005

   Any subsequent traffic associated with this control connection
   (either control traffic or data traffic from a session established
   through this control connection) must use these same UDP ports.

Best regards,
Xiaohu

发件人: Xuxiaohu
发送时间: 2012年12月24日 10:53
收件人: 'Andrew G. Malis'; Lucy yong
抄送: [email-masked]; [email-masked]; [email-masked]
主题: re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document

Hi Andy,

Best regards,
Xiaohu

Lucy,

  3.3.2.1. LAG and ECMP

Lucy

Thanks,
Andy

---snip---

-shane

---

From: Lucy yong <[email-masked]>
Date: Wed, 26 Dec 2012 15:08:40 +0000

Hi Pat,

It is fair to point out this, and it is my bad to bring NVO3 up in this thread. Given current NVO3 chartered task, the applicability of this to nvo3 is for further study.

However, both L2VPN and L3VPN WG are working on the IP VPN and EVPN extensions into DC for multi-tenancy and several major operators and vendors are interested in and working on it now. As part of the extension work, both IP VPN and EVPN extension proposals state the need to let BGP/MPLS based VPN over an common IP underlying infrastructure instead of using MPLS server layer, i.e. LSP tunnel, since the MPLS based core switch is barely used in DCs. Based on current available standard, these proposals recommend to use GRE encapsulation. But today DC switches/routers do not support GRE based load balancing. DC traffic is mainly generated by the hosts that supports TCP/UDP. Thus  DC switches commonly support UDP based load balancing. Therefore, this draft proposes an advanced encapsulation, which can apply to the IP VPN and EVPN extension in data centers and minimize the changes in DC infrastructure.

Regards,
Lucy

From: Pat Thaler [mailto:[email-masked]]
Sent: Friday, December 21, 2012 2:49 PM
To: Lucy yong; Andrew G. Malis; Shane Amante
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document

Lucy,

Problem Statement
Framework document

Regards,
Pat

Andy,

  3.3.2.1. LAG and ECMP

Lucy

Thanks,
Andy

---snip---

-shane

---

From: Lucy yong <[email-masked]>
Date: Wed, 26 Dec 2012 16:01:44 +0000

Shahram,

From: S. Davari [mailto:[email-masked]]
Sent: Friday, December 21, 2012 4:40 PM
To: Lucy yong; Xuxiaohu; Shahram Davari
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] MPLS client layer over an IGP underlying network

Lucy,

I can only see China Telecom as co-author, and the Applicability section says L2VPN and L3VPN. So is China Telecom using it for their Enterprise VPN service? but your earlier emails suggests that this is not the intended usage rather it is for Data Center. So which one is it? Why isn't China Telecom speaking on the list and explaining their usage model?
[Lucy] China Telecom is also a DC provider now and offer various cloud services through their DCs. If you are interested in, please contact the operator directly.

Also regarding Multicast, this means you need to map Multicast traffic to P2P PW, which is inferior to other methods such as NVGRE and VXLAN since they natively support efficient Multicast.
[Lucy] both IPVPN and EVPN do not use PW at all and both proposals give options for multicast traffic. I don’t know what you mean that NVGRE and VXLAN natively support efficient multicast. Please explain.
Thanks,
Lucy

Thanks,
Shahram

Shahram,

Please see inline.

Hi,

Regards,
Lucy

Thanks,
Shahram

Xiaohu