Hi Allan, Thomas The NVO3 charter clearly says it solves the datacenter problem. TR-101 describes the broadband network scenario as I know, and should not be an input for NVO3. For my knowledge, the double tag happens in datacenter when S-channel is enabled, but the S-Tag should be terminated on NVE. Since this is architecture draft, it is not a big problem to loose the number of tags. But I could not see the benefit to have multiple tags.
BR Lizhong David Allan I <[email protected]> wrote: >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 tha _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
