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

From: Aldrin Isaac <[email-masked]>
Date: Sun, 9 Dec 2012 00:51:56 -0500

Historically there really was no MPLS enabled products that hit the right
price points and/or features needed for the DC -- but some of us operators
*have* implemented MPLS in the DC very successfully.  My observation is
that some vendors don't do MPLS/MPBGP very well and aggressively discourage
its adoption, while other vendors reserve them for their SP products for
which they  need reasons to charge a premium.  Now with support for MPLS in
merchant silicon, I don't see any good reason why MPLS-based DCVPN
solutions (IPVPN, E-VPN) should be held back, particularly if the overlay
tunnel is IP-based and MPLS labels are used for VPN context, split-horizon,
etc.

On Thursday, November 29, 2012, Melinda Shore wrote:

> 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
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Sun, 9 Dec 2012 19:04:50 +0000

Hi Aldrin,

I agree with your statements on the application of MPLS and MPLSoIP in DC network, but my question is that do we need yet another new encapsulation. As you know and worked with us, we have successfully shown how E-VPN control-plane can be applied to VXLAN and NVGRE data-plane even without MPLS client layer and still maintaining the features/functionality in E-VPN. We also currently have a standard based for doing MPLSoIP using GRE encap and keeping MPLS client layer intact. So, in light of the above, do we need another encap?

At one point I was myself thinking of MPLSoUPD but considering that any new silicons that support NVGRE also will  support ECMP based on GRE key, I cannot justify another new encap anymore.

Cheers,
Ali

From: Aldrin Isaac <[email-masked]<mailto:[email-masked]>>
Date: Saturday, December 8, 2012 9:51 PM
To: Melinda Shore <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03

Historically there really was no MPLS enabled products that hit the right price points and/or features needed for the DC -- but some of us operators *have* implemented MPLS in the DC very successfully.  My observation is that some vendors don't do MPLS/MPBGP very well and aggressively discourage its adoption, while other vendors reserve them for their SP products for which they  need reasons to charge a premium.  Now with support for MPLS in merchant silicon, I don't see any good reason why MPLS-based DCVPN solutions (IPVPN, E-VPN) should be held back, particularly if the overlay tunnel is IP-based and MPLS labels are used for VPN context, split-horizon, etc.

Melinda

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 9 Dec 2012 20:06:20 +0100

Aldirn,

> Now with support for MPLS in merchant silicon, I don't see any good reason
> why MPLS-based DCVPN solutions (IPVPN, E-VPN) should be held back

For service demux I see no issue as well

For transport I see two major issues:

- MPLS requires new signalling protocol ... DC fabric and hosts which
do act as PEs should be as simple as possible, but not simpler hence
introduction of LDP or worse RSVP-TE to signal the labels seems not
helpful.

- MPLS FECs can not be summarized. With IP we just need information
how to reach subnet X ... with MPLS (even if one would provide the
relaxed match) FECs are still /32s That's a lot of them in large data
centers.

Cheers,
R.

---

From: Aldrin Isaac <[email-masked]>
Date: Sun, 9 Dec 2012 17:29:40 -0500

Hi Ali,

I agree that new encapsulations are not ideal unless they clearly supersede
existing encapsulations.  My comments are purely about the applicability
of MPLS-based VPN for scalable and robust network virtualization in the DC.

Best regards -- aldrin

On Sunday, December 9, 2012, Ali Sajassi (sajassi) wrote:

>
>  Hi Aldrin,
>
>  I agree with your statements on the application of MPLS and MPLSoIP in
> DC network, but my question is that do we need yet another new
> encapsulation. As you know and worked with us, we have successfully shown
> how E-VPN control-plane can be applied to VXLAN and NVGRE data-plane even
> without MPLS client layer and still maintaining the features/functionality
> in E-VPN. We also currently have a standard based for doing MPLSoIP using
> GRE encap and keeping MPLS client layer intact. So, in light of the above,
> do we need another encap?
>
>  At one point I was myself thinking of MPLSoUPD but considering that any
> new silicons that support NVGRE also will  support ECMP based on GRE key, I
> cannot justify another new encap anymore.
>
>  Cheers,
> Ali
>
>   From: Aldrin Isaac <[email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>>
> To: Melinda Shore <[email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>>
> Cc: "[email-masked] <javascript:_e({}, 'cvml', [email-masked]');>" <
> [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>>
>  Historically there really was no MPLS enabled products that hit the
> right price points and/or features needed for the DC -- but some of us
> operators *have* implemented MPLS in the DC very successfully.  My
> observation is that some vendors don't do MPLS/MPBGP very well and
> aggressively discourage its adoption, while other vendors reserve them for
> their SP products for which they  need reasons to charge a premium.  Now
> with support for MPLS in merchant silicon, I don't see any good reason why
> MPLS-based DCVPN solutions (IPVPN, E-VPN) should be held back, particularly
> if the overlay tunnel is IP-based and MPLS labels are used for VPN context,
> split-horizon, etc.
>
>

---

From: Kireeti Kompella <[email-masked]>
Date: Sun, 9 Dec 2012 16:02:18 -0800

Hi Aldrin,

On Dec 8, 2012, at 21:51, Aldrin Isaac <[email-masked]> wrote:

> Historically there really was no MPLS enabled products that hit the right price points and/or features needed for the DC -- but some of us operators *have* implemented MPLS in the DC very successfully.  

Good to hear!

> My observation is that some vendors don't do MPLS/MPBGP very well and aggressively discourage its adoption,

Had to be said; glad you did.

> while other vendors reserve them for their SP products for which they  need reasons to charge a premium.  

Something for them to revisit ...

> Now with support for MPLS in merchant silicon, I don't see any good reason why MPLS-based DCVPN solutions (IPVPN, E-VPN) should be held back, particularly if the overlay tunnel is IP-based and MPLS labels are used for VPN context, split-horizon, etc. 

Agreed. An IP overlay tunnel with ECMP is what this draft proposes. I'm not overfond of having yet another encap, but I think this draft has found a valid, valuable niche.

Kireeti

---

From: Aldrin Isaac <[email-masked]>
Date: Sun, 9 Dec 2012 19:09:02 -0500

Hi Robert,

I agree that LDP and RSVP-based MPLS transport tunnels between hypervisors
or TORs isn't ideal as it is.  IP-based tunnels are better in this regard
with MPLS-based VPNs.

Best regards. -- aldrin

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Sun, 9 Dec 2012 21:25:29 +0000

As Robert pointed out, we need to distinguish between MPLS labels used in virtualization vs. MPLS protocols (LDP, RSVP-TE) used in data center transport networks.

The draft-fang-l3vpn-end-system-requirements-01 (sections 7 and 12) lists pros and cons of using MPLS vs. IP encapsulations.

Multi-access technologies, especially Ethernet, might also be used in data center transport networks, specifically, 802.1ah "varieties."

MPLS/BGP VPN control plane (RFC4364) is encapsulation agnostic as long as this encapsulation has the ability to carry a 20 bit label.

Ø  I don't see any good reason why MPLS-based DCVPN solutions (IPVPN, E-VPN) should be held back, particularly if the overlay tunnel is IP-based and MPLS > labels are used for VPN context, split-horizon, etc.

I would not put MPLS/BGP VPN and EVPN quite on equal footing though for, at least, two main reasons: (1) MPLS/BGP VPN technology is the industry's de-facto standard for wide-area virtual networks and has been successfully deployed for 12+ years at large scale, while EVPN is still being defined; (2) MPLS/BGP VPN does not have the complexity of EVPN necessary for interoperability with bridging (such as split horizon requiring additional so called ESI MPLS labels, designated forwarder election, upstream assigned/context labels).

Maria

From: [email-masked] [mailto:[email-masked]] On Behalf Of Aldrin Isaac
Sent: Sunday, December 09, 2012 12:52 AM
To: Melinda Shore
Cc: [email-masked]
Subject: Re: [nvo3] [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03

Melinda
_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3

---

From: John E Drake <[email-masked]>
Date: Mon, 10 Dec 2012 13:43:25 +0000

Robert,

We are talking about L3VPN and E-VPN over an IP infrastructure so there is no LDP or RSVP-TE.  Rather, the only label is the service label which is distributed via BGP or XMPP.

Irrespectively Yours,

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Robert Raszuk
> Sent: Sunday, December 09, 2012 11:06 AM
> To: Aldrin Isaac
> Cc: Melinda Shore; [email-masked]
> > Now with support for MPLS in merchant silicon, I don't see any good
> > reason why MPLS-based DCVPN solutions (IPVPN, E-VPN) should be held
> > back
> 
> - MPLS FECs can not be summarized. With IP we just need information how
> to reach subnet X ... with MPLS (even if one would provide the relaxed
> match) FECs are still /32s That's a lot of them in large data centers.
> 
> Cheers,
> R.

---

From: Lucy yong <[email-masked]>
Date: Mon, 10 Dec 2012 14:18:23 +0000

Hi Ali,

I agree with Aldrin's assessment as well.  Regarding another encapsulation, here is other justification points.

1)      When using NVGRE, there are only 8 bit flow entropy, this is not large enough for the flow space for a large tenant virtual network.

2)      UPD encapsulation not only provides flow entropy but also makes a good architecture in decoupling overlay network from underlay network.  In UDP encapsulation, the outer header contains underlying tunneling encoding (IP) and flow entropy (in UDP) and overlay data type (UDP).  It does not include any overlay specific information such as virtual network ID, flow ID, etc.  underlying network only processes the outer header and can perform the forwarding and load balancing. In short, that underling network do not use any overlay header at all. This is great metric from the architecture perspective.

Regards,
Lucy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ali Sajassi (sajassi)
Sent: Sunday, December 09, 2012 1:05 PM
To: Aldrin Isaac; Melinda Shore
Cc: [email-masked]
Subject: Re: [nvo3] [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03

Hi Aldrin,

Cheers,
Ali

Melinda

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 10 Dec 2012 15:58:53 +0100

Hi John,

Aldrin's email was not very clear on that especially as he highlighted
mpls support in hardware.

However you as Juniper stating " L3VPN and E-VPN over an IP
infrastructure" it's a great news (after so many years ...)  ! Bravo
!!!

Sincerely yours,
R.

---

From: John E Drake <[email-masked]>
Date: Mon, 10 Dec 2012 15:59:56 +0000

Robert,

Have you not seen drake-nvo3?

Irrespectively Yours,

John

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert
> Raszuk
> Sent: Monday, December 10, 2012 6:59 AM
> To: John E Drake
> Cc: Aldrin Isaac; Melinda Shore; [email-masked]
> > We are talking about L3VPN and E-VPN over an IP infrastructure so
> there is no LDP or RSVP-TE.  Rather, the only label is the service
> label which is distributed via BGP or XMPP.
> >
> > Irrespectively Yours,
> >
> > John
> >
> >
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> >> Of Robert Raszuk
> >> relaxed

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Mon, 10 Dec 2012 16:44:58 +0000

Hi Lucy,

With respect to your two points:

  1.  I was saying that the ASICs that support ECMP for NVGRE, also support ECMP for MPLSoGRE because in both cases, they need to hash the GRE key. The MPLSoGRE key is 32 bit long compare to MPLSoUDP which is 16 bit long. So, if you think longer has value provides better ECMP, MPLSoGRE should perform better than MPLSoUPD.
  2.  Regarding your 2nd point, MPLSoGRE as well as VXLAN also provide the same separation between underly and overlay network layers. In all these cases, you have tunnel header (IP header), flow entropy (UDP header or GRE key), and client layer (MPLS VPN labels in case of MPLS client, or VNI in VXLAN header). So, MPLSoUDP doesn't provide anything extra here.

Cheers,
Ali

From: Lucy yong <[email-masked]<mailto:[email-masked]>>
Date: Monday, December 10, 2012 6:18 AM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>, Aldrin Isaac <[email-masked]<mailto:[email-masked]>>, Melinda Shore <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [nvo3] [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03

Hi Ali,

I agree with Aldrin’s assessment as well.  Regarding another encapsulation, here is other justification points.

Regards,
Lucy

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Ali Sajassi (sajassi)
Sent: Sunday, December 09, 2012 1:05 PM
To: Aldrin Isaac; Melinda Shore
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [nvo3] [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03

Hi Aldrin,

Cheers,
Ali

Melinda

---

From: Lucy yong <[email-masked]>
Date: Mon, 10 Dec 2012 16:53:41 +0000

Hi Ali,

Please see below.

From: Ali Sajassi (sajassi) [mailto:[email-masked]]
Sent: Monday, December 10, 2012 10:45 AM
To: Lucy yong; Aldrin Isaac; Melinda Shore
Cc: [email-masked]
Subject: Re: [nvo3] [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03

Hi Lucy,

  1.  I was saying that the ASICs that support ECMP for NVGRE, also support ECMP for MPLSoGRE because in both cases, they need to hash the GRE key. The MPLSoGRE key is 32 bit long compare to MPLSoUDP which is 16 bit long. So, if you think longer has value provides better ECMP, MPLSoGRE should perform better than MPLSoUPD.
[Lucy] NVGRE take 24 bits for the VSID. Only 8 bit for flow entropy. Don't think 32 bits is necessary to a tunnel.

  1.  Regarding your 2nd point, MPLSoGRE as well as VXLAN also provide the same separation between underly and overlay network layers. In all these cases, you have tunnel header (IP header), flow entropy (UDP header or GRE key), and client layer (MPLS VPN labels in case of MPLS client, or VNI in VXLAN header). So, MPLSoUDP doesn't provide anything extra here.
[Lucy] if MPLSoUDP and NVGREoUDP, underlying network only needs to handle UDP based load balancing, which presents a simpler solution for DC infrastructure. DC do not have to change today's DC device at all. This is the architecture metric I see. How many DC routers support GRE based load balancing today?
Lucy

Cheers,
Ali

Hi Ali,

Regards,
Lucy

Hi Aldrin,

Cheers,
Ali

Melinda

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Mon, 10 Dec 2012 17:10:34 +0000

Hi Lucy,

Comments in line . . .

Date: Monday, December 10, 2012 8:53 AM

Hi Ali,

Please see below.

Hi Lucy,

  1.  I was saying that the ASICs that support ECMP for NVGRE, also support ECMP for MPLSoGRE because in both cases, they need to hash the GRE key. The MPLSoGRE key is 32 bit long compare to MPLSoUDP which is 16 bit long. So, if you think longer has value provides better ECMP, MPLSoGRE should perform better than MPLSoUPD.
[Lucy] NVGRE take 24 bits for the VSID. Only 8 bit for flow entropy. Don’t think 32 bits is necessary to a tunnel.

If hashing is done using GRE key, it is based on the entire key and not part of it. And that covers both NVGRE and MPLSoGRE.

  1.  Regarding your 2nd point, MPLSoGRE as well as VXLAN also provide the same separation between underly and overlay network layers. In all these cases, you have tunnel header (IP header), flow entropy (UDP header or GRE key), and client layer (MPLS VPN labels in case of MPLS client, or VNI in VXLAN header). So, MPLSoUDP doesn't provide anything extra here.
[Lucy] if MPLSoUDP and NVGREoUDP, underlying network only needs to handle UDP based load balancing, which presents a simpler solution for DC infrastructure. DC do not have to change today’s DC device at all. This is the architecture metric I see. How many DC routers support GRE based load balancing today?
Lucy

That ship has already sailed and the capability to do ECMP based on GRE key has already been incorporated into ASICs which enables ECMP based on standard-based MPLSoGRE (RFC2890 and RFC2784). Anyway, let's see what DC operators have to say about this.

-Ali

Cheers,
Ali

Hi Ali,

Regards,
Lucy

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Ali Sajassi (sajassi)

Hi Aldrin,

Cheers,
Ali

Melinda

---

From: Lucy yong <[email-masked]>
Date: Mon, 10 Dec 2012 17:19:03 +0000

Hi Ali,

If hashing is done using GRE key, it is based on the entire key and not part of it. And that covers both NVGRE and MPLSoGRE.
[Lucy] that is true in the first port. However, NGGRE use 24 bit of the GRE key for VSID. Only 8 bit left for the flow entropy. To the second point, if you count GRE key as the part of outer header, NVGRE relies on the outer header to carry the overlay information. If you count it as the part of overlay header, the underlying network will use the overlay header for load distribution. This is my early point. UDP encapsulation provides a good architecture of decoupling between overlay network and underlying network.

Lucy

-Ali

Cheers,
Ali

Hi Ali,

Regards,
Lucy

Hi Aldrin,

Cheers,
Ali

Melinda

---

From: Yiqun Cai <[email-masked]>
Date: Mon, 10 Dec 2012 18:34:06 +0000

A quick comment inline...

--
Yiqun

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Monday, December 10, 2012 6:18 AM
To: Ali Sajassi (sajassi); Aldrin Isaac; Melinda Shore
Cc: [email-masked]
Subject: Re: [nvo3] [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03

Hi Ali,

[Yiqun Cai]

If handled properly, 8 bits of flow entropy allows one to support 256-way ECMP.  I'm not aware of any network that built using 256 way ECMP (or even close to it). Even accounting for polarization,  I still fail to see why it is not large enough.  Would you care to provide an analysis here?

Thanks.

Regards,
Lucy

Hi Aldrin,

Cheers,
Ali

Melinda

---

From: Lucy yong <[email-masked]>
Date: Mon, 10 Dec 2012 18:36:51 +0000

[Yiqun Cai]

[Lucy]  please read hashing function. You miss the point.
Lucy

Thanks.

Regards,
Lucy

Hi Aldrin,

Cheers,
Ali

Melinda

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 11 Dec 2012 08:05:38 +0000

[Xiaohu]

Ali,

The following text is quoted from your draft (http://tools.ietf.org/html/draft-sajassi-nvo3-evpn-overlay-01) which was just submitted no more than two months ago,  " As noted previously, there are existing core switches that do not  support ECMP by hashing the GRE key; however, vast majority of  existing core switches support ECMP by hashing UDP header; therefore,  VXLAN encapsulation can provide better ECMP functions for these existing switches".  Are you going to correct the above statement in a manner of U-turn  in the next revision?

Xiaohu

[/Xiaohu]

-Ali

---

From: Yiqun Cai <[email-masked]>
Date: Tue, 11 Dec 2012 08:18:51 +0000

Lucy,

I don't doubt I'm missing something.  But deleting the very statement that I wanted a clarification for and asking me to study hashing functions is not going to help me get the point.

The draft in question doesn't describe any specific hashing function either.  It only claims that core routers cannot load-balance adequately for GRE packets. Depending on the definition of "core" routers and the timeline, the claim might be true.  But it is not relevant because these core routers are not the ones people use to build large data centers today and tomorrow.
Now please allow me bring your original statement back again,

So what is a large enough space to generate an entropy, by what kind of hashing function, and for what size of a network, if 8 bits is not sufficient? Numbers will work much better for me.

Thanks.

--
Yiqun

From: Lucy yong [mailto:[email-masked]]
Sent: Monday, December 10, 2012 10:37 AM
To: Yiqun Cai; Ali Sajassi (sajassi); Aldrin Isaac; Melinda Shore
Cc: [email-masked]
Subject: RE: [nvo3] [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03

[Yiqun Cai]

Thanks.

Regards,
Lucy

Hi Aldrin,

Cheers,
Ali

Melinda

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Wed, 12 Dec 2012 05:47:06 +0000

Xiaohu,

First, my draft got merged with draft-drake-nvo3-evpn-control-plane and the resultant draft is now draft-sajassi-drake-l2vpn-evpn-overlay-00.txt. And the new draft has no reference to MPLS over UDP.

Second, even in my old draft that you are referencing, if you look at the section that talks about MPLS over UDP, it says:

   [MPLSoUDP] discusses using a UDP header instead of the GRE header to
   transport MPLS client layer over an IP PSN tunnel. The main advantage
   for doing so is for better load-balancing capabilities over existing
   IP networks, where some core routers can perform ECMP based on the
   UDP header but not based on the GRE Key field. However, the routers
   that are capable of supporting [NVGRE<http://tools.ietf.org/html/draft-sajassi-nvo3-evpn-overlay-01#ref-NVGRE>] encapsulation, can also
   perform load-balancing based on the GRE key which accommodates a 32-
   bit entropy value; whereas, UDP encapsulation accommodates a 16-bit
   entropy value.

And this sums up why I don't see a value in MPLS over UDP encap (as I have been explaining on this thread).

-Ali

From: Xuxiaohu <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, December 11, 2012 12:05 AM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>, Lucy yong <[email-masked]<mailto:[email-masked]>>, Aldrin Isaac <[email-masked]<mailto:[email-masked]>>, Melinda Shore <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: re: [nvo3] [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03

[Xiaohu]

Ali,

The following text is quoted from your draft (http://tools.ietf.org/html/draft-sajassi-nvo3-evpn-overlay-01) which was just submitted no more than two months ago,  “ As noted previously, there are existing core switches that do not  support ECMP by hashing the GRE key; however, vast majority of  existing core switches support ECMP by hashing UDP header; therefore,  VXLAN encapsulation can provide better ECMP functions for these existing switches”.  Are you going to correct the above statement in a manner of U-turn  in the next revision?

Xiaohu

[/Xiaohu]

-Ali

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 12 Dec 2012 06:04:55 +0000

Ali,

I don’t care about whether or not your draft has a reference to MPLS over UDP. However, since you’ve made a U-turn on the load-balancing capability of most existing core switches,  I’m just wondering whether the ship you mentioned below just sailed last month:)

Best regards,
Xiaohu

发件人: Ali Sajassi (sajassi) [mailto:[email-masked]]
发送时间: 2012年12月12日 13:47
收件人: Xuxiaohu; Lucy yong; Aldrin Isaac; Melinda Shore
抄送: [email-masked]
主题: Re: [nvo3] [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03

Xiaohu,

First, my draft got merged with draft-drake-nvo3-evpn-control-plane and the resultant draft is now draft-sajassi-drake-l2vpn-evpn-overlay-00.txt.
And the new draft has no reference to MPLS over UDP.

Second, even in my old draft that you are referencing, if you look at the section that talks about
MPLS over UDP, it says:

   entropy value.

-Ali

[Xiaohu]

Ali,

Xiaohu

[/Xiaohu]

-Ali