Subject: Re: [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03

From: "Daniel King" <[email-masked]>
Date: Mon, 26 Nov 2012 20:48:19 -0000

Hi All, 

As requested, I have performed an MPLS-TR review of draft-xu-mpls-in-udp-03:

http://tools.ietf.org/html/draft-xu-mpls-in-udp-03

Overall the document is well written and the motivation seems clear. The
proposed solution is technically sound and given the application of
tunneling of MPLS VPNs across IP PSNs, the mechanism does look to bring
operational benefits for specific use cases. Therefore I believe the
document is ready to be considered for WG adoption.

Authors, 

As I was reviewing the draft I jotted down a number of minor comments, these
are outlined below. Feel free to use or discard. 

1. Authors. The RFC-Editors are requesting no more than 5 authors on the
front-page. So you may as well address this sooner rather than later. You
can look to split into to – Authors and Contributing Authors (or just
Contributors) to circumnavigate the author limit. 

2. You should move the Abstract above the Status of this Memo section. 

3. Perhaps look to expand Abstract to:

Existing technologies to encapsulate MPLS over IP are not adequate for
efficient transport across IP-enabled Packet Switch Networks (PSNs). This
document specifies an IP-based encapsulation technology for load-balancing
MPLS packets across IP PSNs. This mechanism is referred to as MPLS-in-UDP.

This document defines the protocol extensions and procedures for MPLS-in-UDP
and will facilitate transport of MPLS application traffic, including L2VPNs
and L3VPNs, across IP-enabled PSNs. 
<<

4. Introduction is ok, but the wall of text requires splitting into separate
paragraphs for readability. You could split the introduction into sections
(or just additional paragraphs) to help with navigation, no major changes in
text are required:

1. Introduction
- Contains application/motivation background text.
- Intention of the document.  

1.1 Existing Technologies
- Describes existing techniques (RFC4023, et al.).

1.2 Requirements and Motivation
- What the technology or application gaps between prior work and this
proposal. 
- Very important to discuss the motivation given that we already have a
number of alternatives. 

5. The document mentions “core” a number of times. Is this really a core
application or is the mechanism more likely to be applied in environments
with equipment that does not support native MPLS forwarding? This is
something you might want to expand on in Section 6 (Applicability) and
lessen the “core” applicability in other parts of the document. Also, how
applicable is the document to multicast VPNs, any issues? 

6. General comment on acronyms. The document expands ECMP but not GRE or
SAFI, so maybe check document for consistency. 

Please do not hesitate to email me if anything is not clear. 

Br, Dan.

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: Tuesday, November 13, 2012 9:16 AM
To: Gregory Mirsky; Dan King; Eric Osborne (eosborne);
[email-masked]; [email-masked]; Martin Vigoureux;
[email-masked]
Subject: MPLS-RT review of draft-xu-mpls-in-udp-03
 
Greg, Dan, Eric and Nick,
 
You have been selected as an MPLS Review team reviewers for
draft-xu-mpls-in-udp-03.
 
Note to authors: You have been CC'd on this email so that you can know that
this review is going on. However, please do not review your own document.
 
Reviews should comment on whether the document is coherent, is it useful
(ie, is it likely to be actually useful in operational networks), and is the
document technically sound?  We are interested in knowing whether the
document is ready to be considered for WG adoption (ie, it doesn't have to
be perfect at this point, but should be a good start).
 
Reviews should be sent to the document authors, WG co-chairs and secretary,
and CC'd to the MPLS WG email list. If necessary, comments may be sent
privately to only the WG chairs.
 
Are you able to review this draft by November 29, 2012?
 
Thanks, Loa
(as MPLS WG chair)
 
/Loa

-- 

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: Xuxiaohu <[email-masked]>
Date: Tue, 27 Nov 2012 01:37:39 +0000

Hi Daniel,

Thanks a lot for your review and much valuable comments. We will incorporate these comments in the revision.

> applicable is the document to multicast VPNs, any issues?

The " core" here means "IP core networks".  MPLS-in-UDP encapsulation is applicable to mVPN as well just like the MPLS-in-GRE.

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Daniel
> King
> 发送时间: 2012年11月27日 4:48
> 收件人: 'Gregory Mirsky'; 'Loa Andersson'; 'Eric Osborne (eosborne)';
> [email-masked]; [email-masked]; 'Martin Vigoureux';
> 抄送: [email-masked]
> 主题: Re: [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03
> 
>  Hi All,
> 
>                                               +46 767 72 92
> 13
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 27 Nov 2012 05:10:06 +0000

Hi,

In my opinion this is a solution to a problem that has a dozen other solutions such as NVGRE, VXLAN, OTP, STT, etc.

So I wonder why MPLS WG should spend its valuable time working on yet another solution.

Regards,
Shahram

On Nov 26, 2012, at 12:48 PM, "Daniel King" <[email-masked]> wrote:

> can look to split into to - Authors and Contributing Authors (or just
> 5. The document mentions "core" a number of times. Is this really a core
> lessen the "core" applicability in other parts of the document. Also, how

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 27 Nov 2012 06:46:00 +0000

Hi Shahram ,

The MPLS-in-UDP encapsulation is intended to facilitate the load balancing of MPLS-based L2VPN or L3VPN traffic over the IP networks. I think neither of the tunnel encapsulation options you mentioned below is intended to be used as a tunnel technology between the MPLS-based L2VPN or L3VPN PE routers.

Xiaohu

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表
> Shahram Davari
> 发送时间: 2012年11月27日 13:10
> 收件人: Daniel King
> 抄送: [email-masked]; [email-masked];
> [email-masked]

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 27 Nov 2012 14:36:32 +0000

Hi Xiaohu,

The problem you are trying to solve is doing L2VPN or L3VPN over IP with load balancing. And there are technologies that can do that today and are already deployed.

Yes you can also do that with MPLS over UDP over IP. But why not use one of those other ones. Unless you can show that there is major deficiency in other solutions, your solution will add yet another solution to the pack and add to the market confusion.

Regards,
Shahram

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 28 Nov 2012 03:04:08 +0000

> -----邮件原件-----
> 发件人: Shahram Davari [mailto:[email-masked]]
> 发送时间: 2012年11月27日 22:37
> 收件人: Xuxiaohu
> 抄送: Daniel King; [email-masked]; [email-masked];
> The problem you are trying to solve is doing L2VPN or L3VPN over IP with load
> balancing. And there are technologies that can do that today and are already
> deployed.

Hi Shahram,

Could you please explain what the deployed technologies you mentioned above are?

Best regards,
Xiaohu 

> Yes you can also do that with MPLS over UDP over IP. But why not use one of
> those other ones. Unless you can show that there is major deficiency in other
> solutions, your solution will add yet another solution to the pack and add to the
> market confusion.
> 
> Regards,
> Shahram
> 
> 
> > The MPLS-in-UDP encapsulation is intended to facilitate the load balancing of
> MPLS-based L2VPN or L3VPN traffic over the IP networks. I think neither of the
> tunnel encapsulation options you mentioned below is intended to be used as a
> tunnel technology between the MPLS-based L2VPN or L3VPN PE routers.
> >
> > Xiaohu
> >
> >> -----邮件原件-----
> >>> 6. General comment on acronyms. The document expands ECMP but not
> GRE
> >> or

---

From: "S. Davari" <[email-masked]>
Date: Tue, 27 Nov 2012 21:28:48 -0800

VXLAN, NVGRE, OTV, STT.

Regards,
Shahram

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 28 Nov 2012 05:57:44 +0000

It seems that you are talking different things. Here we are explicitly talking about "MPLS-BASED" L2VPN (e.g., BGP or LDP based VPLS) and L3VPN [RFC 4364] technologies where MPLS labels (i.e., VPN labels) are used for identifying different VPN instances.

Best Regards,
Xiaohu
> -----邮件原件-----
> 发件人: S. Davari [mailto:[email-masked]]
> 发送时间: 2012年11月28日 13:29
> 收件人: Xuxiaohu
> 抄送: Shahram Davari; [email-masked]; [email-masked];
> >>>> In my opinion this is a solution to a problem that has a dozen other
> solutions
> >>>> such as NVGRE, VXLAN, OTP, STT, etc.
> >>>>

---

From: "S. Davari" <[email-masked]>
Date: Tue, 27 Nov 2012 22:09:44 -0800

You are obviously not using MPLS for any forwarding. Just using MPLS as VPN identifier. So why use MPLS at all? Just use other identifiers such as those in VXLAN or NVGRE, etc.

Regards,
Shahram

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 28 Nov 2012 07:07:43 +0000

Oh, you are asking a very BIG and disputed question which should be discussed in NVo3, L2VPN and L3VPN WGs, IMHO. 

BTW, somebody else may have the similar doubt: why not use the MPLS label as a VPN identifier? Why use the VN ID in the VXLAN header or the GRE key in the GRE header as a VPN identifier?

Best regards,
Xiaohu

> 发送时间: 2012年11月28日 14:10
> You are obviously not using MPLS for any forwarding. Just using MPLS as VPN
> identifier. So why use MPLS at all? Just use other identifiers such as those in
> VXLAN or NVGRE, etc.

> > It seems that you are talking different things. Here we are explicitly talking
> about "MPLS-BASED" L2VPN (e.g., BGP or LDP based VPLS) and L3VPN [RFC
> 4364] technologies where MPLS labels (i.e., VPN labels) are used for identifying
> different VPN instances.
> >
> > Best Regards,
> > Xiaohu
> >> -----邮件原件-----
> >>>> solutions, your solution will add yet another solution to the pack and add
> to
> >> the
> >>>> market confusion.
> >>>>
> >>>> Regards,
> >>>> Shahram
> >>>>
> >>>>
> >>>>> The MPLS-in-UDP encapsulation is intended to facilitate the load
> balancing
> >> of
> >>>> MPLS-based L2VPN or L3VPN traffic over the IP networks. I think neither
> of
> >> the
> >>>> tunnel encapsulation options you mentioned below is intended to be used
> as
> >> a
> >>>>>> So I wonder why MPLS WG should spend its valuable time working on
> yet
> >>>>>> another solution.
> >>>>>>
> >>>>>> Regards,
> >>>>>> Shahram
> >>>>>>
> >>>>>>
> >>>>>>> As I was reviewing the draft I jotted down a number of minor
> comments,
> >>>>>> these
> >>>>>>> (or just additional paragraphs) to help with navigation, no major
> changes
> >> in
> >>>>>>> text are required:
> >>>>>>>
> >>>>>>> 1. Introduction
> >>>>>>> Note to authors: You have been CC'd on this email so that you can
> know
> >>>> that
> >>>>>>> document is ready to be considered for WG adoption (ie, it doesn't
> have
> >> to

---

From: Lucy yong <[email-masked]>
Date: Thu, 29 Nov 2012 16:33:03 +0000

Hi Shahram,

Let me share my opinion on this. Please see inline.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Shahram Davari
> Sent: Monday, November 26, 2012 11:10 PM
> To: Daniel King
> Cc: [email-masked]; [email-masked]; mpls-
> [email-masked]
> Subject: Re: [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03
> 
> Hi,
> 
> solutions such as NVGRE, VXLAN, OTP, STT, etc.
[Lucy] is any of them standardized? do we want any BIG company to implement one solution ahead and then tell the industry to follow it without going through a standardization? What is the purpose of IETF?

> So I wonder why MPLS WG should spend its valuable time working on yet
[Lucy] IMO: because MPLS and VPN are widely technologies in WAN space. The VPN technology is very close to network virtualization overlay vision in DC except current solution is tied into MPLS implementation slightly, which makes overlay network (MPLS client layer) couples with underlying network (MPLS server layer). DC NVO requires to decouple overlay network from underlying network. We want to leverage VPN technology into DC NVO instead of redesigning a full set of VPN features for DC NVO. 

In fact, the solution is very simple and requires no change to the transit nodes while MPLS client layer can decouple from the MPLS server layer. I don't think that it will take a lot of WG time to work out the solution. If you think that it will, please point out where is the complexity in the solution?

Regards,
Lucy
> changes in
> know that
> have to

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 29 Nov 2012 18:17:26 +0000

Lucy,

As far as I know data center operators don't like MPLS and that is why the core of Data center is mostly IP (or L2) and not MPLS.  As you mentioned there is no standard solution, but there are many de-facto standards such as NVGRE and VXLAN, which are already in silicon.  

I think you should take this argument to NVo3 WG and get their blessing for your solution before indirectly submitting yet another solution to the same problem to MPLS WG.  IETF as a whole should decide on one preferred solution.

Thanks
Shahram

-----Original Message-----
From: Lucy yong [mailto:[email-masked]] 
Sent: Thursday, November 29, 2012 8:33 AM
To: Shahram Davari; Daniel King
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03

Hi Shahram,

Regards,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Thu, 29 Nov 2012 20:21:16 +0000

Shahram,

That is the point. The draft helps to extend VPN solution into DCs for NVO without implementing MPLS in DC. MPLS VPN solution has been standardized and deployed widely for long time. 

Regarding your second point, no matter you like or dislike, it already happens in other WGs. Let's focus on the technical merit here rather than politics.

Lucy  

> Sent: Thursday, November 29, 2012 12:17 PM
> To: Lucy yong; Daniel King
> Cc: [email-masked]; [email-masked]; mpls-
> [email-masked]; [email-masked]
> As far as I know data center operators don't like MPLS and that is why
> the core of Data center is mostly IP (or L2) and not MPLS.  As you
> mentioned there is no standard solution, but there are many de-facto
> standards such as NVGRE and VXLAN, which are already in silicon.
> 
> I think you should take this argument to NVo3 WG and get their blessing
> for your solution before indirectly submitting yet another solution to
> the same problem to MPLS WG.  IETF as a whole should decide on one
> preferred solution.
> 
> 
> 
> Thanks
> Shahram
> 
> 
> 
> [Lucy] is any of them standardized? do we want any BIG company to
> implement one solution ahead and then tell the industry to follow it
> without going through a standardization? What is the purpose of IETF?
> 
> >
> [Lucy] IMO: because MPLS and VPN are widely technologies in WAN space.
> The VPN technology is very close to network virtualization overlay
> vision in DC except current solution is tied into MPLS implementation
> slightly, which makes overlay network (MPLS client layer) couples with
> underlying network (MPLS server layer). DC NVO requires to decouple
> overlay network from underlying network. We want to leverage VPN
> technology into DC NVO instead of redesigning a full set of VPN
> features for DC NVO.
> 
> In fact, the solution is very simple and requires no change to the
> transit nodes while MPLS client layer can decouple from the MPLS server
> layer. I don't think that it will take a lot of WG time to work out the
> solution. If you think that it will, please point out where is the
> complexity in the solution?
> 
> Regards,
> Lucy
> >
> > Regards,
> > Shahram
> >
> >
> > > As requested, I have performed an MPLS-TR review of draft-xu-mpls-
> in-
> > udp-03:
> > >
> > > 1. Authors. The RFC-Editors are requesting no more than 5 authors
> on
> > the
> > > front-page. So you may as well address this sooner rather than
> later.
> > You
> > > and will facilitate transport of MPLS application traffic,
> including
> > L2VPNs
> > > - Very important to discuss the motivation given that we already
> have
> > a
> > > number of alternatives.
> > >
> > > lessen the "core" applicability in other parts of the document.
> Also,
> > how
> > > (ie, is it likely to be actually useful in operational networks),
> and
> > is the

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 30 Nov 2012 01:34:01 +0000

> 发送时间: 2012年11月30日 2:17
> 收件人: Lucy yong; Daniel King
> 抄送: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> As far as I know data center operators don't like MPLS and that is why the core
> of Data center is mostly IP (or L2) and not MPLS.  As you mentioned there is
> no standard solution, but there are many de-facto standards such as NVGRE
> and VXLAN, which are already in silicon.
> 
> I think you should take this argument to NVo3 WG and get their blessing for

Hi Shahram,

You may have noticed that the NVo3 framework and NVo3 data plane requirement drafts both have explicitly stated that the VN context ID can be either a globally unique identifier or a locally significant identifier (e.g., MPLS label). If you have any different opinions on this regard, I suggest you go to the NVo3 WG to express your opinion ASAP ahead of the publication of these two drafts.

Best regards,
Xiaohu

> your solution before indirectly submitting yet another solution to the same
> problem to MPLS WG.  IETF as a whole should decide on one preferred
> solution.
> 
> 
> 
> Thanks
> Shahram
> 
> 
> 
> [Lucy] is any of them standardized? do we want any BIG company to implement
> one solution ahead and then tell the industry to follow it without going through
> a standardization? What is the purpose of IETF?
> 
> >
> [Lucy] IMO: because MPLS and VPN are widely technologies in WAN space. The
> VPN technology is very close to network virtualization overlay vision in DC
> except current solution is tied into MPLS implementation slightly, which makes
> overlay network (MPLS client layer) couples with underlying network (MPLS
> server layer). DC NVO requires to decouple overlay network from underlying
> network. We want to leverage VPN technology into DC NVO instead of
> redesigning a full set of VPN features for DC NVO.
> 
> In fact, the solution is very simple and requires no change to the transit nodes
> while MPLS client layer can decouple from the MPLS server layer. I don't think
> that it will take a lot of WG time to work out the solution. If you think that it will,
> please point out where is the complexity in the solution?
> 
> Regards,
> Lucy
> >
> > Regards,
> > Shahram
> >
> >

---

From: "S. Davari" <[email-masked]>
Date: Thu, 29 Nov 2012 18:14:21 -0800

Lucy,

The problem that I have is that you are trying to standardize a solution to the problem that NVO3 is responsible for in a different WG, without their approval. There are already drafts in NVO3 that address the same problem. 

We should not bypass NVO3 and do anything we like in MPLS WG to solve the NVO problem.  Otherwise how can IETF ensure interoperability when a WG goes and defines and standardizes its own solution. 

Regarding Technical merits, all these solutions are technically sound, the issue is that we don't want to have a dozen solution to the same problem. 

Regards,
Shahram

---

From: "S. Davari" <[email-masked]>
Date: Thu, 29 Nov 2012 18:27:17 -0800

Lucy,

Pls see inline.

Regards,
Shahram

> [Lucy] is any of them standardized? do we want any BIG company to implement one solution ahead and then tell the industry to follow it without going through a standardization? What is the purpose o…
SD] No. They are not standard. However a single IETF Work group (which in my opinion is NVO3) should look at all solutions and select one. We shouldn't try to sneak in other WGs without a general agreement in NVO3 that this is the best solution selected by IETF.

> In fact, the solution is very simple and requires no change to the transit nodes while MPLS client layer can decouple from the MPLS server layer. I don't think that it will take a lot of WG time to…

SD] other solutions also don't require change to transit routers.

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 30 Nov 2012 03:16:06 +0000

Somesh,

> -----邮件原件-----
> 发件人: Somesh Gupta [mailto:[email-masked]]
> 发送时间: 2012年11月30日 10:09
> 收件人: Lucy yong; Shahram Davari; Daniel King
> 主题: RE: [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03
> 
> Standardization that ignores how Software Driven Data Centers will be
> provisioned and managed may be just an academic exercise. The existing
> solution from Nicira, Vmware and Microsoft do point to the general
> direction in which the virtual network solution will move.

As for where is the right location for NVE(Network Virtualization Edge), the current NVo3 WG consensus is the NVE can be located either on network devices or on servers. If you have any different opinion, I suggest you go to the NVo3 to argue for that. By the way, did you doubt about the correctness of Brocade's pursuing of TRILL?

> While some existing networking protocols do provide similar functionality,
> they assume a different operating environment - distributed intelligence,
> autonomous systems, inability to manage centrally.
> 
> The Software Driven Data Center will be centrally provisioned and
> managed. We can come up with the IETF standards, but unless they
> serve that model in a simple manner, we will be disappointed with
> their adoption by the folks who own the orchestration and management
> software.

As for this regard, The NVo3 WG consensus is " A control/management plane entity can be centralized or distributed" (refer to NVo3 framework draft for more details). If you have any different opinion in this regard, I suggest you go to the NVo3 to argue for that as well.

In a word, the above arguments you mentioned is so HUGE that it should be submitted to the NVo3 WG or even the IETF plenary meeting for discussion.

Xiaohu

> Somesh
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > Lucy yong
> > Sent: Thursday, November 29, 2012 12:21 PM
> > Subject: Re: [nvo3] [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03
> >
> > Shahram,
> >
> > That is the point. The draft helps to extend VPN solution into DCs for
> > NVO without implementing MPLS in DC. MPLS VPN solution has been
> > standardized and deployed widely for long time.
> >
> > Regarding your second point, no matter you like or dislike, it already
> > happens in other WGs. Let's focus on the technical merit here rather
> > than politics.
> >
> > Lucy
> >
> > > > From: [email-masked] [mailto:[email-masked]] On
> > Behalf
> > > Of
> > > > Shahram Davari
> > > > > Overall the document is well written and the motivation seems
> > clear.
> > > > The
> > > > > Existing technologies to encapsulate MPLS over IP are not
> > adequate
> > > > for
> > > > > efficient transport across IP-enabled Packet Switch Networks
> > (PSNs).
> > > > This
> > > > > MPLS packets across IP PSNs. This mechanism is referred to as
> > MPLS-
> > > > in-UDP.
> > > > >
> > > > > 4. Introduction is ok, but the wall of text requires splitting
> > into
> > > > separate
> > > > > 5. The document mentions "core" a number of times. Is this really
> > a
> > > > core
> > > > > something you might want to expand on in Section 6
> > (Applicability)
> > > > and
> > nvo3 mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/nvo3

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 30 Nov 2012 12:52:08 +0900

Hi Dan,

On Nov 27, 2012, at 5:48, "Daniel King" <[email-masked]> wrote:

> tunneling of MPLS VPNs across IP PSNs, the mechanism does look to bring operational benefits for specific use cases.

Clear, succinct, technical; free from baggage and politics. Thanks!

I wish I could say the same of the ensuing email thread. As with many threads on this list, I don't know whether to laugh or cry. 

I'll just say this: if MPLS-in-UDP is to be standardized, it should be in this WG. Consulting a WG that has a use case for this technology is fine, but any thought of standardizing it elsewhere should be scotched _now_. 

Kireeti

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 30 Nov 2012 03:58:36 +0000

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 S.
> Davari
> 发送时间: 2012年11月30日 10:27
> 收件人: Lucy yong
> implement one solution ahead and then tell the industry to follow it without
> going through a standardization? What is the purpose of IETF?
> >
> SD] No. They are not standard. However a single IETF Work group (which in my
> opinion is NVO3) should look at all solutions and select one. We shouldn't try to
> sneak in other WGs without a general agreement in NVO3 that this is the best
> solution selected by IETF.

If you have noticed the Section of Applicability in this draft, it has already stated that this MPLS-in-UDP encapsulation can be applicable to any MPLS applications which can be deployed in many other scenarios besides within data centers. 

> The VPN technology is very close to network virtualization overlay vision in DC

Please keep in mind that the context that we are talking about is MPLS_BASED VPN technologies which use MPLS labels rather than anything else for VPN isolation. Please don't waste your valuable time on repeating the confused words again and again. 

Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 30 Nov 2012 04:04:05 +0000

Hi Kireeti,

Many thanks for this fair judgement.

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Kireeti
> Kompella
> 发送时间: 2012年11月30日 11:52
> 收件人: Daniel King
> 抄送: <[email-masked]>; [email-masked];
> <[email-masked]>
> operational benefits for specific use cases.
> 
> I wish I could say the same of the ensuing email thread. As with many threads
> on this list, I don't know whether to laugh or cry.
> 
> I'll just say this: if MPLS-in-UDP is to be standardized, it should be in this WG.
> Consulting a WG that has a use case for this technology is fine, but any thought
> of standardizing it elsewhere should be scotched _now_.
> 
> Kireeti
>

---

From: "S. Davari" <[email-masked]>
Date: Thu, 29 Nov 2012 20:43:56 -0800

I never suggested that this draft be standardized by other WGs. But the main use case is NVO3 and I think they have to agree to the method proposed in this draft, which I'd using VPLS inside UDP.

Regards,
Shahram

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 30 Nov 2012 04:52:00 +0000

Regards,
Shahram

> If you have noticed the Section of Applicability in this draft, it has already stated that this MPLS-in-UDP encapsulation can be applicable to any MPLS applications which can be deployed in many ot…

[SD] In theory all these NVO technologies can be used to provide L2VPN or L3VPN, but in practice it is only used in data centers.

> Please keep in mind that the context that we are talking about is MPLS_BASED VPN technologies which use MPLS labels rather than anything else for VPN isolation. Please don't waste your valuable tim…

[SD] yes the solution to virtualization that you are proposing is MPLS based. But it is one of many possible solutions to same problem. Please don't play with words, we both know the other solutions work well in providing same  function.

---

From: Lucy yong <[email-masked]>
Date: Fri, 30 Nov 2012 15:44:53 +0000

I disagree with this logic. We want moving forward not backward. There is already an evpn proposal for nvo3.(please read two drafts under nvo3). Whether VPLS applicability for DC is for further study and we have not seen any DC operator request yet.  
Lucy 

> S. Davari
> Sent: Thursday, November 29, 2012 10:44 PM
> To: Kireeti Kompella
> Cc: <[email-masked]>; [email-masked]; <mpls-
> [email-masked]>
> I never suggested that this draft be standardized by other WGs. But the
> main use case is NVO3 and I think they have to agree to the method
> proposed in this draft, which I'd using VPLS inside UDP.
> 
> 
> Regards,
> Shahram
> 
> 
> >> tunneling of MPLS VPNs across IP PSNs, the mechanism does look to
> bring operational benefits for specific use cases.
> >
> > I wish I could say the same of the ensuing email thread. As with many
> threads on this list, I don't know whether to laugh or cry.
> >
> > I'll just say this: if MPLS-in-UDP is to be standardized, it should
> be in this WG. Consulting a WG that has a use case for this technology
> is fine, but any thought of standardizing it elsewhere should be
> scotched _now_.
> >
> > Kireeti
> >

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 30 Nov 2012 16:10:10 +0000

Hi

This is my last email on this subject. I let the WG members and chairs decide.

RFC4023 was written in 2005 , when MPLS was not probably in every IP core. Today I haven't seen any core IP network without MPLS, except data centers. So the applicability of RFC4023 and this draft is not service provider network, and applies for major part to data center. 

Regards,
Shahram

---

From: Lucy yong <[email-masked]>
Date: Fri, 30 Nov 2012 16:16:36 +0000

There are DC operators who want EVPN for DCs. Please notice, a lot of network service provider also have DCs and wish to offer cloud services from their DCs. Thus, they should be considered as DC operators as well in this context.

Lucy

> From: Shahram Davari [mailto:[email-masked]]
> Sent: Friday, November 30, 2012 10:10 AM
> To: Lucy yong
> Cc: S. Davari; Kireeti Kompella; <[email-masked]>;
> [email-masked]; <[email-masked]>
> RFC4023 was written in 2005 , when MPLS was not probably in every IP
> core. Today I haven't seen any core IP network without MPLS, except
> data centers. So the applicability of RFC4023 and this draft is not
> service provider network, and applies for major part to data center.
> 
> 
> Regards,
> Shahram
> 
> 
> > I disagree with this logic. We want moving forward not backward.
> There is already an evpn proposal for nvo3.(please read two drafts
> under nvo3). Whether VPLS applicability for DC is for further study and
> we have not seen any DC operator request yet.
> > Lucy
> >