Hi Anoop, The provided text is fine. Given that it is just a minor clarification text, I think it should be OK to incorporate it; however, I need to check with the chairs and the AD given that this draft has already gone through the WG LC.
Cheers, Ali From: <[email protected]<mailto:[email protected]>> on behalf of Anoop Ghanwani <[email protected]<mailto:[email protected]>> Date: Wednesday, July 19, 2017 at 9:11 AM To: Cisco Employee <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [bess] a question about bundled service in draft-ietf-bess-evpn-overlay-08 Thanks Ali. May be worth modifying the sentence below to say: >>> 8) When a 802.1Q interface is used between a CE and a PE, each of the VLAN ID (VID) on that interface can be mapped onto a bridge table (for upto 4094 such bridge tables). More than one bridge table may be mapped onto a single MAC-VRF (in case of VLAN-aware bundle service). >>> Anoop On Wed, Jul 19, 2017 at 12:14 AM, Ali Sajassi (sajassi) <[email protected]<mailto:[email protected]>> wrote: From: BESS <[email protected]<mailto:[email protected]>> on behalf of Anoop Ghanwani <[email protected]<mailto:[email protected]>> Date: Tuesday, July 18, 2017 at 10:39 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: [bess] a question about bundled service in draft-ietf-bess-evpn-overlay-08 This is what the draft says about bundled service: https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-08#section-4 >>> 8) When a 802.1Q interface is used between a CE and a PE, each of the VLAN ID (VID) on that interface can be mapped onto a bridge table (for upto 4094 such bridge tables). All these bridge tables may be mapped onto a single MAC-VRF (in case of VLAN-aware bundle service). >>> So it sounds like 1:1 is supported (that's the straightforward case where the inner VLAD ID is stripped from the encap'ed packet) and All:1 is supported (i.e. the service is blind to the incoming tag and just preserves it as is, potentially with normalization if translation is required). What about the case for n:1 where I want some subset of VLAN IDs coming in on a port to map to VNID1, and another subset map to VNID2? Is that explicitly disallowed? If so, why? That's is also supported. Refer to section 6 of RFC 7432 for different service interfaces that are supported. Cheers, Ali Thanks, Anoop
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
