I don’t think it actually matters how many are in an encapsulated stack. I could think of a use case (BBF TR-101) where NVO3 was used between a BNG and a VAP where I would want to be able to encapsulate a tag stack. So I'd not want to restrict it.
Cheers Dave -----Original Message----- From: Lizhong Jin [mailto:[email protected]] Sent: Wednesday, February 05, 2014 7:08 PM To: David Allan I; [email protected]; [email protected] Subject: RE: [nvo3] NVO3 Arch: Proposed text on VLANs in L2 Service Sorry, I should say, at most one VLAN tag could be passed transparently. This limitation is not for the VAP. Thanks Lizhong David Allan I <[email protected]> wrote: >Can you clarify your comment? > >Are you referring to only one encapsulated tag (e.g. a VAP client can only >originate a single tag)...? > >Dave > >-----Original Message----- >From: nvo3 [mailto:[email protected]] On Behalf Of Lizhong Jin >Sent: Wednesday, February 05, 2014 7:52 AM >To: [email protected]; [email protected] >Subject: Re: [nvo3] NVO3 Arch: Proposed text on VLANs in L2 Service > >Hi Thomas, >I think we should limit the number of VLAN tags to be only one tag explicitly >here. > >Regards >Lizhong > > >-------------------- >Hi. > >Here is proposed text on the topic of VLANs in L2 Service. > >For terminology section: > > > <t hangText="VLAN"> > Unless stated otherwise, the terms VLAN and VLAN Tag are > used in this document denote a C-VLAN and the terms are > used interchangably to improve readability. > </t> > >Note; Following goes as a subsection withink 3.1 (at end of section) > ><section anchor="vlan-tags-section" title="VLAN Tags in L2 Service"> > <t> > An NVO3 L2 virtual network service can carry L2 VLAN tags > provided by a Tenant System, but does not use them in deciding > where and how to forward traffic. Such VLAN tags can be passed > through, so that Tenant Systems that send or expect to receive > them can be supported as appropriate. > </t> > <t> > The processing of VLAN tags that an NVE receives from a TS is > controlled by settings associated with the VAP. Just as in the > case with ports on Ethernet switches, a number of settings could > be imagined. For example, C-TAGs can be passed through > transparently, they could always be stripped upon receipt from a > Tenant System, they could be compared against a list of > explicitely confiured tags, etc. > </t> > <t> > Note that the handling of C-VIDs has additional complications, > as described in <xref target="vlan-tags-split-nve"/> below. > </t> ></section> > >Note: the following goes as a new subection 4.2.1 (subsection of >Split-NVE) > ><section anchor="vlan-tags-split-nve" title="Tenant VLAN handling in Split-NVE >Case"> > <t> > Preserving tenant VLAN tags across a NVO3 as described in > <xref target="vlan-tags-section"/> poses additional complications > in the split-NVE case. The portion of the NVE that performs the > encapsulation function needs access to the specific VLAN tags that > the Tenant System is using in order to include them in the > encapsulated packet. When an NVE is implemented entirely within > the hypervisor, the NVE has access to the complete original packet > (including any VLAN tags) sent by the tenant. In the split-NVE > case, however, the VLAN tag used between the hypervisor and > offloaded portions of the NVE normally only identify the specific > VN that traffic belongs. In order to allow a tenant to preserve > VLAN information in the split-NVE case, additional mechanisms > would be needed. > </t> ></section> > >Comments? > >Thomas > >_______________________________________________ >nvo3 mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
