Re: [nvo3-dt-encap] Discussion summary

Here is some text for a few sections with my name:

Section 6.2 >>>
Another use case would be to carry the Group Based Policy (GBP) source group information within a NVO3 header extension in a similar manner as has been implemented for VXLAN [reference]. This allows various forms of policy such as access control and QoS to be applied between abstract groups rather than coupled to specific endpoint addresses.

Section 6.4 >>>
Extension header length has a significant impact to hardware and software implementations. A total header length that is too small will unnecessarily constraint software flexibility. A total header length that is too large will place a nontrivial cost on hardware implementations. Thus, the design team recommends that there be a minimum and maximum total extension header length selected. The maximum total header length is determined by the bits allocated for the total extension header length field. The risk with this approach is that it may be difficult to extend the total header size in the future. The minimum total header length is determined by a requirement in the specifications that all implementations must meet. The risk with this approach is that all implementations will only implement the minimum total header length which would then become the defacto maximum total header length. The recommended minimum total header length is TBD. 64 ?

Thanks,
Michael

From: nvo3-dt-encap <nvo3-dt-encap-bounces@ietf.org<mailto:nvo3-dt-encap-bounces@ietf.org>> on behalf of Sami Boutros <sboutros@vmware.com<mailto:sboutros@vmware.com>>
Date: Sunday, January 15, 2017 at 9:59 PM
To: Pankaj Garg <ipankajg@gmail.com<mailto:ipankajg@gmail.com>>, Rajeev Manur <rajeev.manur@broadcom.com<mailto:rajeev.manur@broadcom.com>>
Cc: "nvo3-dt-encap@ietf.org<mailto:nvo3-dt-encap@ietf.org>" <nvo3-dt-encap@ietf.org<mailto:nvo3-dt-encap@ietf.org>>
Subject: Re: [nvo3-dt-encap] Discussion summary - 1/10/2017

Please find attached the initial draft.

Thanks,

Sami
From: nvo3-dt-encap <nvo3-dt-encap-bounces@ietf.org<mailto:nvo3-dt-encap-bounces@ietf.org>> on behalf of Pankaj Garg <ipankajg@gmail.com<mailto:ipankajg@gmail.com>>
Date: Thursday, January 12, 2017 at 12:12 AM
To: Rajeev Manur <rajeev.manur@broadcom.com<mailto:rajeev.manur@broadcom.com>>
Cc: "nvo3-dt-encap@ietf.org<mailto:nvo3-dt-encap@ietf.org>" <nvo3-dt-encap@ietf.org<mailto:nvo3-dt-encap@ietf.org>>
Subject: Re: [nvo3-dt-encap] Discussion summary - 1/10/2017

Yes I did, my mistake, sorry about it.

On Jan 11, 2017 11:00 AM, "Rajeev Manur" <rajeev.manur@broadcom.com<mailto:rajeev.manur@broadcom.com>> wrote:
Hi Pankaj,

Thanks for the notes. I participated in yesterday's discussion as well. Looks like you missed my name on the participants list.

Thanks!
--Rajeev

Sent from my iPhone

> On Jan 11, 2017, at 7:25 AM, Pankaj Garg <ipankajg@gmail.com<mailto:ipankajg@gmail.com>> wrote:
>
> Hi All,
>
> Thanks for attending the call. My curated notes are below.
>
> Participants:
>    Erik Nordmark (Arista)
>    Michael Smith (Cisco)
>    Ignas Bagdonas (Equinix)
>    Ilango Ganga (Intel)
>    Sami Boutros (VMware)
>    Tal Mizrahi (Marvell)
>    David Mozes (Mellanox)
>    Pankaj Garg (Microsoft)
>
> 1. We discussed the text for requiring at minimum 64-bytes to be
>   supported in Geneve. There is consensus that we should propose a text
>   to Geneve authors on minimum option length requirement. This would
>   ensure there is common minimum support from all compliant Geneve
>   implementations.
>
> 2. We discussed the idea of TLV0 further and upon discussion it was
>   realized that it adds more confusion without any significant gain.
>   Hence design team agreed to drop this from the proposed changes.
>
> 3. We agreed that we should put some text either in Geneve draft or
>   design team report around supporting option ordering in Geneve
>   implemnentations. The idea is that if a hardware can process options
>   in TCAM but it can only process the first TLV, then control plane in
>   a deployment can use this capability by ensuring a specific TLV is
>   always the first one in the packet. We need someone to write this
>   text.
>
> 4. We discussed split-NVE case and agreed that we need to ask WG whether
>   in split-NVE case, options needs to be carried in other packet
>   formats such as 802.1q and if they do, then would carrying Geneve
>   frame in 802.1q be needed? Based on WG recommendation, an ETYPE
>   and/or IP protocol number can be allocated for Geneve as well. Erik
>   has agreed to write text around this question. Thanks Erik.
>
> 5. Sami has volunteered to write the initial draft for design team
>   report. This report would contain our rationale for proposing a
>   specific encapsulation and few specific extension use cases and how
>   propose encapsulation meet those requirements. Thanks Sami.
>
> 6. Pankaj would send one extension use case around diagnostics. We would
>   check with Tom on extension around security. Those will probably be
>   two use cases we would cover in our design report.
>
> Please let me know if I missed anything.
>
> Thanks,
> Pankaj (on behalf of NVO3 Encap Design Team)
>
> _______________________________________________
> nvo3-dt-encap mailing list
> nvo3-dt-encap@ietf.org<mailto:nvo3-dt-encap@ietf.org>
> https://www.ietf.org/mailman/listinfo/nvo3-dt-encap<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_nvo3-2Ddt-2Dencap&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=IVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=nm_Ctkl_dvuZF0yR7wFkzKY9084l5Bdok5sR2g1LFX4&s=t-U-Xb4i7VQD8CuCVfPVBuNiMKRYKD3RkKDuxtkXWxs&e=>