Subject: Re: [nvo3] comments on draft-sridharan-virtualization-nvgre-03

From: Lizhong Jin <[email-masked]>
Date: Fri, 6 Sep 2013 16:18:52 +0800

>
>  **
>
> We can have a better solution to support ECMP. Most switches and routers
> today support 5 tuple based load balance. Five tuple are IP src/dst addr,
> tcp|udp src/dst ports, and IP protocol type.
> draft-yong-tsvwg-gre-in-udp-encap-01 proposes the gre-in-udp encapsulation
> for GRE encapsulated protocols to be tunneled over IP networks where ECMP
> exists. This solution supports 16 bits flow entropy, does not require any
> change on intermediate switches and routers, and applies to any GRE
> encapsulated protocol. It also gives the ingress end point flexibility to
> generate the flow entropy without explicitly exposing VSID. I highly
> recommend NVGRE proposal to adopt this method for ECMP support.****
>
> [PG] – Thanks, I would take a look at the proposal, however I treat this
> as another tunneling protocol in addition to three existing ones i.e.
> NVGRE, VxLAN and STT. What are the specific advantages of this over other
> protocols? Also many of current generation NIC hardware support offloads
> for the existing three protocols. Wouldn’t using GRE-IN-UDP break those
> offloads?****
>
> *[Lucy] If NIC hardware support VxLAN which use UDP port for the flow
> entropy, it should be easy to support gre-in-udp encaps as well. Will be
> great  to see chip vendor comment on this. Please take a look at the
> gre-in-udp encapsulation proposal (below), welcome comment on it.*
>
> [PG] Sure, I would take a look at it.
>
[Lizhong] it is not easy to design gre-in-udp from the chip design point of
view. The offloading NIC provided is to terminate tunnel. But in
gre-in-udp, you have two tunnel layer, then you have to terminate twice for
the chip. Then of cource, you will increase the cost, power consumption,
and etc.

My concern is if applying gre-in-udp for nvgre, then why not directly using
vxlan?

Regards
Lizhong

>  ****
>
> * *
>
> *Regards,*
>
> *Lucy*****
>
> ** **
>
> Here is the draft. The TSVWG will adopt it as WG draft soon.****
>
> ** **
>
> http://datatracker.ietf.org/doc/draft-yong-tsvwg-gre-in-udp-encap/****
>
> ** **
>
> Regards,****
>
> Lucy****
>
> ** **
>
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>
>

---

From: Lucy yong <[email-masked]>
Date: Fri, 6 Sep 2013 19:57:40 +0000

Hi Lizhong,

Please see my reply inling.

From: Lizhong Jin [mailto:[email-masked]]
Sent: Friday, September 06, 2013 3:19 AM
To: [email-masked]; [email-masked]; [email-masked]; Lucy yong; [email-masked]
Subject: Re: [nvo3] comments on draft-sridharan-virtualization-nvgre-03

We can have a better solution to support ECMP. Most switches and routers today support 5 tuple based load balance. Five tuple are IP src/dst addr, tcp|udp src/dst ports, and IP protocol type. draft-yong-tsvwg-gre-in-udp-encap-01 proposes the gre-in-udp encapsulation for GRE encapsulated protocols to be tunneled over IP networks where ECMP exists. This solution supports 16 bits flow entropy, does not require any change on intermediate switches and routers, and applies to any GRE encapsulated protocol. It also gives the ingress end point flexibility to generate the flow entropy without explicitly exposing VSID. I highly recommend NVGRE proposal to adopt this method for ECMP support.
[PG] - Thanks, I would take a look at the proposal, however I treat this as another tunneling protocol in addition to three existing ones i.e. NVGRE, VxLAN and STT. What are the specific advantages of this over other protocols? Also many of current generation NIC hardware support offloads for the existing three protocols. Wouldn't using GRE-IN-UDP break those offloads?
[Lucy] If NIC hardware support VxLAN which use UDP port for the flow entropy, it should be easy to support gre-in-udp encaps as well. Will be great  to see chip vendor comment on this. Please take a look at the gre-in-udp encapsulation proposal (below), welcome comment on it.
[PG] Sure, I would take a look at it.
[Lizhong] it is not easy to design gre-in-udp from the chip design point of view. The offloading NIC provided is to terminate tunnel. But in gre-in-udp, you have two tunnel layer, then you have to terminate twice for the chip. Then of cource, you will increase the cost, power consumption, and etc.
[Lucy] If NIC can terminate UDP tunnel for vxlan and GRE tunnel for NVGRE, it can support gre-in-udp for NVGRE. I don't see the given reasons superior to the benefit gained in the network.

My concern is if applying gre-in-udp for nvgre, then why not directly using vxlan?
[Lucy] I am glad that you point out this.  We also propose vxlan enhancement to add prototype field (see http://datatracker.ietf.org/doc/draft-yong-l3vpn-nvgre-vxlan-encap/).  These enhancements make nvgre+ and vxlan+ very similar semantics and general to support other overlays. The only difference in between will be that they use different UDP port number and use different bit (3rd bit or 5th ) to indicate the presence of VSID or VNI. In the spirit of IETF and for easy interworking, it will be nice to have one standardized. Given the existing deployment circumstance and chips support both, should IETF compliance and adopt both? This is what the community has to decide.

Thanks,
Lucy

Regards
Lizhong

Regards,
Lucy

Here is the draft. The TSVWG will adopt it as WG draft soon.

http://datatracker.ietf.org/doc/draft-yong-tsvwg-gre-in-udp-encap/

Regards,
Lucy

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