Subject: [nvo3] VDP GroupID vs. VNID in draft-ietf-nvo3-hpvr2nve-cp-req-02

From: Benson Schliesser <[email-masked]>
Date: Sat, 21 Mar 2015 19:38:23 -0500

Speaking as an individual contributor to NVO3:

In reviewing draft-ietf-nvo3-hpvr2nve-cp-req-02, it seems to me that 
there is an assumption that a tNVE will perform local switching of e.g. 
inter-VM packets. Based on this assumption, the recommendation seems to 
be that the VDP GroupID is mapped to the VNID for a given VN.

I don't see anything wrong with that particular mode of operation. But I 
do also think it would be valuable to decouple things a bit further... 
Specifically, I can imagine two modes of operation. One of them is as 
described in the draft, where GroupID == VNID. The other might be 
described as GroupID == VAP.

This latter mode might be useful in cases where the nNVE is responsible 
for filtering of some kind, in cases where there are network services 
that must be processed for inter-TS traffic, etc. In fact it seems to me 
that we may want this latter mode to be the default behavior of a split NVE.

It's not clear to me how these different modes might be communicated via 
VDP, and/or via the NVE-NVA control plane, if they need to be 
communicated... I'd be interested to hear feedback from the authors and 
any other WG contributors that have thought about this topic.

Thanks,
-Benson

---

From: Anoop Ghanwani <[email-masked]>
Date: Sat, 21 Mar 2015 20:38:19 -0700

Let me try and see if I understand this.

Basically what you're asking for is for the Group ID to remain a proxy for
the VLAN ID, but not necessarily for the VNID.  In the case of an L2VPN,
VNID=VLAN. But in the case of L3VPN a VNID may actually represent a group
of VLANs.

If so, I agree with your assessment.

Anoop

On Sat, Mar 21, 2015 at 5:38 PM, Benson Schliesser <[email-masked]>
wrote:

> inter-VM packets. Based on this assumption, the recommendation seems to be
> that the VDP GroupID is mapped to the VNID for a given VN.
>
> described in the draft, where GroupID == VNID. The other might be described
> as GroupID == VAP.
>
> for filtering of some kind, in cases where there are network services that
> must be processed for inter-TS traffic, etc. In fact it seems to me that we
> may want this latter mode to be the default behavior of a split NVE.
>
> communicated... I'd be interested to hear feedback from the authors and any
> other WG contributors that have thought about this topic.
>
> Thanks,
> -Benson
>
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>

---

From: Benson Schliesser <[email-masked]>
Date: Sun, 22 Mar 2015 00:00:40 -0500

Hi, Anoop.

> Let me try and see if I understand this.

Everything I know about VDP was learned by reading the draft. So it's 
rather possible that I don't understand. :) But let me try to clarify my 
comments here:

> Basically what you're asking for is for the Group ID to remain a proxy
> for the VLAN ID, but not necessarily for the VNID.

Yes, that's what I mean. But to be explicit, I'm talking about the VLAN 
ID that is tagged on the wire between the tNVE and nNVE (using the 
draft's terminology).

In the draft, that tag is used to identify a VN. If there are multiple 
VMs (on the same hypervisor) attached to the same VN, they may have 
local switching inside the tNVE.

My suggestion is that, for some use-cases, the tag could be used to 
identify a VAP rather than a VN. Therefore e.g. a specific VM interface 
would be mapped to a tNVE-nNVE VLAN tag, so that the nNVE would be used 
for all switching (and filtering etc) of inter-VM traffic even if 
they're on the same hypervisor.

>  In the case of an
> L2VPN, VNID=VLAN. But in the case of L3VPN a VNID may actually represent
> a group of VLANs.

This is where I'm not sure if we are saying the same thing... Whether or 
not the VN is used to carry L2 or L3 traffic is orthogonal. In either 
case (L2 or L3) we may or may not want local tNVE switching. If not then 
we want the tNVE-nNVE VLAN tag to represent a VAP rather than VN.

Cheers,
-Benson

> On Sat, Mar 21, 2015 at 5:38 PM, Benson Schliesser
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     In reviewing draft-ietf-nvo3-hpvr2nve-cp-__req-02, it seems to me
>     that there is an assumption that a tNVE will perform local switching
>     of e.g. inter-VM packets. Based on this assumption, the
>     recommendation seems to be that the VDP GroupID is mapped to the
>     VNID for a given VN.
>
>     I don't see anything wrong with that particular mode of operation.
>     But I do also think it would be valuable to decouple things a bit
>     further... Specifically, I can imagine two modes of operation. One
>     of them is as described in the draft, where GroupID == VNID. The
>     other might be described as GroupID == VAP.
>
>     This latter mode might be useful in cases where the nNVE is
>     responsible for filtering of some kind, in cases where there are
>     network services that must be processed for inter-TS traffic, etc.
>     In fact it seems to me that we may want this latter mode to be the
>     default behavior of a split NVE.
>
>     It's not clear to me how these different modes might be communicated
>     via VDP, and/or via the NVE-NVA control plane, if they need to be
>     communicated... I'd be interested to hear feedback from the authors
>     and any other WG contributors that have thought about this topic.
>
>     Thanks,
>     -Benson
>
>     _________________________________________________
>     nvo3 mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/nvo3
>     <https://www.ietf.org/mailman/listinfo/nvo3>
>
>

---

From: Anoop Ghanwani <[email-masked]>
Date: Sat, 21 Mar 2015 22:17:38 -0700

I misunderstood what you were saying.

The mode of operation where there is no local tNVE switching is referred to
as VEPA (virtual Ethernet port aggregator) in IEEE 802.1Qbg.

In that case, if you say that a VLAN represents a VAP, what does a VNID
represent?  For the L2 case, why does it not correspond to a VLAN ID (or a
collection of VLAN IDs in the case where translation may be present)?

(But your query was about Group ID and the same Group ID can map to
different VLANs on different ports.)

Anoop

On Sat, Mar 21, 2015 at 10:00 PM, Benson Schliesser <[email-masked]>
wrote:

> Yes, that's what I mean. But to be explicit, I'm talking about the VLAN ID
> that is tagged on the wire between the tNVE and nNVE (using the draft's
> terminology).
>
> In the draft, that tag is used to identify a VN. If there are multiple VMs
> (on the same hypervisor) attached to the same VN, they may have local
> switching inside the tNVE.
>
> would be mapped to a tNVE-nNVE VLAN tag, so that the nNVE would be used for
> all switching (and filtering etc) of inter-VM traffic even if they're on
> the same hypervisor.
>
>   In the case of an
> not the VN is used to carry L2 or L3 traffic is orthogonal. In either case
> (L2 or L3) we may or may not want local tNVE switching. If not then we want
> the tNVE-nNVE VLAN tag to represent a VAP rather than VN.
>
> Cheers,
> -Benson
>
>

---

From: Benson Schliesser <[email-masked]>
Date: Sun, 22 Mar 2015 01:23:36 -0500

I suspect that we might be talking past each other here...

Let's ignore the terms VEPA, EVB, etc, because we are really focused on the
NVO3 architecture in which a TS attaches through a VAP to a VNI. And let's
not use "VLAN" because it's really just the .1Q local identifier that we
care about (not the LAN service).

In the split-NVE scenario the tNVE resides in the end device e.g.
hypervisor, and the nNVE resides in the external network element e.g. TOR.
What we need in the protocol described by this draft is a mechanism for
extending connectivity between the tNVE and nNVE. That connectivity must
support multiple logical links, each of which is identified with a .1Q tag.

The question is whether the tag represents a link to a specific TS or to a
group of TSs. In other words, is the .1Q tag being used to extend the VAP
or the VNI between the tNVE and nNVE?

Since the NVE-NVA control plane provides information to the nNVE it seems
like we need to do all overlay forwarding there. If there is no advanced
policy etc then it would be possible to delegate local TS forwarding to the
tNVE. But if we need to filter or otherwise apply policy (and services etc)
to the local TS forwarding then we must either define a mechanism for
communicating that policy to the tNVE, or use the .1Q tag as a VAP
extension and perform local TS forwarding on the nNVE.

I see use-cases for both models. Local TS forwarding can be more efficient
if delegated to the tNVE (depending on the implementation details). But the
trust model, policy, etc may require local traffic to be forwarded by an
element that is under the NVA's control.

-B

On Sunday, March 22, 2015, Anoop Ghanwani <[email-masked]> wrote:

> The mode of operation where there is no local tNVE switching is referred
> to as VEPA (virtual Ethernet port aggregator) in IEEE 802.1Qbg.
>
> On Sat, Mar 21, 2015 at 10:00 PM, Benson Schliesser <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>> Hi, Anoop.
>>
>> Anoop Ghanwani wrote:
>>
>> ID that is tagged on the wire between the tNVE and nNVE (using the draft's
>> terminology).
>>
>> VMs (on the same hypervisor) attached to the same VN, they may have local
>>> <[email-masked]
>>> <javascript:_e(%7B%7D,'cvml',[email-masked]');> <mailto:
>>> [email-masked]
>>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>> wrote:
>>>
>>>     [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>>> <mailto:[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>

---

From: Anoop Ghanwani <[email-masked]>
Date: Sun, 22 Mar 2015 06:59:35 -0700

To me, I see the tag as extending the VNI (for L2 case only).  There are
other ways to extend the VAP if that is what is desired an if the source
MAC address is not sufficient to achieve that (e.g. S-tags via multichannel
or 802.1BR, port extenders).

(If we have multiple devices with the same VLAN for which we need to apply
policy at the nNVE, how do we do it if the VLAN is used to determine the
VAP?)

Anoop

On Sat, Mar 21, 2015 at 11:23 PM, Benson Schliesser <[email-masked]>
wrote:

> Let's ignore the terms VEPA, EVB, etc, because we are really focused on
> the NVO3 architecture in which a TS attaches through a VAP to a VNI. And
> let's not use "VLAN" because it's really just the .1Q local identifier that
> we care about (not the LAN service).
>
>> On Sat, Mar 21, 2015 at 10:00 PM, Benson Schliesser <
>> [email-masked]> wrote:
>>
>>> Hi, Anoop.
>>>
>>> Anoop Ghanwani wrote:
>>>

---

From: Lucy yong <[email-masked]>
Date: Sun, 22 Mar 2015 18:12:41 +0000

I agree with Benson that both modes on tNVE are useful. Hypervispor needs to convey tNVE mode to nNVE. Regardless of the mode, group ID should represent TS's VAP and VDP allows multiple TSes to share the same VAP ID, which covers both modes.

Lucy

From: nvo3 [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
Sent: Sunday, March 22, 2015 9:00 AM
To: Benson Schliesser
Cc: [email-masked]; [email-masked]
Subject: Re: [nvo3] VDP GroupID vs. VNID in draft-ietf-nvo3-hpvr2nve-cp-req-02

The question is whether the tag represents a link to a specific TS or to a group of TSs. In other words, is the .1Q tag being used to extend the VAP or the VNI between the tNVE and nNVE?

To me, I see the tag as extending the VNI (for L2 case only).  There are other ways to extend the VAP if that is what is desired an if the source MAC address is not sufficient to achieve that (e.g. S-tags via multichannel or 802.1BR, port extenders).

(If we have multiple devices with the same VLAN for which we need to apply policy at the nNVE, how do we do it if the VLAN is used to determine the VAP?)

Anoop

On Sat, Mar 21, 2015 at 11:23 PM, Benson Schliesser <[email-masked]<mailto:[email-masked]>> wrote:
I suspect that we might be talking past each other here...

Let's ignore the terms VEPA, EVB, etc, because we are really focused on the NVO3 architecture in which a TS attaches through a VAP to a VNI. And let's not use "VLAN" because it's really just the .1Q local identifier that we care about (not the LAN service).

In the split-NVE scenario the tNVE resides in the end device e.g. hypervisor, and the nNVE resides in the external network element e.g. TOR. What we need in the protocol described by this draft is a mechanism for extending connectivity between the tNVE and nNVE. That connectivity must support multiple logical links, each of which is identified with a .1Q tag.

The question is whether the tag represents a link to a specific TS or to a group of TSs. In other words, is the .1Q tag being used to extend the VAP or the VNI between the tNVE and nNVE?

Since the NVE-NVA control plane provides information to the nNVE it seems like we need to do all overlay forwarding there. If there is no advanced policy etc then it would be possible to delegate local TS forwarding to the tNVE. But if we need to filter or otherwise apply policy (and services etc) to the local TS forwarding then we must either define a mechanism for communicating that policy to the tNVE, or use the .1Q tag as a VAP extension and perform local TS forwarding on the nNVE.

I see use-cases for both models. Local TS forwarding can be more efficient if delegated to the tNVE (depending on the implementation details). But the trust model, policy, etc may require local traffic to be forwarded by an element that is under the NVA's control.

-B

On Sunday, March 22, 2015, Anoop Ghanwani <[email-masked]<mailto:[email-masked]>> wrote:
I misunderstood what you were saying.

The mode of operation where there is no local tNVE switching is referred to as VEPA (virtual Ethernet port aggregator) in IEEE 802.1Qbg.

In that case, if you say that a VLAN represents a VAP, what does a VNID represent?  For the L2 case, why does it not correspond to a VLAN ID (or a collection of VLAN IDs in the case where translation may be present)?

(But your query was about Group ID and the same Group ID can map to different VLANs on different ports.)

Anoop

On Sat, Mar 21, 2015 at 10:00 PM, Benson Schliesser <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Anoop.

Anoop Ghanwani wrote:

Everything I know about VDP was learned by reading the draft. So it's rather possible that I don't understand. :) But let me try to clarify my comments here:
Basically what you're asking for is for the Group ID to remain a proxy
for the VLAN ID, but not necessarily for the VNID.

Yes, that's what I mean. But to be explicit, I'm talking about the VLAN ID that is tagged on the wire between the tNVE and nNVE (using the draft's terminology).

In the draft, that tag is used to identify a VN. If there are multiple VMs (on the same hypervisor) attached to the same VN, they may have local switching inside the tNVE.

My suggestion is that, for some use-cases, the tag could be used to identify a VAP rather than a VN. Therefore e.g. a specific VM interface would be mapped to a tNVE-nNVE VLAN tag, so that the nNVE would be used for all switching (and filtering etc) of inter-VM traffic even if they're on the same hypervisor.
 In the case of an
L2VPN, VNID=VLAN. But in the case of L3VPN a VNID may actually represent
a group of VLANs.

This is where I'm not sure if we are saying the same thing... Whether or not the VN is used to carry L2 or L3 traffic is orthogonal. In either case (L2 or L3) we may or may not want local tNVE switching. If not then we want the tNVE-nNVE VLAN tag to represent a VAP rather than VN.

Cheers,
-Benson

Anoop

On Sat, Mar 21, 2015 at 5:38 PM, Benson Schliesser
<[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>> wrote:

    Thanks,
    -Benson

    _________________________________________________
    nvo3 mailing list
    [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
    https://www.ietf.org/mailman/__listinfo/nvo3
    <https://www.ietf.org/mailman/listinfo/nvo3>

---

From: Liyizhou <[email-masked]>
Date: Sun, 22 Mar 2015 18:59:04 +0000

There is no assumption that a tNVE will always perform local switching of e.g. inter-VM packets. I agree that 2 modes of operations are possible when VM tries to forward the frame to another VM attached to the same hypervisor. Let's call it local forwarding for hypervisor locally forward to another VM and hairpin forwarding for traffic is forced to go through external NVE.   Currently 802.1 uses LLDP based extension to let each other find out if hairpin forwarding is supported by both sides and if yes the hypervisor can notify external NVE whether to enable the hairpin forwarding. This mechanism is independent from VDP though it is put together as VDP in 802.1Qbg. From my understanding we can simply re-use it with the following exceptional case to consider.

NVO3 allows the hypervisor indirectly connected to external NVE via some classic bridge though in VDP case it has to be direct connection. If hairpin forwarding on external NVE is enabled in indirect connection case, the same packet would be possibly received duplicately by other VN attaching to other tNVE connecting to same class bridge as the pic below.

VM1's multicast packet could be forwarded by classic bridge B1 to VM3 and at the same time, external NVE wants to hairpin it to VM2 intentionally since tNVE1 disabled local forwarding. Then classic bridge B1 will send another copy to VM3 from external NVE. (Assume all VMs are from the same VNs/VLANs)

I think we need to figure out how external NVE perform the hairpin forwarding in this case before deciding if any other extension is required. Personally I prefer not to enable hairpin forwarding in any indirect connection case. Otherwise we still need some intelligence on intermediate classic bridge B1.

Yizhou

From: nvo3 [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
Sent: Sunday, March 22, 2015 10:00 PM
To: Benson Schliesser
Cc: [email-masked]; [email-masked]
Subject: Re: [nvo3] VDP GroupID vs. VNID in draft-ietf-nvo3-hpvr2nve-cp-req-02

Anoop

-B

Anoop

Anoop Ghanwani wrote:

Cheers,
-Benson

Anoop

    Thanks,
    -Benson

---

From: Benson Schliesser <[email-masked]>
Date: Sun, 22 Mar 2015 14:16:51 -0500

Hi, Yizhou. Thanks for your note.

Liyizhou wrote:
> I think we need to figure out how external NVE perform the hairpin
> forwarding in this case before deciding if any other extension is
> required. Personally I prefer not to enable hairpin forwarding in any
> indirect connection case. Otherwise we still need some intelligence on
> intermediate classic bridge B1.

Is this true if we use a distinct Q tag for each VM? I.e. if we use the 
tag to identify a VAP, and do *not* think of this as Q-tag = VN, then we 
should be able to switch through intermediate devices and "hairpin" 
forward on the nNVE when appropriate. Is this correct and/or am I 
missing something?

Cheers,
-Benson

---

From: Liyizhou <[email-masked]>
Date: Sun, 22 Mar 2015 19:23:59 +0000

Typo

second paragraph: received duplicately by other VN -> should be VM

From: Liyizhou
Sent: Monday, March 23, 2015 2:59 AM
To: 'Anoop Ghanwani'; Benson Schliesser
Cc: [email-masked]; [email-masked]
Subject: RE: [nvo3] VDP GroupID vs. VNID in draft-ietf-nvo3-hpvr2nve-cp-req-02

Yizhou

From: nvo3 [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
Sent: Sunday, March 22, 2015 10:00 PM
To: Benson Schliesser
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [nvo3] VDP GroupID vs. VNID in draft-ietf-nvo3-hpvr2nve-cp-req-02

Anoop

-B

Anoop

Anoop Ghanwani wrote:

Cheers,
-Benson

Anoop

    Thanks,
    -Benson

---

From: Liyizhou <[email-masked]>
Date: Sun, 22 Mar 2015 19:44:07 +0000

Benson,

I am a little bit confused about tag for VAP concept. In my understanding, tag for VAP is equivalent to tag for VN since VAP is (logical) port per VN thing according to arch draft?

If we assign a tag per VM, I agree that duplication by hairpin problem in indirect case does not exist any more. However hairpin-ed multicast packets has to be unicast with different Q-tag to the intented VMs? That would be tedious.

Another approach could be having two tags. One for VN, another for tNVE. Hairpin-ed packets has to be delivered to certain tNVE first and then to VMs in certain VN attached to that specific tNVE.

Yizhou

-----Original Message-----
From: Benson Schliesser [mailto:[email-masked]] 
Sent: Monday, March 23, 2015 3:17 AM
To: Liyizhou
Cc: Anoop Ghanwani; [email-masked]; [email-masked]
Subject: Re: [nvo3] VDP GroupID vs. VNID in draft-ietf-nvo3-hpvr2nve-cp-req-02

> intermediate classic bridge B1.

Is this true if we use a distinct Q tag for each VM? I.e. if we use the tag to identify a VAP, and do *not* think of this as Q-tag = VN, then we should be able to switch through intermediate devices and "hairpin" 
forward on the nNVE when appropriate. Is this correct and/or am I missing something?

Cheers,
-Benson

---

From: Anoop Ghanwani <[email-masked]>
Date: Sun, 22 Mar 2015 16:42:07 -0500

Benson,

This is a new model for bridging.  It's easy to see how it can be made to work for unicast; less so for multicast.

Let me just say, I don't disagree with the need for Group ID to represent a VAP rather than the VNI.  But my reason for why it's needed is different from yours.

Anoop

Sent from my iPhone

> On Mar 22, 2015, at 2:16 PM, Benson Schliesser <[email-masked]> wrote:
> 
> Is this true if we use a distinct Q tag for each VM? I.e. if we use the tag to identify a VAP, and do *not* think of this as Q-tag = VN, then we should be able to switch through intermediate devices and "hairpin" forward on the nNVE when appropriate. Is this correct and/or am I missing something?
> 
> Cheers,
> -Benson

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Mon, 23 Mar 2015 19:56:55 +0000

Hi Benson,

Chiming in a bit late, but I believe I understand what you are getting at.

My first comment is that my interpretation of the NVO3 architecture so far
is that policy is applied when traffic enter/leaves a VN.  If you look at
the text I recently added to the architecture, I mention that the main
motivation for L2VN to L2VN or L3VN to L3VN gateways are to enforce policy.
In other words, TS on the same VN are expected to have full communication
with each other.

Second, (and I need to say I am NOT an expert on the IEEE VEB/VEPA
standards)
is that what you are asking for is covered by 802.1qbh (what we at Cisco
call VN-Tag).  I am unsure if it works across a classic bridge or not.
Also, using a single VLAN tag seems like it would be too limiting
to carry all the VAPs, but I could see perhaps Q-in-Q working for your use
case.

 - Larry

---

From: "Joe Pelissier (jopeliss)" <[email-masked]>
Date: Mon, 23 Mar 2015 20:10:45 +0000

A quick correction:  What Larry referred to as 802.1qbh is actually 802.1BR.

802.1BR was not intended to operate across a classic bridge, but anything is possible ;-)

Anyway, I think we are getting confused here with the concept that the NVE is split.  As I stated before, in my (probably naïve) opinon, the external NVE is the NVE, and there is no tNVE.  The tennate system is simply running VDP for any of the many reasons that it might decide to run VDP, and the network devices (bridge, VEPA, extended bridge, and/or NVE) do the right thing.  The TS does not need to know what network devices are actually being used to deliver its packets.

Barely $0.02 worth..
Joe

-----Original Message-----
From: nvo3 [mailto:[email-masked]] On Behalf Of Larry Kreeger (kreeger)
Sent: Monday, March 23, 2015 2:57 PM
To: Benson Schliesser; [email-masked]; [email-masked]
Subject: Re: [nvo3] VDP GroupID vs. VNID in draft-ietf-nvo3-hpvr2nve-cp-req-02

Hi Benson,

My first comment is that my interpretation of the NVO3 architecture so far is that policy is applied when traffic enter/leaves a VN.  If you look at the text I recently added to the architecture, I mention that the main motivation for L2VN to L2VN or L3VN to L3VN gateways are to enforce policy.
In other words, TS on the same VN are expected to have full communication with each other.

Second, (and I need to say I am NOT an expert on the IEEE VEB/VEPA
standards)
is that what you are asking for is covered by 802.1qbh (what we at Cisco call VN-Tag).  I am unsure if it works across a classic bridge or not.
Also, using a single VLAN tag seems like it would be too limiting to carry all the VAPs, but I could see perhaps Q-in-Q working for your use case.

 - Larry

On 3/21/15 7:38 PM, "Benson Schliesser" <[email-masked]> wrote:

>I don't see anything wrong with that particular mode of operation. But 
>I do also think it would be valuable to decouple things a bit further...
>that must be processed for inter-TS traffic, etc. In fact it seems to 
>me that we may want this latter mode to be the default behavior of a 
>split NVE.
>

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Mon, 23 Mar 2015 21:40:49 +0000

Hi Joe,

Thanks for the correction.  I agree with you about the tNVE/nNVE split.
IMO, we should not really consider the tNVE to be an NVE.  It is simply
something that knows if want to make use of an external device to perform
networking.  It can be completely unaware of how (or even if) network
virtualization is taking place.

Currently, we have been assuming that there is local switching happening,
either in the hypervisor vSwitch, or by the classic bridge (if it exists
between the hypervisor and the nNVE).  All policy enforcement would happen
in the nNVE.  The tNVE is extremely lightweight and does not even have a
channel to the NVA to get the policy to enforce.

So, my question to you Benson is, what is the use case for performing
policy enforcement within a VN, as opposed to across VNs?

 - Larry

On 3/23/15 3:10 PM, "Joe Pelissier (jopeliss)" <[email-masked]> wrote:

>Anyway, I think we are getting confused here with the concept that the
>NVE is split.  As I stated before, in my (probably naïve) opinon, the
>external NVE is the NVE, and there is no tNVE.  The tennate system is
>simply running VDP for any of the many reasons that it might decide to
>run VDP, and the network devices (bridge, VEPA, extended bridge, and/or
>NVE) do the right thing.  The TS does not need to know what network
>devices are actually being used to deliver its packets.
>
>Barely $0.02 worth..
>Joe
>
>To: Benson Schliesser; [email-masked];
>[email-masked]
>My first comment is that my interpretation of the NVO3 architecture so
>far is that policy is applied when traffic enter/leaves a VN.  If you
>look at the text I recently added to the architecture, I mention that the
>main motivation for L2VN to L2VN or L3VN to L3VN gateways are to enforce
>policy.
>Also, using a single VLAN tag seems like it would be too limiting to
>carry all the VAPs, but I could see perhaps Q-in-Q working for your use
>case.
>
> - Larry
>