I agree, my understanding was that the tagging needed to be Persistant.
J > On Feb 7, 2014, at 10:18 AM, David Allan I <[email protected]> wrote: > > Hmmm, we have a work item (WT-317 network enabled virtual residential > gateway, which BTW is a common theme in the industry these days), which for > various reasons the TR-101 tagging needs to be preserved all the way to > whatever hosts the virtual residential gateway. Which could be a VM.... > > That was the industry's thinking > Dave > > > > -----Original Message----- > From: Lizhong Jin [mailto:[email protected]] > Sent: Thursday, February 06, 2014 8:54 AM > To: David Allan I; [email protected]; [email protected] > Subject: RE: [nvo3] NVO3 Arch: Proposed text on VLANs in L2 Service > > 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
