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]>
wrote:

>
> From: BESS <[email protected]> on behalf of Anoop Ghanwani <
> [email protected]>
> Date: Tuesday, July 18, 2017 at 10:39 PM
> To: "[email protected]" <[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

Reply via email to