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
