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 protected]> 发件人: "nvo3" <[email protected]> 2016-04-05 05:19 收件人 EXT Diego Garcia del Rio <[email protected]>, "S. Davari" <[email protected]>, 抄送 "[email protected]" <[email protected]>, "Rajiv Asati \(rajiva\)" <[email protected]> 主题 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 protected] on behalf of [email protected]> 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 protected]> 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 protected]> To: Rajiv Asati (rajiva) <[email protected]> Cc: S. Davari <[email protected]>; "[email protected]" <[email protected]> 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 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
