Subject: Re: [nvo3] NVO3 Arch: Proposed text on VLANs in L2 Service

From: Lizhong Jin <[email-masked]>
Date: Thu, 06 Feb 2014 11:07:40 +0800

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-masked]> 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-masked]] On Behalf Of Lizhong Jin
>Sent: Wednesday, February 05, 2014 7:52 AM
>To: [email-masked]; [email-masked]
>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-masked]
>https://www.ietf.org/mailman/listinfo/nvo3

---

From: David Allan I <[email-masked]>
Date: Thu, 6 Feb 2014 15:20:58 +0000

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-masked]] 
Sent: Wednesday, February 05, 2014 7:08 PM
To: David Allan I; [email-masked]; [email-masked]
Subject: RE: [nvo3] NVO3 Arch: Proposed text on VLANs in L2 Service

Thanks
Lizhong

---

From: Thomas Narten <[email-masked]>
Date: Thu, 06 Feb 2014 10:27:06 -0500

At Thu, 6 Feb 2014 15:20:58 +0000, David Allan I 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.

I tend to agree. The point is that whatever tag or tags are carried
end-to-end can be (and should be) transparent to NVO3 and NVO3 doesn't
use them to influence forwarding. If it is useful to preserve tags
end-to-end for use at the VAPs, why not?

What actual tags are supported (e.g., nested) would be an issue more
for the encap/VAP. While I wouldn't want to get carried away and
suggest all possible imaginable combinations of tags should be
supported, I don't see any reason to be particularly restrictive in
the architecture.

Thomas