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
