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). 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) [hfw]I will consider your suggestion. Regards. Fangwei Diego Garcia del Rio <[email protected]> 发件人: "nvo3" <[email protected]> 2016-04-05 04:11 收件人 "Rajiv Asati (rajiva)" <[email protected]>, 抄送 "[email protected]" <[email protected]>, "S. Davari" <[email protected]> 主题 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 protected]> 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 -----Original Message----- From: nvo3 <[email protected]> on behalf of "S. Davari" < [email protected]> Reply-To: "S. Davari" <[email protected]> Date: Monday, April 4, 2016 at 2:24 PM To: "[email protected]" <[email protected]> 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 > > > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
