Subject: [nvo3] Issue with draft-chen-nvo3-vxlan-yang-02

From: "S. Davari" <[email-masked]>
Date: Mon, 4 Apr 2016 18:24:53 +0000 (UTC)

Hi, I like to repeat my comments in today’s NVO3 meeting. This draft goes way beyond the RFC and accepted VXLAN drafts. It introduces new modes that are not required and not supported in any implementation. Such as L2 interface to VNID mapping or MAC_DA to VNID mapping. I would like to only see VLAN mapping to VNID, which is consistent with VXLAN RFC and drafts, else I am against this draft becoming a WG draft,. ThxShahram DavariBroadcom

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 4 Apr 2016 20:01:29 +0000

+1.

Also, it might be better to have a base overlay module and protocol specific modules to avoid duplication & force consistency. For ex, inner-tag-removal may well be common to more than one overlay protocol.

-- 
Cheers,
Rajiv  

-----Original Message-----
From: nvo3 <[email-masked]> on behalf of "S. Davari" <[email-masked]>
Reply-To: "S. Davari" <[email-masked]>
Date: Monday, April 4, 2016 at 2:24 PM
To: "[email-masked]" <[email-masked]>
Subject: [nvo3] Issue with draft-chen-nvo3-vxlan-yang-02

>Hi,
> 
>I like to repeat my comments in today’s NVO3 meeting. This draft goes way beyond the RFC and accepted VXLAN drafts. It introduces new modes that are not required and not supported in any implementation. Such as
> L2 interface to VNID mapping or MAC_DA to VNID mapping.
> 
>I would like to only see VLAN mapping to VNID, which is consistent with VXLAN RFC and drafts, else I am against this draft becoming a WG draft,.
> 
>Thx
>Shahram Davari
>Broadcom
>
>
>

---

From: Diego Garcia del Rio <[email-masked]>
Date: Mon, 4 Apr 2016 17:11:02 -0300

Port+vlan to vnid is actually supported by a few vendors (as well as OVS
itself) - with basically port-significant vlan. But I agree that we should
basically separate the access side from the tunnel side. I'm sure the
access side has probably been defined in other WGs as well (such as L2
VPNs, etc).

The need for tunnel-side yang model to attach to a "service" would probably
cover most of the needed models (and given, at the moment, the limited
options in the vxlan header itself), we probably would be limited at
whether you transport the vlan over vxlan or not and then whether the
tunnels are source-based replicated or not (PIM-SM based) and if you do
learning over the tunnel or not (for an EVPN-control-plane signalled tunnel)

On Mon, Apr 4, 2016 at 5:01 PM, Rajiv Asati (rajiva) <[email-masked]>
wrote:

> +1.
>
> Also, it might be better to have a base overlay module and protocol
> specific modules to avoid duplication & force consistency. For ex,
> inner-tag-removal may well be common to more than one overlay protocol.
>
> --
> Cheers,
> Rajiv
>
>
>
>
>
>
>
>
> >I like to repeat my comments in today’s NVO3 meeting. This draft goes way
> beyond the RFC and accepted VXLAN drafts. It introduces new modes that are
> not required and not supported in any implementation. Such as
> >I would like to only see VLAN mapping to VNID, which is consistent with
> VXLAN RFC and drafts, else I am against this draft becoming a WG draft,.
> >
> >Thx
> >Shahram Davari
> >Broadcom
> >
> >
> >
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>

---

From: "S. Davari" <[email-masked]>
Date: Mon, 4 Apr 2016 20:27:08 +0000 (UTC)

Hi Diego,
PORT+VLAN is fine as long as it is not required for to have different VNID for the same VPN. in other words as long as it is N:1 mapping for same VPN. This means we should not be required to do switching packet from one VNID to another VNID.
May be a better way to represent this is Yang is to always map VFI to VNID. Then VFI can be derived in many ways including VLAN, (Port, VLAN), etc,
Thx
Shahram

      From: Diego Garcia del Rio <[email-masked]>
 To: Rajiv Asati (rajiva) <[email-masked]> 
Cc: S. Davari <[email-masked]>; "[email-masked]" <[email-masked]>
 Sent: Monday, April 4, 2016 1:11 PM
 Subject: Re: [nvo3] Issue with draft-chen-nvo3-vxlan-yang-02
   
Port+vlan to vnid is actually supported by a few vendors (as well as OVS itself) - with basically port-significant vlan. But I agree that we should basically separate the access side from the tunnel side. I'm sure the access side has probably been defined in other WGs as well (such as L2 VPNs, etc).
The need for tunnel-side yang model to attach to a "service" would probably cover most of the needed models (and given, at the moment, the limited options in the vxlan header itself), we probably would be limited at whether you transport the vlan over vxlan or not and then whether the tunnels are source-based replicated or not (PIM-SM based) and if you do learning over the tunnel or not (for an EVPN-control-plane signalled tunnel)

On Mon, Apr 4, 2016 at 5:01 PM, Rajiv Asati (rajiva) <[email-masked]> wrote:

+1.

--
Cheers,
Rajiv

---

From: Diego Garcia del Rio <[email-masked]>
Date: Mon, 4 Apr 2016 17:44:25 -0300

I agree the mapping should be VFI (that is what I called service) to
VXLAN/VNID with whatever control/data-plane there might be in use (Openflow
/ flood-and-learn / evpn / etc)

whether the VFI is vlan-backed or something else, it should be irrelevant
to this part of the draft IMHO, as well as how packets get tagged into the
particular VFI (again, port+local-vlan-id, box-wide vlan, qinq, mac-filter,
or whatever other mechanism) - but I see this as a second problem that
probalby belongs on a separate draft or even seprate groups.

On Mon, Apr 4, 2016 at 5:27 PM, S. Davari <[email-masked]> wrote:

> Hi Diego,
>
> PORT+VLAN is fine as long as it is not required for to have different VNID
> for the same VPN. in other words as long as it is N:1 mapping for same VPN.
> This means we should not be required to do switching packet from one VNID
> to another VNID.
>
> May be a better way to represent this is Yang is to always map VFI to
> VNID. Then VFI can be derived in many ways including VLAN, (Port, VLAN),
> etc,
>
> Thx
> Shahram
>
>
> ------------------------------
> *From:* Diego Garcia del Rio <[email-masked]>
> *To:* Rajiv Asati (rajiva) <[email-masked]>
> *Cc:* S. Davari <[email-masked]>; "[email-masked]" <[email-masked]>
> *Sent:* Monday, April 4, 2016 1:11 PM
> *Subject:* Re: [nvo3] Issue with draft-chen-nvo3-vxlan-yang-02
>
> The need for tunnel-side yang model to attach to a "service" would
> probably cover most of the needed models (and given, at the moment, the
> limited options in the vxlan header itself), we probably would be limited
> at whether you transport the vlan over vxlan or not and then whether the

---

From: "Rabadan, Jorge (Nokia - US)" <[email-masked]>
Date: Mon, 4 Apr 2016 21:19:33 +0000

Fully agree with Diego.

One more thing I wanted to add:
To me VXLAN is one more tunnel type for a layer-2 service. There is an L2VPN YANG model and an EVPN YANG model, both are pretty mature at this moment and if we are missing any constructs for vxlan we should add them there. I don’t see the need for a separate YANG model just for VXLAN.

An update of both drafts will be presented on Thursday during the BESS session.

Thanks.
Jorge

On 4/4/16, 5:44 PM, "nvo3 on behalf of EXT Diego Garcia del Rio" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

I agree the mapping should be VFI (that is what I called service) to VXLAN/VNID with whatever control/data-plane there might be in use (Openflow / flood-and-learn / evpn / etc)

whether the VFI is vlan-backed or something else, it should be irrelevant to this part of the draft IMHO, as well as how packets get tagged into the particular VFI (again, port+local-vlan-id, box-wide vlan, qinq, mac-filter, or whatever other mechanism) - but I see this as a second problem that probalby belongs on a separate draft or even seprate groups.

On Mon, Apr 4, 2016 at 5:27 PM, S. Davari <[email-masked]<mailto:[email-masked]>> wrote:
Hi Diego,

Thx
Shahram

________________________________
From: Diego Garcia del Rio <[email-masked]<mailto:[email-masked]>>
To: Rajiv Asati (rajiva) <[email-masked]<mailto:[email-masked]>>
Cc: S. Davari <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Monday, April 4, 2016 1:11 PM
Subject: Re: [nvo3] Issue with draft-chen-nvo3-vxlan-yang-02

On Mon, Apr 4, 2016 at 5:01 PM, Rajiv Asati (rajiva) <[email-masked]<mailto:[email-masked]>> wrote:
+1.

--
Cheers,
Rajiv

-----Original Message-----
From: nvo3 <[email-masked]<mailto:[email-masked]>> on behalf of "S. Davari" <[email-masked]<mailto:[email-masked]>>
Reply-To: "S. Davari" <[email-masked]<mailto:[email-masked]>>
Date: Monday, April 4, 2016 at 2:24 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [nvo3] Issue with draft-chen-nvo3-vxlan-yang-02

[email-masked]<mailto:[email-masked]>

---

From: "S. Davari" <[email-masked]>
Date: Mon, 4 Apr 2016 21:57:36 +0000 (UTC)

Agree.
Thx
SD

      From: "Rabadan, Jorge (Nokia - US)" <[email-masked]>
 To: EXT Diego Garcia del Rio <[email-masked]>; S. Davari <[email-masked]> 
Cc: "[email-masked]" <[email-masked]>; Rajiv Asati (rajiva) <[email-masked]>
 Sent: Monday, April 4, 2016 2:19 PM
 Subject: Re: [nvo3] Issue with draft-chen-nvo3-vxlan-yang-02
   
Fully agree with Diego.
One more thing I wanted to add:To me VXLAN is one more tunnel type for a layer-2 service. There is an L2VPN YANG model and an EVPN YANG model, both are pretty mature at this moment and if we are missing any constructs for vxlan we should add them there. I don’t see the need for a separate YANG model just for VXLAN.
An update of both drafts will be presented on Thursday during the BESS session.
Thanks.Jorge
On 4/4/16, 5:44 PM, "nvo3 on behalf of EXT Diego Garcia del Rio" <[email-masked] on behalf [email-masked]> wrote:

Hi Diego,

+1.

--
Cheers,
Rajiv

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 6 Apr 2016 02:36:28 +0000

Jorge,

To me VXLAN is one more tunnel type for a layer-2 service

I agree.

layer-2 service. There is an L2VPN YANG model and an EVPN YANG model, both are pretty mature at this moment and if we are missing any constructs for vxlan we should add them there.

If the intent is to cover all of standardized  l2vpn and EVPN tunnel/overlay types in the existing drafts, then it is better to avoid having overlay specific drafts.

Cheers,
Rajiv

On Apr 4, 2016, at 6:19 PM, Rabadan, Jorge (Nokia - US) <[email-masked]<mailto:[email-masked]>> wrote:

Fully agree with Diego.

Thanks.
Jorge

Thx
Shahram

--
Cheers,
Rajiv

---

From: "Rabadan, Jorge (Nokia - US)" <[email-masked]>
Date: Wed, 6 Apr 2016 02:38:37 +0000

Fully agree.

Thanks.
Jorge

On 4/5/16, 11:36 PM, "EXT Rajiv Asati (rajiva)" <[email-masked]<mailto:[email-masked]>> wrote:

Jorge,

I agree.

Cheers,
Rajiv

Fully agree with Diego.

Thanks.
Jorge

Thx
Shahram

--
Cheers,
Rajiv

---

From: [email-masked]
Date: Wed, 6 Apr 2016 20:13:09 +0800

Hi，Davari
Thanks for you comments.
Please check my reply with[hfw].

beyond the RFC and accepted VXLAN drafts. It introduces new modes that are 
not required and >not supported in any implementation. Such as L2 
interface to VNID mapping or MAC_DA to VNID mapping.

[hfw] Actually, we have implement the L2 interface to VNID mapping in the 
product.

Thanks
Regards.
Fangwei.

"S. Davari" <[email-masked]> 
发件人:  "nvo3" <[email-masked]>
2016-04-05 02:24
请答复 给
"S. Davari" <[email-masked]>

收件人
"[email-masked]" <[email-masked]>, 
抄送

主题
[nvo3] Issue with draft-chen-nvo3-vxlan-yang-02

Hi,
 
I like to repeat my comments in today’s NVO3 meeting. This draft goes way 
beyond the RFC and accepted VXLAN drafts. It introduces new modes that are 
not required and not supported in any implementation. Such as L2 interface 
to VNID mapping or MAC_DA to VNID mapping.

Thx
Shahram Davari
Broadcom

---

From: [email-masked]
Date: Wed, 6 Apr 2016 20:17:04 +0800

Hi, Diege

>Port+vlan to vnid is actually supported by a few vendors (as well as OVS 
itself) - with basically port-significant vlan. 
[hfw] Yes, we have implemented this feature.

But I agree that we should >basically separate the access side from the 
tunnel side. I'm sure the access side has probably been defined in other 
WGs as well (such as L2 VPNs, etc).

learning over the tunnel or not (for an EVPN-control-plane signalled 
tunnel)

[hfw]I will consider your suggestion.

Regards.
Fangwei

Diego Garcia del Rio <[email-masked]> 
发件人:  "nvo3" <[email-masked]>
2016-04-05 04:11

收件人
"Rajiv Asati (rajiva)" <[email-masked]>, 
抄送
"[email-masked]" <[email-masked]>, "S. Davari" <[email-masked]>
主题
Re: [nvo3] Issue with draft-chen-nvo3-vxlan-yang-02

learning over the tunnel or not (for an EVPN-control-plane signalled 
tunnel)

--
Cheers,
Rajiv

-----Original Message-----
From: nvo3 <[email-masked]> on behalf of "S. Davari" <
[email-masked]>

>Hi,
>
>I like to repeat my comments in today’s NVO3 meeting. This draft goes 
way beyond the RFC and accepted VXLAN drafts. It introduces new modes that 
are not required and not supported in any implementation. Such as

---

From: [email-masked]
Date: Wed, 6 Apr 2016 20:27:49 +0800

I agree that we should focus on the tunnel side. While there are several 
ways to establish the tunnel. EVPN, PIM-SM+ data plane learning, and 
static tunnel. EVPN is one of the choice.
If we difine it in the L2VPN YANG model, so how do we deal with the PIM-SM 
solution?

I know that some vendors only support PIM-SM ,or Openflow etc. EVPN is not 
support, so I think we still need have a VxLAN YANG data model, and we can 
focus more on the tunnel side.

Regards.
Fangwei

"Rabadan, Jorge (Nokia - US)" <[email-masked]> 
发件人:  "nvo3" <[email-masked]>
2016-04-05 05:19

收件人
EXT Diego Garcia del Rio <[email-masked]>, "S. Davari" 
<[email-masked]>, 
抄送
"[email-masked]" <[email-masked]>, "Rajiv Asati \(rajiva\)" 
<[email-masked]>
主题
Re: [nvo3] Issue with draft-chen-nvo3-vxlan-yang-02

Fully agree with Diego.

One more thing I wanted to add:
To me VXLAN is one more tunnel type for a layer-2 service. There is an 
L2VPN YANG model and an EVPN YANG model, both are pretty mature at this 
moment and if we are missing any constructs for vxlan we should add them 
there. I don’t see the need for a separate YANG model just for VXLAN.

An update of both drafts will be presented on Thursday during the BESS 
session.

Thanks.
Jorge

On 4/4/16, 5:44 PM, "nvo3 on behalf of EXT Diego Garcia del Rio" <
[email-masked] on behalf of [email-masked]> wrote:

I agree the mapping should be VFI (that is what I called service) to 
VXLAN/VNID with whatever control/data-plane there might be in use 
(Openflow / flood-and-learn / evpn / etc) 

whether the VFI is vlan-backed or something else, it should be irrelevant 
to this part of the draft IMHO, as well as how packets get tagged into the 
particular VFI (again, port+local-vlan-id, box-wide vlan, qinq, 
mac-filter, or whatever other mechanism) - but I see this as a second 
problem that probalby belongs on a separate draft or even seprate groups.

PORT+VLAN is fine as long as it is not required for to have different VNID 
for the same VPN. in other words as long as it is N:1 mapping for same 
VPN. This means we should not be required to do switching packet from one 
VNID to another VNID.

Thx
Shahram

--
Cheers,
Rajiv

-----Original Message-----

[email-masked]

---

From: "S. Davari" <[email-masked]>
Date: Wed, 6 Apr 2016 09:35:52 -0300

Hi Fangwei

I understand. But this draft should only state mapping from VFI to VNID and should be agnostic on how VFI is derived. It can be derived from port, VLAN, (port, VLAN), etc. 

Please update the draft to only mention VFI to VNID mapping. 

Regards,
Shahram

> On Apr 6, 2016, at 9:13 AM, [email-masked] wrote:
> 
> Hi，Davari 
> Thanks for you comments. 
> >I like to repeat my comments in today’s NVO3 meeting. This draft goes way beyond the RFC and accepted VXLAN drafts. It introduces new modes that  are not required and >not supported in any implementation. Such as L2  interface to VNID mapping or MAC_DA to VNID mapping. 
>   
> [hfw] Actually, we have implement the L2 interface to VNID mapping in the product. 
> 
> Thanks 
> Regards. 
> Fangwei. 
> 
> 
> 
> 
> I like to repeat my comments in today’s NVO3 meeting. This draft goes way beyond the RFC and accepted VXLAN drafts. It introduces new modes that  are not required and not supported in any implementation. Such as L2  interface to VNID mapping or MAC_DA to VNID mapping. 
>