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

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,

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

> -----Original Message-----
> 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,
> 
> In my opinion this is a solution to a problem that has a dozen other
> 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
> another solution.
[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
> 
> 
> On Nov 26, 2012, at 12:48 PM, "Daniel King" <[email-masked]> wrote:
> 
> >  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
> >
> >
> > _______________________________________________
> > mpls mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls
> >
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

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

---

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

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表
> Shahram Davari
> 发送时间: 2012年11月30日 2:17
> 收件人: Lucy yong; Daniel King
> 抄送: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> 主题: Re: [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03
> 
> 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

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: Somesh Gupta <[email-masked]>
Date: Thu, 29 Nov 2012 18:08:31 -0800

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.

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.

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
> > > > As requested, I have performed an MPLS-TR review of draft-xu-
> mpls-
> > in-
> > > udp-03:
> > > >
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3

---

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: Melinda Shore <[email-masked]>
Date: Thu, 29 Nov 2012 18:01:57 -0900

On 11/29/12 5:14 PM, S. Davari wrote:
> 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.

Traditionally the IETF has let the market sort out competing
technologies rather than try to deem one "best," but there's
got to be at least some evidence that a technology will be
adopted.  I have to agree that MPLS in data centers is a
tough sell.  It would be great to see some input from data
center operators to help sort this out.

Melinda

---

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
> 

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?

> their adoption by the folks who own the orchestration and management

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

> > > > > 6. General comment on acronyms. The document expands ECMP but
> not
> > > GRE
> > > > or
> > > > >                                               +46 767 72 92
> 13

---

From: Somesh Gupta <[email-masked]>
Date: Thu, 29 Nov 2012 20:23:40 -0800

I think it is inappropriate to start marketing Brocade's products
and comparing their superiority to some other vendor's products.
And it would not make sense for me to explain how our products
fit into today's and tomorrow's data centers and how they will
evolve.

And I agree that the NVE will be located in some instances in
network devices.

And I have raised the issue in nv03 that the control plane in a
software driven data center will be primarily centralized. I was
once again, it seems futilely, hoping for activity that is more
effective.

Regards
Somesh

> Xuxiaohu
> Sent: Thursday, November 29, 2012 7:16 PM
> To: Somesh Gupta; Lucy yong; Shahram Davari; Daniel King
> 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?
>
> 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
> >
> > > > As far as I know data center operators don't like MPLS and that
> is
> > > why
> > > > for your solution before indirectly submitting yet another
> solution
> > > to
> > > > > So I wonder why MPLS WG should spend its valuable time working
> on
> > > yet
> > > > > another solution.
> > > > layer. I don't think that it will take a lot of WG time to work
> out
> > > the
> > > > > On Nov 26, 2012, at 12:48 PM, "Daniel King"
> <[email-masked]>
> > > > wrote:
> > > > >
> > > > > >  Hi All,
> > > > > >
> > > > > > proposed solution is technically sound and given the
> application
> > > of
> > > > > > operational benefits for specific use cases. Therefore I
> believe
> > > > the
> > > > > > 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
> > > > > > 4. Introduction is ok, but the wall of text requires
> splitting
> > > into
> > > > > separate
> > > > > > - 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
> > > > > > with equipment that does not support native MPLS forwarding?
> This
> > > > is
> > > > > > 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
> > > > > > document technically sound?  We are interested in knowing
> whether
> > > > the