Subject: [nvo3] Comments on draft-dunbar-nvo3-overlay-mobility-issues

From: "Guyingjie (Yingjie)" <[email-masked]>
Date: Thu, 5 Jul 2012 01:14:55 +0000

Hi Linda,
I read your draft on NVO3-mobility.
I am okay with most of the content, just some secondary comments on your description of mechanism between NVE and TES.
In my mind, external controller assistance is a bit more complicate to implement than using a protocol between NVEs and TES.
A premise of my comments is that NVE is on external network devices, such as TOR and EOR, and TES are VMs in physical servers.

4.1.1 First paragraph: "NVEs may
   not be aware of VMs being added or deleted unless NVEs have a north
   bound interface to a controller which can communicate with VM/server
   Manager(s).

"
This is not true. In VDP, with an Association/De-association message from Hypervisor to edge bridge(i.e. NVE in NVO3, and will use NVE instead of edge bridge in below), the bridge can be timely notified about the connect and disconnect to the bridge. That means it doesn't need an northbound API for NVEs to be aware of VMs (dis)connection.  And also, VDP protocol can carry a field showing "This is a new created VM" or "This is a VM migrated from somewhere else". That is VDP can fulfill the requirement of mobility notification, which can be a trigger for NVE to timely updating the states on itself, e.g. acquiring VNID associated with the VM moving/adding to the NVE, inner-outer address mapping, deleting states associated with the VM moving/deleting from this NVE.

In the 4th paragraph of 4.1.1, If, for whatever reason, it is necessary to have local VID in the

   data frames before encapsulating outer header of EgressNVE-DA/

   IngressNVE-SA /VNID, NVE should get the specific local VID from the

   external Controller for those untagged data frames coming to each

   Virtual Access Point
For some reasons, I don't think this part is good.
First, there is other way to get the local VID except for external controller. In VDP, when NVE receives a (Pre)Association message from TES, it can acquire local VID from a Database which is managed by network administrator.

Secondly, while defining VDP, we consider of the situation you described, i.e. different local VID at different location. So the VDP can support different local VID under different NVE, by getting local VID from Database while receive the (Pre)Association message. And it can even feedback to the Hypervisor, so that the data frames from TES could have the local VID on it, but it's also okay for NVE to add the local VID to data frames.

In the 6th paragraph in 4.1.1, The IEEE802.1Qbg's VDP protocol (Virtual Station Interface (VSI)

   discovery and configuration protocol) requires hypervisor to send VM

   profile upon a new VM is instantiated. However, not all hypervisors

   support this function.
The following is the VDP TLV definition from Qbg. Each VSI (Virtual Station Interface) usually is a VM interface id(could be MAC,IPV4/V6, UUID, etc).
The NVE gets profile from Database by VSI type & instance information. I think your profile ID also means the combination of VSI type and instance information. So we are talking the same thing.   My point is it's not profile, but the IDs to get profile, that is carried in VDP message. It might be confusing to people knowing nothing about VDP. Carrying profile in message is a huge overload.

External Controller can be very useful in NVO3, but not best suitable for each part of NVO3. I think we should think of other way for different problems.

________________________________
Best Regards
Gu Yingjie

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 9 Jul 2012 19:27:30 +0000

Ying Jie,

Thank you very much for the nice comments. My replies are inserted below:

From: Guyingjie (Yingjie)
Sent: Wednesday, July 04, 2012 8:15 PM
To: [email-masked]; Linda Dunbar
Subject: Comments on draft-dunbar-nvo3-overlay-mobility-issues

Hi Linda,

"

[Linda]  In your IEEE802.1Qbg's VDP example, the NVE would be the Hypervisor which sends Association/De-association messages to the edge bridge. I.e. the Hypervisor need to have north bound interface which is aware a VM is add or deleted.

I think that the sentence should have stated as "NVEs may not be aware of the VMs being added or deleted unless NVEs have a north bound interface to a controller which can communicate with VM/Server managers, or there is a protocol between TES and NVEs as defined by IEEE802.1Qbg.

However, it is a security hole to let TES inform NVEs of being added or deleted, unless it is in a secure environment, or NVEs (or Hypervisors) can validate the information from TES via its management system.

   Virtual Access Point
For some reasons, I don't think this part is good.
First, there is other way to get the local VID except for external controller. In VDP, when NVE receives a (Pre)Association message from TES, it can acquire local VID from a Database which is managed by network administrator.
[Linda] Yes, I should have added that NVE can also get local VID from TES as IEEE802.1Qbg defined.

[Linda] it is all good if TES can have those functions. But in many environment, TES don't. This paragraph is emphasizing on the scenario when TES don't support IEEE802.1Qbg. It is a good idea that you point out the functions of IEEE802.1Qbg.

   support this function.

[Linda] Thanks for sharing this table.

Linda

---

From: <[email-masked]>
Date: Tue, 10 Jul 2012 09:17:01 -0400

Hi Linda,

I don't think so.  If the NVE is in the hypervisor, the external Ethernet switches (bridges) don't see the inner MACs after encapsulation, hence VDP to the external Ethernet switch (bridge) is not useful because it sets up inner MACs that won't occur in the outer headers beyond the hypervisor's NVE.  If the NVE is in the external Ethernet switch (bridge), VDP is useful because then it's running between the TES and the NVE.

I'm not sure that "secure environment" sets the right expectation.

For an external NVE, it's necessary to trust the hypervisor to provide info on VM attach/detach, so the security concern is that this info come only from the hypervisor.  For VDP this starts with use of a link-local destination MAC - if a VM sends to this MAC, the virtual switch in the hypervisor is the recipient.  That virtual switch doesn't forward the VDP frames, and probably just drops them. For an SR-IOV NIC in the server, the virtual switch in the NIC has to drop VDP frames sent by a VM so that VDP frames originate only from the hypervisor.  If an IP-based protocol is used for this function, authentication will be needed.  For an NVE in the hypervisor, the hypervisor configures its virtual switch directly and VDP does not run outside the hypervisor.

Thanks,
--David

From: [email-masked] [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Monday, July 09, 2012 3:28 PM
To: Guyingjie (Yingjie); [email-masked]
Subject: Re: [nvo3] Comments on draft-dunbar-nvo3-overlay-mobility-issues

Ying Jie,

Hi Linda,

"

   Virtual Access Point

   support this function.

Linda

---

From: "Stiliadis, Dimitrios (Dimitri)" <[email-masked]>
Date: Tue, 10 Jul 2012 10:27:24 -0500

David,

As far as I know, VDP doesn't have an authentication mechanism. The NVE needs to verify
that the hypervisor is who it says that it is, and same for the hypervisor. A secure solution
would have some form of authentication. This would enable greater flexibility  in the
positioning of NVEs.

Dimitri

Thanks,
--David

Ying Jie,

Hi Linda,

"

   Virtual Access Point

   support this function.

Linda

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 10 Jul 2012 15:48:43 +0000

David,

IEEE802.1 Qbg's VDP doesn't do encapsulation, so it is different from NVo3's NVE. VDP allows the hypervisor to notify the network of the virtual network  to which the new VMs belong. In that aspect, there is similarity to NVo3's NVE.

Hypervisor may be trusted, but  I don't think DC operators can trust VMs. When VMs are instantiated with applications from random clients, whose applications can initiate attack to other clients network. It happened once in Amazon's EC2.
Security will be a big concern for any protocols from TES to NVE.

Linda

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 10, 2012 8:17 AM
To: Linda Dunbar; [email-masked]
Subject: TES-NVE attach/detach protocol security (mobility-issues draft)

Hi Linda,

For an external NVE, it's necessary to trust the hypervisor to provide info on VM attach/detach, so the security concern is that this info come only from the hypervisor.

For VDP this starts with use of a link-local destination MAC - if a VM sends to this MAC, the virtual switch in the hypervisor is the recipient.  That virtual switch doesn't forward the VDP frames, and probably just drops them. For an SR-IOV NIC in the server, the virtual switch in the NIC has to drop VDP frames sent by a VM so that VDP frames originate only from the hypervisor.  If an IP-based protocol is used for this function, authentication will be needed.  For an NVE in the hypervisor, the hypervisor configures its virtual switch directly and VDP does not run outside the hypervisor.

Thanks,
--David

Ying Jie,

Hi Linda,

"

   Virtual Access Point

   support this function.

Linda

---

From: <[email-masked]>
Date: Tue, 10 Jul 2012 12:27:49 -0400

Linda,

We're mostly in agreement ...

Right - VDP is a protocol that can be used between TES and NVE.  For a hypervisor, VDP would only be used on a link to an external NVE (e.g., in the ToR switch).  If the NVE is inside the hypervisor there's no external TES-NVE protocol because both the TES and NVE are in the same physical server.

Hypervisor may be trusted, but  I don't think DC operators can trust VMs.

I agree, and VDP approaches this via use of a link-local destination MAC address for all VDP frames sent to the NVE.  If a VM sends a VDP frame, that frame is received by a virtual switch in the hypervisor, and so a simple solution is for virtual switches to drop and ignore all VDP frames sent by VMs.  An SR-IOV NIC would be configured to do likewise for VDP frames sent by VMs.  In both cases, this enables an external NVE in a ToR switch to rely on the VDP frames it receives having been originated by the hypervisor and not the VMs.

I agree, and any IP based TES-NVE protocol will be unable to rely on link-local destination MACs, hence I would expect authentication to be at least a "MUST implement" requirement if an IP-based protocol is used.

Thanks,
--David

From: Linda Dunbar [mailto:[email-masked]]
Sent: Tuesday, July 10, 2012 11:49 AM
To: Black, David; [email-masked]
Subject: RE: TES-NVE attach/detach protocol security (mobility-issues draft)

David,

Linda

Hi Linda,

Thanks,
--David

Ying Jie,

Hi Linda,

"

   Virtual Access Point

   support this function.

Linda

---

From: <[email-masked]>
Date: Tue, 10 Jul 2012 12:33:41 -0400

Dimitri,

VDP is always sent to a link-local MAC; bridges/switches don't forward VDP frames.  If one can rely on the hypervisor being correctly configured (e.g., virtual switches receive, drop and ignore VDP frames sent by VMs), and link integrity can also be relied upon (e.g., no injection of VDP frames), the ToR switch that receives a VDP frame can safely assume that the hypervisor sent it.

If either of those elements cannot be relied upon, or the NVE needs to be located further away from the TES than the other end of the same Ethernet link, then something else in the way of authentication would be needed.

Thanks,
--David

From: Stiliadis, Dimitrios (Dimitri) [mailto:[email-masked]]
Sent: Tuesday, July 10, 2012 11:27 AM
To: Black, David; [email-masked]; [email-masked]
Subject: RE: [nvo3] TES-NVE attach/detach protocol security (mobility-issues draft)

David,

Dimitri

Thanks,
--David

Ying Jie,

Hi Linda,

"

   Virtual Access Point

   support this function.

Linda

---

From: "Stiliadis, Dimitrios (Dimitri)" <[email-masked]>
Date: Tue, 10 Jul 2012 12:03:27 -0500

David:

Blade systems, where the NVE is the ToR is one example where this gets messy. Traffic
goes from the blades to an L2 switch to the ToR, and some people also want to offer
bare metal as a service in such systems.

Cheers,

Dimitri

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 10, 2012 9:34 AM
To: Stiliadis, Dimitrios (Dimitri); [email-masked]
Subject: RE: [nvo3] TES-NVE attach/detach protocol security (mobility-issues draft)

Dimitri,

Thanks,
--David

David,

Dimitri

Thanks,
--David

Ying Jie,

Hi Linda,

"

   Virtual Access Point

   support this function.

Linda

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Wed, 11 Jul 2012 03:06:38 +0000

Trying to clarify the discussion below…using the terminology from draft-lasserre-nvo3-framework-03

A TES (tenant end system) is not a trusted entity and would not use VDP to communicate to an NVE.  It is an "End System" that would use VDP to communicate to an NVE, which would be a trusted device within the data center that is administered by the data center operator – NOT a tenant.

 - Larry

From: David Black <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 10, 2012 9:27 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] TES-NVE attach/detach protocol security (mobility-issues draft)

Linda,

We’re mostly in agreement ...

IEEE802.1 Qbg’s VDP doesn’t do encapsulation, so it is different from NVo3’s NVE. VDP allows the hypervisor to notify the network of the virtual network  to which the new VMs belong. In that aspect, there is similarity to NVo3’s NVE.

Right - VDP is a protocol that can be used between TES and NVE.  For a hypervisor, VDP would only be used on a link to an external NVE (e.g., in the ToR switch).  If the NVE is inside the hypervisor there’s no external TES-NVE protocol because both the TES and NVE are in the same physical server.

Hypervisor may be trusted, but  I don’t think DC operators can trust VMs.

I agree, and any IP based TES-NVE protocol will be unable to rely on link-local destination MACs, hence I would expect authentication to be at least a “MUST implement” requirement if an IP-based protocol is used.

Thanks,
--David

From: Linda Dunbar [mailto:[email-masked]]
Sent: Tuesday, July 10, 2012 11:49 AM
To: Black, David; [email-masked]<mailto:[email-masked]>
Subject: RE: TES-NVE attach/detach protocol security (mobility-issues draft)

David,

IEEE802.1 Qbg’s VDP doesn’t do encapsulation, so it is different from NVo3’s NVE. VDP allows the hypervisor to notify the network of the virtual network  to which the new VMs belong. In that aspect, there is similarity to NVo3’s NVE.

Hypervisor may be trusted, but  I don’t think DC operators can trust VMs. When VMs are instantiated with applications from random clients, whose applications can initiate attack to other clients network. It happened once in Amazon’s EC2.
Security will be a big concern for any protocols from TES to NVE.

Linda

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, July 10, 2012 8:17 AM
To: Linda Dunbar; [email-masked]<mailto:[email-masked]>
Subject: TES-NVE attach/detach protocol security (mobility-issues draft)

Hi Linda,

[Linda]  In your IEEE802.1Qbg’s VDP example, the NVE would be the Hypervisor which sends Association/De-association messages to the edge bridge. I.e. the Hypervisor need to have north bound interface which is aware a VM is add or deleted.

I don’t think so.  If the NVE is in the hypervisor, the external Ethernet switches (bridges) don’t see the inner MACs after encapsulation, hence VDP to the external Ethernet switch (bridge) is not useful because it sets up inner MACs that won’t occur in the outer headers beyond the hypervisor’s NVE.  If the NVE is in the external Ethernet switch (bridge), VDP is useful because then it’s running between the TES and the NVE.

I’m not sure that “secure environment” sets the right expectation.

For an external NVE, it’s necessary to trust the hypervisor to provide info on VM attach/detach, so the security concern is that this info come only from the hypervisor.

For VDP this starts with use of a link-local destination MAC - if a VM sends to this MAC, the virtual switch in the hypervisor is the recipient.  That virtual switch doesn’t forward the VDP frames, and probably just drops them. For an SR-IOV NIC in the server, the virtual switch in the NIC has to drop VDP frames sent by a VM so that VDP frames originate only from the hypervisor.  If an IP-based protocol is used for this function, authentication will be needed.  For an NVE in the hypervisor, the hypervisor configures its virtual switch directly and VDP does not run outside the hypervisor.

Thanks,
--David

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Monday, July 09, 2012 3:28 PM
To: Guyingjie (Yingjie); [email-masked]<mailto:[email-masked]>
Subject: Re: [nvo3] Comments on draft-dunbar-nvo3-overlay-mobility-issues

Ying Jie,

From: Guyingjie (Yingjie)
Sent: Wednesday, July 04, 2012 8:15 PM
To: [email-masked]<mailto:[email-masked]>; Linda Dunbar
Subject: Comments on draft-dunbar-nvo3-overlay-mobility-issues

Hi Linda,

4.1.1 First paragraph: “NVEs may
   not be aware of VMs being added or deleted unless NVEs have a north
   bound interface to a controller which can communicate with VM/server
   Manager(s).

”
This is not true. In VDP, with an Association/De-association message from Hypervisor to edge bridge(i.e. NVE in NVO3, and will use NVE instead of edge bridge in below), the bridge can be timely notified about the connect and disconnect to the bridge. That means it doesn’t need an northbound API for NVEs to be aware of VMs (dis)connection.  And also, VDP protocol can carry a field showing “This is a new created VM” or “This is a VM migrated from somewhere else”. That is VDP can fulfill the requirement of mobility notification, which can be a trigger for NVE to timely updating the states on itself, e.g. acquiring VNID associated with the VM moving/adding to the NVE, inner-outer address mapping, deleting states associated with the VM moving/deleting from this NVE.

[Linda]  In your IEEE802.1Qbg’s VDP example, the NVE would be the Hypervisor which sends Association/De-association messages to the edge bridge. I.e. the Hypervisor need to have north bound interface which is aware a VM is add or deleted.

I think that the sentence should have stated as “NVEs may not be aware of the VMs being added or deleted unless NVEs have a north bound interface to a controller which can communicate with VM/Server managers, or there is a protocol between TES and NVEs as defined by IEEE802.1Qbg.

   Virtual Access Point
For some reasons, I don’t think this part is good.
First, there is other way to get the local VID except for external controller. In VDP, when NVE receives a (Pre)Association message from TES, it can acquire local VID from a Database which is managed by network administrator.
[Linda] Yes, I should have added that NVE can also get local VID from TES as IEEE802.1Qbg defined.

Secondly, while defining VDP, we consider of the situation you described, i.e. different local VID at different location. So the VDP can support different local VID under different NVE, by getting local VID from Database while receive the (Pre)Association message. And it can even feedback to the Hypervisor, so that the data frames from TES could have the local VID on it, but it’s also okay for NVE to add the local VID to data frames.

[Linda] it is all good if TES can have those functions. But in many environment, TES don’t. This paragraph is emphasizing on the scenario when TES don’t support IEEE802.1Qbg. It is a good idea that you point out the functions of IEEE802.1Qbg.

   support this function.
The following is the VDP TLV definition from Qbg. Each VSI (Virtual Station Interface) usually is a VM interface id(could be MAC,IPV4/V6, UUID, etc).
The NVE gets profile from Database by VSI type & instance information. I think your profile ID also means the combination of VSI type and instance information. So we are talking the same thing.   My point is it’s not profile, but the IDs to get profile, that is carried in VDP message. It might be confusing to people knowing nothing about VDP. Carrying profile in message is a huge overload.

Linda

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Wed, 11 Jul 2012 03:27:36 +0000

Agree with Larry. It is the end-system talking VDP with the NVE.  If the end-system and NVE belongs to the same DC operator, then the end-system is in the trusted zone of the operator.

A different point on l3, if it is L3 overlay tunnel starting at the end-system, I'd assume no VDP involvement.

Luyuan

From: [email-masked] [mailto:[email-masked]] On Behalf Of Larry Kreeger (kreeger)
Sent: Tuesday, July 10, 2012 11:07 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [nvo3] TES-NVE attach/detach protocol security (mobility-issues draft)

Trying to clarify the discussion below...using the terminology from draft-lasserre-nvo3-framework-03

A TES (tenant end system) is not a trusted entity and would not use VDP to communicate to an NVE.  It is an "End System" that would use VDP to communicate to an NVE, which would be a trusted device within the data center that is administered by the data center operator - NOT a tenant.

 - Larry

Linda,

Thanks,
--David

David,

Linda

Hi Linda,

Thanks,
--David

Ying Jie,

Hi Linda,

"

   Virtual Access Point

   support this function.

Linda

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 11 Jul 2012 03:28:53 +0000

As per the definition in 802.1Qbg, “…When ECP is used as a transport protocol for VDP, ECP uses the Nearest Customer Bridge group MAC
address (Table 8-1) as the destination address for ECPDUs…” Hence if the blade switch is not enabled with 802.1D, it should still be able to transparently forward the VDP packets as if they were normal MAC frames received from the default VLAN, just like it could transparently forward the BPDU frame which also uses the Nearest Customer Bridge group MAC address(i.e., 01-80-C2-00- 00-00) as the destination MAC address.

Best regards,
Xiaohu

发件人: [email-masked] [mailto:[email-masked]] 代表 Stiliadis, Dimitrios (Dimitri)
发送时间: 2012年7月11日 1:03
收件人: [email-masked]; [email-masked]
主题: Re: [nvo3] TES-NVE attach/detach protocol security (mobility-issues draft)

David:

Cheers,

Dimitri

Dimitri,

VDP is always sent to a link-local MAC; bridges/switches don’t forward VDP frames.  If one can rely on the hypervisor being correctly configured (e.g., virtual switches receive, drop and ignore VDP frames sent by VMs), and link integrity can also be relied upon (e.g., no injection of VDP frames), the ToR switch that receives a VDP frame can safely assume that the hypervisor sent it.

Thanks,
--David

David,

As far as I know, VDP doesn’t have an authentication mechanism. The NVE needs to verify
that the hypervisor is who it says that it is, and same for the hypervisor. A secure solution
would have some form of authentication. This would enable greater flexibility  in the
positioning of NVEs.

Dimitri

For an external NVE, it’s necessary to trust the hypervisor to provide info on VM attach/detach, so the security concern is that this info come only from the hypervisor.  For VDP this starts with use of a link-local destination MAC - if a VM sends to this MAC, the virtual switch in the hypervisor is the recipient.  That virtual switch doesn’t forward the VDP frames, and probably just drops them. For an SR-IOV NIC in the server, the virtual switch in the NIC has to drop VDP frames sent by a VM so that VDP frames originate only from the hypervisor.  If an IP-based protocol is used for this function, authentication will be needed.  For an NVE in the hypervisor, the hypervisor configures its virtual switch directly and VDP does not run outside the hypervisor.

Thanks,
--David

Ying Jie,

Hi Linda,

”

   Virtual Access Point

   support this function.

Linda

---

From: [email-masked]
Date: Wed, 11 Jul 2012 11:39:58 +0800

Follow the comment,

I agree with that TES is not a trusted entity in nvo3. In my point of 
view, the trust model for nvo3 is a basis for dicussing security issues.

The following figure attempts to explicitly describe nov3 trust model in 
draft-wei-nvo3-security-framework.

                  +------------------------------------+
                  |              Trusted               |
                  |       +--------------------+       |
                  |       |+------------------+|       |
                  |       || Virtual Network 1||       |
                  |       |+------------------+|       |
    +----------+  | +-----++------------------++-----+ |
    |Tenant End|  | |     || Virtual Network 2||     | |  +----------+
    |  System  +----+ NV  |+------------------+|  NV | |  |Tenant End|
    +----------+  | |Edge |+------------------+| Edge+----+  System  |
                  | |     || Virtual Network 3||     | |  +----------+
     Untrusted    | +-----++------------------++-----+ |
                  |       | L3 Overlay Network |       |    Untrusted
                  |       |                    |       |
                  |       +--+---------------+-+       |
                  |          |    Overlay    |         |
                  |          | Boundary Point|         |
                  |          +-------+-------+         |
                  +------------------|-----------------+
                                     |
                          +----------+---------+
                          | Underlying Network |   Untrusted
                          +--------------------+

       Figure 1: Security Reference Model for Overlay based Network
                              Virtualization

-----------
Yinxing Wei

"Larry Kreeger (kreeger)" <[email-masked]> 
发件人:  [email-masked]
2012/07/11 11:06

收件人
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" <[email-masked]>
抄送

主题
Re: [nvo3] TES-NVE attach/detach protocol security (mobility-issues draft)

Trying to clarify the discussion below…using the terminology from 
draft-lasserre-nvo3-framework-03

A TES (tenant end system) is not a trusted entity and would not use VDP to 
communicate to an NVE.  It is an "End System" that would use VDP to 
communicate to an NVE, which would be a trusted device within the data 
center that is administered by the data center operator – NOT a tenant.

 - Larry

From: David Black <[email-masked]>
Date: Tuesday, July 10, 2012 9:27 AM
To: "[email-masked]" <[email-masked]>, "[email-masked]" <
[email-masked]>
Subject: Re: [nvo3] TES-NVE attach/detach protocol security 
(mobility-issues draft)

Linda,

IEEE802.1 Qbg’s VDP doesn’t do encapsulation, so it is different from 
NVo3’s NVE. VDP allows the hypervisor to notify the network of the 
virtual network  to which the new VMs belong. In that aspect, there is 
similarity to NVo3’s NVE. 
 
Right - VDP is a protocol that can be used between TES and NVE.  For a 
hypervisor, VDP would only be used on a link to an external NVE (e.g., in 
the ToR switch).  If the NVE is inside the hypervisor there’s no external 
TES-NVE protocol because both the TES and NVE are in the same physical 
server.

I agree, and VDP approaches this via use of a link-local destination MAC 
address for all VDP frames sent to the NVE.  If a VM sends a VDP frame, 
that frame is received by a virtual switch in the hypervisor, and so a 
simple solution is for virtual switches to drop and ignore all VDP frames 
sent by VMs.  An SR-IOV NIC would be configured to do likewise for VDP 
frames sent by VMs.  In both cases, this enables an external NVE in a ToR 
switch to rely on the VDP frames it receives having been originated by the 
hypervisor and not the VMs.

I agree, and any IP based TES-NVE protocol will be unable to rely on 
link-local destination MACs, hence I would expect authentication to be at 
least a “MUST implement” requirement if an IP-based protocol is used.
 
Thanks,
--David
 
From: Linda Dunbar [mailto:[email-masked]] 
Sent: Tuesday, July 10, 2012 11:49 AM
To: Black, David; [email-masked]
Subject: RE: TES-NVE attach/detach protocol security (mobility-issues 
draft)
 
David, 
 
IEEE802.1 Qbg’s VDP doesn’t do encapsulation, so it is different from 
NVo3’s NVE. VDP allows the hypervisor to notify the network of the 
virtual network  to which the new VMs belong. In that aspect, there is 
similarity to NVo3’s NVE. 
 
Hypervisor may be trusted, but  I don’t think DC operators can trust VMs. 
When VMs are instantiated with applications from random clients, whose 
applications can initiate attack to other clients network. It happened 
once in Amazon’s EC2. 
Security will be a big concern for any protocols from TES to NVE. 
 
Linda

Hi Linda,
 
[Linda]  In your IEEE802.1Qbg’s VDP example, the NVE would be the 
Hypervisor which sends Association/De-association messages to the edge 
bridge. I.e. the Hypervisor need to have north bound interface which is 
aware a VM is add or deleted. 
 
I don’t think so.  If the NVE is in the hypervisor, the external Ethernet 
switches (bridges) don’t see the inner MACs after encapsulation, hence 
VDP to the external Ethernet switch (bridge) is not useful because it sets 
up inner MACs that won’t occur in the outer headers beyond the hypervisor
’s NVE.  If the NVE is in the external Ethernet switch (bridge), VDP is 
useful because then it’s running between the TES and the NVE.
 
However, it is a security hole to let TES inform NVEs of being added or 
deleted, unless it is in a secure environment, or NVEs (or Hypervisors) 
can validate the information from TES via its management system. 

For an external NVE, it’s necessary to trust the hypervisor to provide 
info on VM attach/detach, so the security concern is that this info come 
only from the hypervisor. 

For VDP this starts with use of a link-local destination MAC - if a VM 
sends to this MAC, the virtual switch in the hypervisor is the recipient. 
That virtual switch doesn’t forward the VDP frames, and probably just 
drops them. For an SR-IOV NIC in the server, the virtual switch in the NIC 
has to drop VDP frames sent by a VM so that VDP frames originate only from 
the hypervisor.  If an IP-based protocol is used for this function, 
authentication will be needed.  For an NVE in the hypervisor, the 
hypervisor configures its virtual switch directly and VDP does not run 
outside the hypervisor. 
 
Thanks,
--David
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Linda Dunbar
Sent: Monday, July 09, 2012 3:28 PM
To: Guyingjie (Yingjie); [email-masked]
Subject: Re: [nvo3] Comments on draft-dunbar-nvo3-overlay-mobility-issues
 
Ying Jie, 

 
 
Hi Linda,
I read your draft on NVO3-mobility. 
I am okay with most of the content, just some secondary comments on your 
description of mechanism between NVE and TES. 
In my mind, external controller assistance is a bit more complicate to 
implement than using a protocol between NVEs and TES. 
A premise of my comments is that NVE is on external network devices, such 
as TOR and EOR, and TES are VMs in physical servers. 
 
4.1.1 First paragraph: “NVEs may
   not be aware of VMs being added or deleted unless NVEs have a north
   bound interface to a controller which can communicate with VM/server
   Manager(s).
”
This is not true. In VDP, with an Association/De-association message from 
Hypervisor to edge bridge(i.e. NVE in NVO3, and will use NVE instead of 
edge bridge in below), the bridge can be timely notified about the connect 
and disconnect to the bridge. That means it doesn’t need an northbound 
API for NVEs to be aware of VMs (dis)connection.  And also, VDP protocol 
can carry a field showing “This is a new created VM” or “This is a VM 
migrated from somewhere else”. That is VDP can fulfill the requirement of 
mobility notification, which can be a trigger for NVE to timely updating 
the states on itself, e.g. acquiring VNID associated with the VM 
moving/adding to the NVE, inner-outer address mapping, deleting states 
associated with the VM moving/deleting from this NVE. 
 
[Linda]  In your IEEE802.1Qbg’s VDP example, the NVE would be the 
Hypervisor which sends Association/De-association messages to the edge 
bridge. I.e. the Hypervisor need to have north bound interface which is 
aware a VM is add or deleted. 
 
I think that the sentence should have stated as “NVEs may not be aware of 
the VMs being added or deleted unless NVEs have a north bound interface to 
a controller which can communicate with VM/Server managers, or there is a 
protocol between TES and NVEs as defined by IEEE802.1Qbg. 
 
However, it is a security hole to let TES inform NVEs of being added or 
deleted, unless it is in a secure environment, or NVEs (or Hypervisors) 
can validate the information from TES via its management system. 

In the 4th paragraph of 4.1.1, If, for whatever reason, it is necessary to 
have local VID in the
   data frames before encapsulating outer header of EgressNVE-DA/
   IngressNVE-SA /VNID, NVE should get the specific local VID from the
   external Controller for those untagged data frames coming to each
   Virtual Access Point
For some reasons, I don’t think this part is good. 
First, there is other way to get the local VID except for external 
controller. In VDP, when NVE receives a (Pre)Association message from TES, 
it can acquire local VID from a Database which is managed by network 
administrator. 
[Linda] Yes, I should have added that NVE can also get local VID from TES 
as IEEE802.1Qbg defined. 

Secondly, while defining VDP, we consider of the situation you described, 
i.e. different local VID at different location. So the VDP can support 
different local VID under different NVE, by getting local VID from 
Database while receive the (Pre)Association message. And it can even 
feedback to the Hypervisor, so that the data frames from TES could have 
the local VID on it, but it’s also okay for NVE to add the local VID to 
data frames. 
 
[Linda] it is all good if TES can have those functions. But in many 
environment, TES don’t. This paragraph is emphasizing on the scenario 
when TES don’t support IEEE802.1Qbg. It is a good idea that you point out 
the functions of IEEE802.1Qbg. 

In the 6th paragraph in 4.1.1, The IEEE802.1Qbg's VDP protocol (Virtual 
Station Interface (VSI)
   discovery and configuration protocol) requires hypervisor to send VM
   profile upon a new VM is instantiated. However, not all hypervisors
   support this function.
The following is the VDP TLV definition from Qbg. Each VSI (Virtual 
Station Interface) usually is a VM interface id(could be MAC,IPV4/V6, 
UUID, etc). 
The NVE gets profile from Database by VSI type & instance information. I 
think your profile ID also means the combination of VSI type and instance 
information. So we are talking the same thing.   My point is it’s not 
profile, but the IDs to get profile, that is carried in VDP message. It 
might be confusing to people knowing nothing about VDP. Carrying profile 
in message is a huge overload.

 
External Controller can be very useful in NVO3, but not best suitable for 
each part of NVO3. I think we should think of other way for different 
problems. 

Linda 

Best Regards
Gu Yingjie
 _______________________________________________
nvo3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nvo3

[附件 "image001.png" 被 韦银星126577/user/zte_ltd 删除]

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Wed, 11 Jul 2012 03:47:52 +0000

From: "Luyuan Fang (lufang)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 10, 2012 8:27 PM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>, David Black <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [nvo3] TES-NVE attach/detach protocol security (mobility-issues draft)

A different point on l3, if it is L3 overlay tunnel starting at the end-system, I’d assume no VDP involvement.

LK> Yes, the idea of using VDP or a VDP-like protocol is to communicate between the end-system and and external NVE.  If the NVE is embedded in the end-system, then there is not need for an on-the-wire protocol.

Luyuan

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Larry Kreeger (kreeger)
Sent: Tuesday, July 10, 2012 11:07 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [nvo3] TES-NVE attach/detach protocol security (mobility-issues draft)

 - Larry

Linda,

Thanks,
--David

David,

Linda

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, July 10, 2012 8:17 AM
To: Linda Dunbar; [email-masked]<mailto:[email-masked]>
Subject: TES-NVE attach/detach protocol security (mobility-issues draft)

Hi Linda,

Thanks,
--David

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Monday, July 09, 2012 3:28 PM
To: Guyingjie (Yingjie); [email-masked]<mailto:[email-masked]>
Subject: Re: [nvo3] Comments on draft-dunbar-nvo3-overlay-mobility-issues

Ying Jie,

Hi Linda,

”

   Virtual Access Point

   support this function.

Linda

---

From: [email-masked]
Date: Wed, 11 Jul 2012 11:50:39 +0800

Hi, Luyuan

I agree with this text "If the end-system and NVE belongs to the same DC 
operator, then the end-system is in the trusted zone of the operator."
For a another case, for example, end-system and NVE belongs to the 
DIFFERENT DC operator, how can we define the trust zone?

-----------
Yinxing Wei

"Luyuan Fang (lufang)" <[email-masked]> 
发件人:  [email-masked]
2012/07/11 11:27

收件人
"Larry Kreeger (kreeger)" <[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" <[email-masked]>
抄送

主题

Agree with Larry. It is the end-system talking VDP with the NVE.  If the 
end-system and NVE belongs to the same DC operator, then the end-system is 
in the trusted zone of the operator.
 
A different point on l3, if it is L3 overlay tunnel starting at the 
end-system, I’d assume no VDP involvement.
 
Luyuan
 
Larry Kreeger (kreeger)

 
 - Larry

Linda,

 

 

Thanks,
--David

David, 

 
Linda

Hi Linda,

 

 
 
Thanks,
--David

Ying Jie, 

 
 
Hi Linda,

 

 

 

 
Linda 

Best Regards
Gu Yingjie

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Wed, 11 Jul 2012 03:52:31 +0000

Yinxing,

I would argue that inside of a data center the underlying network is also trusted.

 - Larry

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 10, 2012 8:39 PM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>
Cc: David Black <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Re: [nvo3] TES-NVE attach/detach protocol security (mobility-issues draft)

Follow the comment,

I agree with that TES is not a trusted entity in nvo3. In my point of view, the trust model for nvo3 is a basis for dicussing security issues.

The following figure attempts to explicitly describe nov3 trust model in draft-wei-nvo3-security-framework.

-----------
Yinxing Wei

"Larry Kreeger (kreeger)" <[email-masked]<mailto:[email-masked]>>
发件人:  [email-masked]<mailto:[email-masked]>

2012/07/11 11:06

收件人
        "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
抄送

主题

 - Larry

Linda,

Thanks,
--David

David,

Linda

Hi Linda,

Thanks,
--David

Ying Jie,

Hi Linda,

”

Linda

Best Regards
Gu Yingjie
 _______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3

[附件 "image001.png" 被韦银星126577/user/zte_ltd 删除]

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 11 Jul 2012 03:52:55 +0000

If the L3 NVE function is implemented at other devices (e.g., ToR switches) than end systems, what protocol is available for us to notify the VM attach/detach events to the L3 NVE? ARP, XMPP or still VDP?

Best regards,
Xiaohu

发件人: [email-masked] [mailto:[email-masked]] 代表 Luyuan Fang (lufang)
发送时间: 2012年7月11日 11:28
收件人: Larry Kreeger (kreeger); [email-masked]; Linda Dunbar; [email-masked]
主题: Re: [nvo3] TES-NVE attach/detach protocol security (mobility-issues draft)

Luyuan

 - Larry

Linda,

Thanks,
--David

David,

Linda

Hi Linda,

Thanks,
--David

Ying Jie,

Hi Linda,

”

   Virtual Access Point

   support this function.

Linda

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Wed, 11 Jul 2012 04:07:11 +0000

My understanding VDP is a discovery protocol for bridging…
If you are using pure l3 end-system to end-system, there is no bridging, there is no need for VDP.
But if your l3 only starts at ToR, VDP can be used between ToR to end-system.

Luyuan

From: Xuxiaohu [mailto:[email-masked]]
Sent: Tuesday, July 10, 2012 11:53 PM
To: Luyuan Fang (lufang); Larry Kreeger (kreeger); [email-masked]; Linda Dunbar; [email-masked]
Subject: re: [nvo3] TES-NVE attach/detach protocol security (mobility-issues draft)

Best regards,
Xiaohu

Luyuan

 - Larry

Linda,

Thanks,
--David

David,

Linda

Hi Linda,

Thanks,
--David

Ying Jie,

Hi Linda,

”

   Virtual Access Point

   support this function.

Linda

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Wed, 11 Jul 2012 04:22:12 +0000

I would define anything under the operator’s control are in the trusted zone of that operator, including the DC underlay infra as Larry pointed out, if it belongs to the same DC operator.
If the end-system and the NVE belong to different operators, then they would treat each other as un-trusted. It does not mean they cannot work with each other, but some security mitigation, e.g. authentication should be considered.
Luyuan

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 10, 2012 11:51 PM
To: Luyuan Fang (lufang)
Cc: [email-masked]; Larry Kreeger (kreeger); [email-masked]; [email-masked]; [email-masked]
Subject: Re: Re: [nvo3] TES-NVE attach/detach protocol security (mobility-issues draft)

Hi, Luyuan

I agree with this text "If the end-system and NVE belongs to the same DC operator, then the end-system is in the trusted zone of the operator."
For a another case, for example, end-system and NVE belongs to the DIFFERENT DC operator, how can we define the trust zone?

-----------
Yinxing Wei

2012/07/11 11:27

收件人

"Larry Kreeger (kreeger)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

抄送

主题

Luyuan

 - Larry

Linda,

Thanks,
--David

David,

Linda

Hi Linda,

Thanks,
--David

Ying Jie,

Hi Linda,

”

Linda

Best Regards
Gu Yingjie

---

From: Melinda Shore <[email-masked]>
Date: Tue, 10 Jul 2012 20:29:35 -0800

> I would argue that inside of a data center the underlying network is

I don't know what "underlying network" means in this context - do
you mean that the outer headers on the VPN are "trusted" but the inner
headers are not?

I'd also think pretty hard about what it means to be "trusted" -
do you think that security mechanisms aren't required at the layer
you've decided to trust?

Melinda

---

From: [email-masked]
Date: Wed, 11 Jul 2012 13:00:02 +0800

I am fine, thanks!
It may be necessary to further identify some possible security threats.

-----------
Yinxing Wei

2012/07/11 12:22

收件人
"[email-masked]" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>, "Larry Kreeger \(kreeger\)" <[email-masked]>, 
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
Re: [nvo3] TES-NVE attach/detach protocol security (mobility-issues draft)

I would define anything under the operator’s control are in the trusted 
zone of that operator, including the DC underlay infra as Larry pointed 
out, if it belongs to the same DC operator.
If the end-system and the NVE belong to different operators, then they 
would treat each other as un-trusted. It does not mean they cannot work 
with each other, but some security mitigation, e.g. authentication should 
be considered.
Luyuan
 
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, July 10, 2012 11:51 PM
To: Luyuan Fang (lufang)
Cc: [email-masked]; Larry Kreeger (kreeger); [email-masked]; 
[email-masked]; [email-masked]
Subject: Re: Re: [nvo3] TES-NVE attach/detach protocol security 
(mobility-issues draft)

Hi, Luyuan 

----------- 
Yinxing Wei 

收件人

主题

  
  
Luyuan 

  
  
 - Larry 

Linda, 

  

  

  
Thanks,
--David 

David, 

Linda 

Hi Linda, 

  

  

Thanks,
--David 

Ying Jie, 

  

Hi Linda, 

” 

  

  

  

  
Linda 

Best Regards
Gu Yingjie

---

From: [email-masked]
Date: Wed, 11 Jul 2012 15:00:41 +0800

Hi, Larry

There may exist different cases: 
Case 1: Virtual network and underlying infrastructure belong to the same 
DC operator, 
        In this case, the underlying infra can be trusted
Case 2: Virtual network and underlying infrastructure belong to different 
DC operators,
        In this case, different operator may have different security 
policies. So the underlying infra
        can be considered as Untrusted.

Case (1) is missing in the my current draft, I will update it next time.

-----------
Yinxing Wei

2012/07/11 11:52

收件人
"[email-masked]" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" <[email-masked]>, 
"[email-masked]" <[email-masked]>
主题
Re: [nvo3] TES-NVE attach/detach protocol security (mobility-issues draft)

Yinxing,

I would argue that inside of a data center the underlying network is also 
trusted.

 - Larry

From: "[email-masked]" <[email-masked]>
Date: Tuesday, July 10, 2012 8:39 PM
To: Cisco Employee <[email-masked]>
Cc: David Black <[email-masked]>, "[email-masked]" <
[email-masked]>, "[email-masked]" <[email-masked]>, "
[email-masked]" <[email-masked]>
Subject: Re: Re: [nvo3] TES-NVE attach/detach protocol security 
(mobility-issues draft)

Follow the comment, 

----------- 
Yinxing Wei 

收件人
"[email-masked]" <[email-masked]>, "[email-masked]" <
[email-masked]>, "[email-masked]" <[email-masked]>
抄送

主题

 - Larry 

Linda, 

  

  

  
Thanks,
--David 

David, 

Linda 

Hi Linda, 

  

  

Thanks,
--David 

Ying Jie, 

  

Hi Linda, 

” 

  

  

  

  
Linda 

Best Regards
Gu Yingjie

---

From: [email-masked]
Date: Wed, 11 Jul 2012 15:31:03 +0800

Hi, Melinda
 
  If the underlying network is trusted, it is believed that it will do no 
harm to 
the other components in the same trust zone. 
  If it is untrusted, it may endanger other components in the different 
trust zone.
We should consider potential security risks in the untrusted case. 

 "trusted" can be established by phsical security or some other security 
mechanisms, e.g. IPsec VPN.

-----------
Yinxing Wei

Melinda Shore <[email-masked]> 
发件人:  [email-masked]
2012/07/11 12:29

收件人
[email-masked]
抄送

主题

Melinda

---

From: Thomas Narten <[email-masked]>
Date: Wed, 11 Jul 2012 09:54:51 -0400

> My understanding VDP is a discovery protocol for bridging…

Note: VDP stands for VSI Discovery and Configuration Protocol (though
the "configuration" part is often dropped).

It does more than just "discover". E.g., see
http://blog.ioshints.info/2011/05/edge-virtual-bridging-evb-8021qbg-eases.html

> One of the most interesting parts of EVB is the VSI Discovery and
> Configuration Protocol (VDP). Using VDP, the EVB station (host) can
> inform the adjacent EVB Bridge (access switch) before a VM is deployed
> (started or moved). The host can also tell the switch which VLAN the
> VM needs and which MAC address (or set of MAC addresses) the VM
> uses. Blasting through the VLAN limits (4K VLANs allowed by 802.1Q),
> the VDP supports 4-byte long Group ID, which can be mapped dynamically
> into different access VLANs on as-needed basis (this is a recent
> addendum to 802.1Qbg and probably allows nice interworking with I-SID
> field in PBB/SPB).

Also, see draft-gu-nvo3-overlay-cp-arch-00.txt  and
draft-gu-nvo3-tes-nve-mechanism-00.txt which has text on VDP.

If anyone can point the WG to a good overview/summary of what VDP
does, that would be helpful.

> bridging, there is no need for VDP.

I'm not sure about that.

When you say L3 TES, what is the interface between the NVE and TES? My
assumption is that it is still L2, even if the service provided is
L3. You'd ignore the L2 stuff (mostly), but most VMs are already set
up to send L2 packets on their interfaces. 

Also VDP is between the Hypervisor and NVE. Thus, it may still be
needed, even if the service provided to the TES is L3 only.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Wed, 11 Jul 2012 09:58:51 -0400

[email-masked] writes:

> Case 1: Virtual network and underlying infrastructure belong to the
>         same DC operator, In this case, the underlying infra can be
>         trusted

Can you clarify a bit? When you say "virtual network", isn't that the
tenant network, which by definition is separate from the DC operator
network? I would assume that the VN and underlying infrastructure
never trust each other.

> Case 2: Virtual network and underlying infrastructure belong to
>         different DC operators, In this case, different operator may
>         have different security policies. So the underlying infra can
>         be considered as Untrusted.

I would assuem this is the case we care about.

Thomas

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Wed, 11 Jul 2012 14:21:43 +0000

I’d be happy to team up for the work.
I worked 3 security framework docs in different areas, RFC 4111 - security framework for ppvpn may be a closer one to this (comparing to RFC 5920), though nvo3’s security related scope is wider,  potentially more security threats and defensive techniques need to be addressed in this area.
Luyuan

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, July 11, 2012 1:00 AM
To: Luyuan Fang (lufang)
Cc: [email-masked]; Larry Kreeger (kreeger); [email-masked]; [email-masked]; [email-masked]
Subject: Re: Re: [nvo3] TES-NVE attach/detach protocol security (mobility-issues draft)

I am fine, thanks!

-----------
Yinxing Wei

2012/07/11 12:22

收件人

抄送

"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Larry Kreeger \(kreeger\)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

主题

Hi, Luyuan

-----------
Yinxing Wei

2012/07/11 11:27

收件人

抄送

主题

Luyuan

- Larry

Linda,

Thanks,
--David

David,

Linda

Hi Linda,

Thanks,
--David

Ying Jie,

Hi Linda,

”

Linda

Best Regards
Gu Yingjie
_______________________________________________
nvo3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nvo3_______________________________________________
nvo3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nvo3

---

From: Lucy yong <[email-masked]>
Date: Wed, 11 Jul 2012 15:00:01 +0000

Here is my 2 cents for the L3VN case.

If an NVE is on a server and TESs are VMs on the server, TES-NVE attach/detach is configured by DC operators. When VM is power-on, the NVE populates it in the forwarding table; When VM is power-off, the NVE removes it from the table. The forwarding between the NVE and TESs is simply an internal table lookup and delivery process on the server. If an NVE is on ToR, TESs may be either non-virtualized servers or a vSwitch on virtualized servers; the routing between NVE and TESs may use Petro's proposal or run a routing protocol such as OSPF per a VN; The forwarding between two is like [RFC4364].

Lucy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Narten
Sent: Wednesday, July 11, 2012 8:55 AM
To: Luyuan Fang (lufang)
Cc: [email-masked]
Subject: Re: [nvo3] TES-NVE attach/detach protocol security (mobility-issues draft)

"Luyuan Fang (lufang)" <[email-masked]> writes:

> My understanding VDP is a discovery protocol for bridging鈥?

Note: VDP stands for VSI Discovery and Configuration Protocol (though the "configuration" part is often dropped).

It does more than just "discover". E.g., see http://blog.ioshints.info/2011/05/edge-virtual-bridging-evb-8021qbg-eases.html

> VM needs and which MAC address (or set of MAC addresses) the VM uses. 
> Blasting through the VLAN limits (4K VLANs allowed by 802.1Q), the VDP 
> supports 4-byte long Group ID, which can be mapped dynamically into 
> different access VLANs on as-needed basis (this is a recent addendum 
> to 802.1Qbg and probably allows nice interworking with I-SID field in 
> PBB/SPB).

Also, see draft-gu-nvo3-overlay-cp-arch-00.txt  and draft-gu-nvo3-tes-nve-mechanism-00.txt which has text on VDP.

If anyone can point the WG to a good overview/summary of what VDP does, that would be helpful.

I'm not sure about that.

When you say L3 TES, what is the interface between the NVE and TES? My assumption is that it is still L2, even if the service provided is L3. You'd ignore the L2 stuff (mostly), but most VMs are already set up to send L2 packets on their interfaces. 

Also VDP is between the Hypervisor and NVE. Thus, it may still be needed, even if the service provided to the TES is L3 only.

Thomas

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Wed, 11 Jul 2012 15:11:09 +0000

I just realized that I quoted the wrong term from the framework draft.  Where I said "End System" I really meant "End Device ".

 - Larry

----- Reply message -----
From: "Larry Kreeger (kreeger)" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [nvo3] TES-NVE attach/detach protocol security (mobility-issues draft)
Date: Tue, Jul 10, 2012 8:07 pm

 - Larry

Linda,

Thanks,
--David

David,

Linda

Hi Linda,

Thanks,
--David

Ying Jie,

Hi Linda,

”

   Virtual Access Point

   support this function.

Linda

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Wed, 11 Jul 2012 15:51:38 +0000

Lucy,
Thanks for the notes, that is more or less the way I see it too. 

Thomas,
Also look Larry's reply yesterday: "the idea of using VDP or a VDP-like protocol is to communicate between the end-system and and external NVE.  If the NVE is embedded in the end-system, then there is not need for an on-the-wire protocol."
I believe Larry is right.

Luyuan

> From: Lucy yong [mailto:[email-masked]]
> Sent: Wednesday, July 11, 2012 11:00 AM
> To: Thomas Narten; Luyuan Fang (lufang)
> Cc: [email-masked]
> If an NVE is on a server and TESs are VMs on the server, TES-NVE
> attach/detach is configured by DC operators. When VM is power-on, the
> NVE populates it in the forwarding table; When VM is power-off, the NVE
> removes it from the table. The forwarding between the NVE and TESs is
> simply an internal table lookup and delivery process on the server. If
> an NVE is on ToR, TESs may be either non-virtualized servers or a
> vSwitch on virtualized servers; the routing between NVE and TESs may
> use Petro's proposal or run a routing protocol such as OSPF per a VN;
> The forwarding between two is like [RFC4364].
> 
> Lucy
> 
> Thomas Narten
> Also, see draft-gu-nvo3-overlay-cp-arch-00.txt  and draft-gu-nvo3-tes-
> nve-mechanism-00.txt which has text on VDP.
> 
> assumption is that it is still L2, even if the service provided is L3.
> You'd ignore the L2 stuff (mostly), but most VMs are already set up to
> send L2 packets on their interfaces.
>

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Wed, 11 Jul 2012 16:20:47 +0000

> needed, even if the service provided to the TES is L3 only.

In a layer 3 solution (whether encapsulation starts at the hypervisor or on a switch outside of the hypervisor) there is no need to run a complicated (IEEE) protocol such as VDP. VDP was invented to interoperate a virtual server with an external layer 2 switch/bridge. 
A layer 3 solution can use much simpler IP-based protocol (developed in IETF) such as Extensible Messaging and Presence Protocol (XMPP).

Maria

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Wed, 11 Jul 2012 16:35:48 +0000

Hi Thomas,

I can see where the phrase "Virtual network and underlying infrastructure"
can be interpreted differently.  It would be good for Yinxing to clarify.
My interpretation was that he meant "The NVEs and underlying
infrastructure".

Certainly the traffic within a given virtual network is tenant traffic and
should not be trusted and must be isolated from the underlying network,
but the implementation/administration of a virtual network is done by data
center administrators (not the tenants).

 - Larry

---

From: Lucy yong <[email-masked]>
Date: Wed, 11 Jul 2012 16:35:44 +0000

Tom,

I am a bit confused in your comments. DC operators own and manage both Server devices and networks devices. When they construct a VN by using their devices for a tenant, why a VN and underlying network has to be considered as Untrusted? What do I miss here?

>From the tenant perspective, they just run the applications on the VN and do not aware of underlying network existence, the trust/untrust does not exist between the tenant and underlying network. IMO: the nvo3 work is to make the VN be trusted by a tenant.

Regards,
Lucy  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Narten
Sent: Wednesday, July 11, 2012 8:59 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [nvo3] TES-NVE attach/detach protocol security (mobility-issues draft)

Thomas

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Wed, 11 Jul 2012 16:51:36 +0000

Hi Melinda,

What I mean is that within the walls of a data center, there is an
assumption of physical security of the devices connected to the network
and knowledge of the security of the administration of the devices.

For example, I assume that the switches/routers providing the underlying
network are owned/secured/administrated by the trusted data center
administrators who also control what ports on those devices connect to
their own trusted devices vs tenant devices which would be considered to
not be trusted.

Based on that, I suppose you could extrapolate to say that the outer
headers sent across the underlying network are trusted since the data
center administrator can control what devices connect to the underlying
network.

 - Larry

---

From: Melinda Shore <[email-masked]>
Date: Wed, 11 Jul 2012 09:13:40 -0800

> their own trusted devices vs tenant devices which would be considered to

I think that's a critical distinction when thinking about how
to secure this mechanism.

> center administrator can control what devices connect to the underlying

This is pretty far outside my comfort zone but it seems to be a
common assumption in actual deployments, so let me ask this:  Do you
want to put that particular constraint (that it always be deployed
in "trusted" environments) on the protocol?  My feeling is that
since the concept of a "trusted data center network" and a "trusted
data center administrator" are, in general (there are exceptions),
pretty bogus, that's an unrealistic constraint, and because it can
be anticipated that there will be some number of deployments that
ignore that constraint anyway, nvo3 needs to be somewhat more
responsible about security than "it's all on a trusted network,
anyway" would suggest.

Melinda

---

From: Paul Unbehagen <[email-masked]>
Date: Wed, 11 Jul 2012 11:17:55 -0600

VDP isn't that complicated of a protocol.  It was designed to autoconnect VMs to the proper VLAN and any tenant profile required by involving communication to a management system which then configures the proper tenant parameters in the ToR/EoR in a automated way.  This is all transparent to the routing layer as the IP and default gateway and vlan assignment take care of all that automatically. 

I believe it's already in a few server vendors products already as I saw prototypes of it a couple years ago. 

--
Paul Unbehagen

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Wed, 11 Jul 2012 17:28:21 +0000

Thomas, Larry, Lucy, Maria, and Paul, 

Thanks for the discussion, and sharing the insight...

I'd like to get us on the same page on when VDP is needed and when it is not, please help if the following points are not correct?

1) If NVE and TES are in the same physical device - there is no external wire between them, then no VDP or VDP-like protocol is needed, regardless L2 or L3 is used.
2) If NVE and TES are not in the same physical device, but TES to NVE using L3 protocols only, there is still no need for VDP or VDP-alike protocol.
3) If NVE and TES are not in the same physical device, TES to NVE using L2, then VDP or VDP-like protocol plays important role for discovery and more.

Thanks,
Luyuan

> From: Paul Unbehagen [mailto:[email-masked]]
> Sent: Wednesday, July 11, 2012 1:18 PM
> To: NAPIERALA, MARIA H
> Cc: Thomas Narten; Luyuan Fang (lufang); [email-masked]
> VDP isn't that complicated of a protocol.  It was designed to
> autoconnect VMs to the proper VLAN and any tenant profile required by
> involving communication to a management system which then configures
> the proper tenant parameters in the ToR/EoR in a automated way.  This
> is all transparent to the routing layer as the IP and default gateway
> and vlan assignment take care of all that automatically.
> 
> > In a layer 3 solution (whether encapsulation starts at the hypervisor
> or on a switch outside of the hypervisor) there is no need to run a
> complicated (IEEE) protocol such as VDP. VDP was invented to
> interoperate a virtual server with an external layer 2 switch/bridge.
> > A layer 3 solution can use much simpler IP-based protocol (developed
> in IETF) such as Extensible Messaging and Presence Protocol (XMPP).
> >
> > Maria

---

From: Thomas Narten <[email-masked]>
Date: Wed, 11 Jul 2012 13:42:30 -0400

Hi Luyuan.

> I'd like to get us on the same page on when VDP is needed and when
>  it is not, please help if the following points are not correct?

Let me try, based on my understanding of things...

> 1) If NVE and TES are in the same physical device - there is no
>  external wire between them, then no VDP or VDP-like protocol is
>  needed, regardless L2 or L3 is used.

Agreed. This can all be done internal to the device.
  
> 2) If NVE and TES are not in the same physical device, but TES to
> NVE using L3 protocols only, there is still no need for VDP or
> VDP-alike protocol.

Not sure I agree with this.

More to the point, in a DC, when will an NVE and TES be separated by a
physical network link that is *only* running L3? Even if L3 is being
used, it will surely also be running over L2, which I assume (in a DC
environment) will be ethernet. Or is this assumption wrong?

Thus, VDP can also be used here. Or at least, I'd like to understand
why it wouldn't be appropriate and why a different (and new) L3
protocol is needed.

To be clear, I'm not wedded to using VDP (or any specific
protocol). We need to figure out requirements and then do a gap
analysis, so it's premature to be trying to be picking solutions here.

But, my assumption is:

1) VDP exists and is already being implemented.  We do of course need
to have the conversation about whether its implemented widely enough,
etc.

2) Assuming VDP already exists, and we can add the needed NVO3
functionality to it (i.e., by defining the needed TLVs), isn't that
preferred over inventing a new protocol, no matter how "simple" that
new protocol would be?

> 3) If NVE and TES are not in the same physical device, TES to NVE
> using L2, then VDP or VDP-like protocol plays important role for
> discovery and more.

Same arguments as above.

Thomas

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Wed, 11 Jul 2012 17:43:12 +0000

My main point was that VDP is not needed in a layer 3 solution since MACs and VLANs are irrelevant to layer 3.
Dealing with a protocol which was defined for interoperability with bridging would be unnecessary complication to a layer 3 solution.

Maria

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Wed, 11 Jul 2012 18:05:39 +0000

On 7/11/12 10:28 AM, "Luyuan Fang (lufang)" <[email-masked]> wrote:

>I'd like to get us on the same page on when VDP is needed and when it is
>not, please help if the following points are not correct?
>
>1) If NVE and TES are in the same physical device - there is no external
>wire between them, then no VDP or VDP-like protocol is needed, regardless
>L2 or L3 is used.

Agreed.

>2) If NVE and TES are not in the same physical device, but TES to NVE
>using L3 protocols only, there is still no need for VDP or VDP-alike
>protocol.

I don't agree with that one.  But first, let's clarify that I'm assuming
that there is an additional component in between the TES and the NVE
(which I believe is called End Device in the framework doc).  Here is a
picture to illustrate:

       Hypervisor            Access Router/Switch
   +-------------------+       +-----+-------+
   | +---+   +-------+ |       |     |       |
   | |TES|---|       | | VLAN  |     |       |
   | +---+   |Virtual|---------+ NVE |       +--- Underlying
   | +---+   |Switch | | Trunk |     |       |    Network
   | |TES|---|       | |       |     |       |
   | +---+   +-------+ |       |     |       |
   +-------------------+       +-----+-------+

I'm assuming VDP happens between trusted devices, so in this picture the
hypervisor virtual switch is a trusted End Device.  It would run the
VDP-like protocol.  In this case, there is still a need to inform the NVE
of the need to participate in a given L3 VN and possibly to be informed of
the TES IP addresses within that VN.

>3) If NVE and TES are not in the same physical device, TES to NVE using
>L2, then VDP or VDP-like protocol plays important role for discovery and
>more.

I'm not sure why you differentiate the cases of L2 and L3.  The tenant VN
traffic on the wire between the Hypervisor and the Access switch/router
needs to be differentiated (since TESs from different tenants could be
present on the same hypervisor), so some kind of tag (like a locally
significant VLAN tag) needs to be negotiated with the NVE across that
wire, and the NVE still needs to know what TES addresses are
attaching/detaching from what VN regardless of the address family used for
forwarding across the VN.

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Wed, 11 Jul 2012 19:41:43 +0000

Luyuan,

I saw that Thomas and Larry responded. Let me do it separately, so we don't get confused.

> external wire between them, then no VDP or VDP-like protocol is needed,
> regardless L2 or L3 is used.

Yes.

> using L3 protocols only, there is still no need for VDP or VDP-alike

We need a protocol here also since the VPN endpoint membership information must be communicated to NVE by the end-system (TES). The end-system L3VPN proposal uses XMPP for that purpose (as well as for communication with the VPN controller/signaling gateway).

> L2, then VDP or VDP-like protocol plays important role for discovery
> and more.
> 
> Thanks,
> Luyuan
> 
> (mobility-
> > issues draft)

---

From: Lucy yong <[email-masked]>
Date: Wed, 11 Jul 2012 22:00:27 +0000

Larry,

Please see inline.

Snipped ..

[[LY]] In this case, should we request vswitch to be a vrouter? i.e. forward based on IP? We can still use vlans to segregate the VN traffic on the wire. Then it would be similar to VRF-Lite.

[[LY]] If we do not differentiate the cases of L2 and L3, L3VN is not a end-to-end L3VN.
I don't think the framework catch this scenario. When TES and NVE are physically separated, the current framework assumes that TES is non-virtualized server. This case makes non end-to-end overlay for both L2 and L3 cases. 

Thanks to depict this case clearly.

Lucy

---

From: <[email-masked]>
Date: Wed, 11 Jul 2012 19:29:29 -0400

Thomas,

> environment) will be ethernet. Or is this assumption wrong?

It's a good assumption - the next two questions are:
	- How many Ethernet links are traversed?
	- Is there any IP forwarding involved?
If the answer to the questions are "1" and "no" respectively, a single
Ethernet link is involved, and L2 access control looks like a reasonable
approach for an L2 protocol such as VDP.

If either question has a different answer, an L2 protocol like VDP gets
more interesting, as pointed out in a thread between Dimitri and I yesterday.
In particular:
	- If multiple Ethernet links are involved, VDP has to somehow
		be plumbed through the L2 bridges that connect the links.
	- If there's an IP forwarding node between the End Device and
		the NVE, VDP needs to be relayed through that node (this
		has some analogies to the function of a DHCP relay).
Both of these result in a larger L2 scope for VDP and hence more things
that have to be checked to ensure that the access control is correct.  

An IP-based protocol avoids these L2 complications, but it also cannot rely
on L2 topology for access control purposes.

Thanks,
--David

> Sent: Wednesday, July 11, 2012 1:43 PM
> To: Luyuan Fang (lufang)
> Cc: Paul Unbehagen; [email-masked]; Larry Kreeger (kreeger); Lucy yong;
> NAPIERALA, MARIA H

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Thu, 12 Jul 2012 00:46:54 +0000

>		be plumbed through the L2 bridges that connect the links.

Or, the device in between can act as a relay.  I runs the VDP-like
protocol with the End Device to negotiate a local .1Q tag for a VN on that
local link, then act as an End Device to the NVE on the other link to
negotiate a separate local .1Q tag.  It would then translate tags as the
traffic flows across the device at L2.

I'm guessing this might not be what you had in mind.  Are you assuming the
intermediate device(s) between the End Device and NVE are unmodified, off
the shelf 802.1Q bridges that are not participating in any protocols?  If
so...assuming the method to keep each VN's traffic separated as it flows
across this bridge is 802.1Q VLANs (global to the device), then this will
limit how many VNs can be accessed on the NVE to how many VLANs can be
trunked on all the ports of this bridge simultaneously.  Since this bridge
is not running any protocols with the End Device or NVE,  the admin would
have to statically configure as many VLANs as supported on all the trunk
ports which lead to all the End Systems and to the NVE.  Assuming this
device cannot support 4K VLANs on all its ports, this means the NVE must
be configured to negotiate only the limited VLAN range, and all the End
Devices must share this limited VLAN space for all of their VNs.

>		has some analogies to the function of a DHCP relay).

I'm wondering how two tenant's traffic is kept separated while they
traverse this IP forwarding node that lies between the End Device and the
NVE.  It seems like it would require some kind of tunnel, with the End
Device required to encapsulate/decapsulate the TES traffic into and out of
the tunnel.  This seems to diminish the utility of offloading the VN
encap/decap to the NVE and only serves to make life more complicated, with
little benefit.  Am I missing something?

>> Narten
>>(mobility-issues

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 12 Jul 2012 02:10:35 +0000

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Larry
> Kreeger (kreeger)
> 发送时间: 2012年7月12日 2:06
> 收件人: Luyuan Fang (lufang); Paul Unbehagen; NAPIERALA, MARIA H
> 抄送: Thomas Narten; [email-masked]; Lucy yong

Hi Larry,

I agree with you and Thomas that some kind of signaling (e.g., VDP) for VM attachment/de-attachment events between End Device and NVE is needed in this case, no matter L2 or L3 NVE is involved. 

As an alternative, in the case where the VM profile (e.g., VLAN ID, ACL etc.,) has already been auto-configured on the NVE via the orchestration system, is it possible to allow the TES itself to notify its attachments explicitly and its de-attachments implicitly to the NVE by using some existing protocol, e.g., ARP? For example, when a VM is attached to a given NVE, the VM or its hypervisor on behalf of it could send a gratuitous ARP packet to notify the NVE of its attachment. When a VM is moved from a old NVE to a new NVE, when the event of VM attachment to the new NVE arrives at the old NVE (e.g., via the propagation of the gratuitous ARP, or via the advertisement of the MAC or IP address of the VM), the old NVE would either update its forwarding table entry of that VM directly (imagine the traditional VPLS's behavior) or after it has confirmed that the VM is no longer attached to it (imagine the case where the MAC or IP reachability information of remote VMs is learnt on the control plane).

Best regards,
Xiaohu

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Thu, 12 Jul 2012 03:03:18 +0000

> From: Larry Kreeger (kreeger) [mailto:[email-masked]]
> Sent: Wednesday, July 11, 2012 2:06 PM
> To: Luyuan Fang (lufang); Paul Unbehagen; NAPIERALA, MARIA H
> Cc: Thomas Narten; [email-masked]; Lucy yong

<snip>

> using
> and
> wire, 

Correct. In the "end-system L3VPN" proposal the virtual interface within a given end-system is identified by the combination of the physical interface MAC address and 802.1Q tag. This tag is unique only within the end-system. The first-hop router (NVE) responds to all ARP requests from the end-system and performs IP lookup on every packet. MAC address of the guest OS is not on the wire.

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 12 Jul 2012 03:25:06 +0000

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表
> NAPIERALA, MARIA H
> 发送时间: 2012年7月12日 11:03
> 收件人: Larry Kreeger (kreeger); Luyuan Fang (lufang); Paul Unbehagen
> Correct. In the "end-system L3VPN" proposal the virtual interface within a
> given end-system is identified by the combination of the physical interface MAC
> address and 802.1Q tag. This tag is unique only within the end-system. The
> first-hop router (NVE) responds to all ARP requests from the end-system and
> performs IP lookup on every packet. MAC address of the guest OS is not on the
> wire.

Hi Maria,

I guess the current "end-system L3VPN" proposal should belong to case 1, rather than case 3 where NVE and TES are not in the same physical device, unless the "end-system L3VPN" makes some changes as follows: XMPP is only used as a signaling of VM attachment/detachment events between hypervisors and ToRs, rather than as a replacement of BGP-based L3VPN signaling. In this way, the NVE functionality (i.e., L3VPN PE) is performed on the ToRs, rather than on the end-systems.

Best regards,
Xiaohu

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Thu, 12 Jul 2012 03:38:51 +0000

Xiaohu,

> I guess the current "end-system L3VPN" proposal should belong to case
> 1, rather than case 3 where NVE and TES are not in the same physical
> device, unless the "end-system L3VPN" makes some changes as follows:
> XMPP is only used as a signaling of VM attachment/detachment events
> between hypervisors and ToRs, rather than as a replacement of BGP-based
> L3VPN signaling. In this way, the NVE functionality (i.e., L3VPN PE) is
> performed on the ToRs, rather than on the end-systems.

Actually, "end-system L3VPN" proposal covers both cases. In the case NVE functionality is on external switch, it operates as an XMPP server processing requests from end-systems and as a client of one or more controllers/signaling gateways.  It relays to the signaling gateways(s) messages it receives from the end-system.  In this scenario, the VPN routing information the NVE receives from a signaling gateway is not propagated to the end-system.

Maria

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 12 Jul 2012 04:11:01 +0000

Hi Maria,

If I remembered correctly, "end-system L3VPN" proposed that end-system (i.e., physical server) act as PE routers (i.e., NVE) and use XMPP instead of BGP as a L3VPN signaling with XMPP signaling gateways. Of course, I haven't check whether the recent "end-system L3VPN" reversions have made changes as I mentioned before.

In fact, there has been a L3VPN+host route based DCVPN proposal referred to as Virtual Subnet (http://tools.ietf.org/html/draft-xu-virtual-subnet-08) (proposed two year earlier) which covers the scenario where the L3NVE and TES are located at different physical devices. 

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: NAPIERALA, MARIA H [mailto:[email-masked]]
> 发送时间: 2012年7月12日 11:39
> 收件人: Xuxiaohu; Larry Kreeger (kreeger); Luyuan Fang (lufang); Paul
> Unbehagen
> 主题: RE: [nvo3] TES-NVE attach/detach protocol security (mobility-issues
> draft)
> 
> Xiaohu,
> 
> Actually, "end-system L3VPN" proposal covers both cases. In the case NVE
> functionality is on external switch, it operates as an XMPP server processing
> requests from end-systems and as a client of one or more controllers/signaling
> gateways.  It relays to the signaling gateways(s) messages it receives from
> the end-system.  In this scenario, the VPN routing information the NVE
> receives from a signaling gateway is not propagated to the end-system.
> 
> 
> Maria

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Thu, 12 Jul 2012 04:18:07 +0000

> If I remembered correctly, "end-system L3VPN" proposed that end-system
> (i.e., physical server) act as PE routers (i.e., NVE) and use XMPP
> instead of BGP as a L3VPN signaling with XMPP signaling gateways. Of
> course, I haven't check whether the recent "end-system L3VPN"
> reversions have made changes as I mentioned before.

It has. Check -05 version.
 
> In fact, there has been a L3VPN+host route based DCVPN proposal
> referred to as Virtual Subnet (http://tools.ietf.org/html/draft-xu-
> virtual-subnet-08) (proposed two year earlier) which covers the
> scenario where the L3NVE and TES are located at different physical
> devices.

OK. I'll take a look. 

Maria

---

From: "Guyingjie (Yingjie)" <[email-masked]>
Date: Thu, 12 Jul 2012 07:01:21 +0000

The MACs and VLANs fields in VDP tlv can be null if they are not necessary to be transferred from End device to NVE. The VSI ID information can be used to find out which VN the VM belongs to. From this point of view, I don't think that we need a new protocol for L3. 

To support VN attach/detach on L3VPN discussed in the thread, IMHO, it's easy to find suitable information or easily add new to /delete unnecessary field from VDP. 

But there is still something to consider while using VDP in L3VPN case, because VDP is defined to be running on ECP(Edge Control Protocol), which is intended to operate between two peers over an IEEE802.1LAN. ECP has a designated Ether-type. ECP can be used to transmit various Upper Layer protocol, e.g. VDP and PE CSP(IEEE 802.1BR), and can carry more than one TLVs in one ECPDU. 

In the case, where TES and NVE are on different physical entities, and using L2. NVE receives ECP, decap the VDP TLV and send to upper layer for processing. A L-ACK is sent to TES(or say End Device) before next ECPDU can be sent from TES. 

If in the case where TES and NVE are on different physical entities, and using L3 protocol, there are two ways that we can do:
1) ECP is supported by router NVE, which I think is not difficult. 
2) another protocol is designated to carry VDP, correspondingly Hypervisor must support this protocol, e.g. BGP

Best Regards
Gu Yingjie

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 NAPIERALA, MARIA H
发送时间: 2012年7月12日 乐乐1:43
收件人: Paul Unbehagen
抄送: Thomas Narten; Luyuan Fang (lufang); [email-masked]
主题: Re: [nvo3] TES-NVE attach/detach protocol security (mobility-issues draft)

Maria

---

From: <[email-masked]>
Date: Thu, 12 Jul 2012 12:27:19 -0400

Larry,

> traffic flows across the device at L2.

To extend the DHCP functional analogy, that's a proxy, not just a relay.
Translating the VLAN tag may not be desirable because that translation
makes it more difficult to match up End Device and NVE configurations.

> the shelf 802.1Q bridges that are not participating in any protocols?  

I'm assuming that the intermediate bridges may have enough onboard
functionality that VDP does not pass through their data planes as if it
were ordinary Ethernet traffic.  I believe that support for any form
of spanning tree in such a bridge may be enough to cause this diversion
of VDP to the control plane.

> little benefit.  Am I missing something?

Yes, VLANs plus a virtual router for each tenant that operates across
VLANs would suffice as the traffic is VLAN tagged but not nvo3-encapped.
Whether IP forwarding between the End Device and NVE is appropriate
depends on the structure of the network.

Thanks,
--David

> Sent: Wednesday, July 11, 2012 8:47 PM
> To: Black, David; [email-masked]
> Cc: [email-masked]

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 12 Jul 2012 21:47:49 +0000

> [email-masked]
> Sent: Thursday, July 12, 2012 11:27 AM
> To: [email-masked]
> Cc: [email-masked]

[Linda] I think that it is a great idea to extend DHCP, to allow NVE request a local VID for a newly discovered Virtual Network. 

> If
> > >An IP-based protocol avoids these L2 complications, but it also
> cannot
> > >rely

---

From: <[email-masked]>
Date: Thu, 12 Jul 2012 18:40:42 -0400

Hi Linda,

> [Linda] I think that it is a great idea to extend DHCP, to allow NVE
> request a local VID for a newly discovered Virtual Network.

Actually I didn't intend to go there (at least not in this thread), as
DHCP traffic is L2 LAN/VLAN scoped, whereas VDP (and ECP) are scoped to
a single L2 link, and hence have rather different requirements/behavior
in terms of where they hit the control plane.

The only thing I'm trying to do is reuse the words "relay" and "proxy" as
they are used with DHCP to differentiate two classes of possible VDP
functionality in a bridge between an End Device and an NVE.  A "relay" just
forwards the traffic associated with the protocol whereas a "proxy" is a
full participant in the protocol.

Thanks,
--David

> Sent: Thursday, July 12, 2012 5:48 PM
> To: Black, David; [email-masked]
> Cc: [email-masked]
> [Linda] I think that it is a great idea to extend DHCP, to allow NVE request a
> local VID for a newly discovered Virtual Network.
> 
> 
> >

---

From: Aldrin Isaac <[email-masked]>
Date: Thu, 12 Jul 2012 19:50:49 -0400

Hi Gu,  questions inline -- aldrin

> The MACs and VLANs fields in VDP tlv can be null if they are not necessary to be transferred from End device to NVE. The VSI ID information can be used to find out which VN the VM belongs to. From…

Could the VSI Type ID be used to represent a generic service handle that is interpreted by a network manager to deliver service related configuration to the NVE?  How large is the VSI ID?  Seems to be only two octets from what I can gather -- this doesn't seem like it is large for environments where there are many defined network service instances/templates.

---

From: "Guyingjie (Yingjie)" <[email-masked]>
Date: Fri, 13 Jul 2012 07:42:57 +0000

" Could the VSI Type ID be used to represent a generic service handle that is interpreted by a network manager to deliver service related configuration to the NVE?  How large is the VSI ID?  Seems to be only two octets from what I can gather -- this doesn't seem like it is large for environments where there are many defined network service instances/templates."

Aldrin,

VSI Type is defined as a set of configuration that can be shared by multiple VSIs. So yes, you are right. The VTID (VSI Type ID) can represent a generic service handle and be interpreted as configuration to NVE.

VSI Type ID is 3 octets and VSI ID is 16 octets, so the VSI ID should be large enough.

Best Regards

Gu Yingjie

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Aldrin Isaac
发送时间: 2012年7月13日 乐乐7:51
收件人: Guyingjie (Yingjie)
抄送: Paul Unbehagen; Thomas Narten; Luyuan Fang (lufang); NAPIERALA, MARIA H; [email-masked]
主题: Re: [nvo3] 答复: TES-NVE attach/detach protocol security (mobility-issues draft)

>> Subject: Re: [nvo3] TES-NVE attach/detach protocol security (mobility-

>> I believe it's already in a few server vendors products already as I

>> saw prototypes of it a couple years ago.

>> On Jul 11, 2012, at 10:20 AM, "NAPIERALA, MARIA H" <[email-masked]>

>> wrote:

nvo3 mailing list

[email-masked]

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 13 Jul 2012 16:16:54 +0000

Maria, 

While it might not be necessary to run the complete IEEE802.1Qbg's VDP between TES and NVE, the functionalities and attributes defined by IEEE802.1Qbg's VDP would be valuable to the TES/NVE attach/detach. 
I can understand that XMPP protocol might be used to pass those needed attributes.  

Linda

> Sent: Wednesday, July 11, 2012 11:21 AM
> A layer 3 solution can use much simpler IP-based protocol (developed in
> IETF) such as Extensible Messaging and Presence Protocol (XMPP).
> 
> Maria

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 13 Jul 2012 16:37:32 +0000

David, 

I didn't mean literally using DHCP for this purpose. I just thought that some controller (like DHCP server) for NVE to get local VID would be useful. Well, it might be out of scope for NVo3. 

Linda

> Sent: Thursday, July 12, 2012 5:41 PM
> To: Linda Dunbar
> Cc: [email-masked]
> > Subject: RE: [nvo3] TES-NVE attach/detach protocol security
> (mobility-issues
> > draft)
> >
> >
> >
> > > > protocol with the End Device to negotiate a local .1Q tag for a
> VN on
> > > that
> > > > negotiate a separate local .1Q tag.  It would then translate tags
> as
> > > the
> request a
> > > > intermediate device(s) between the End Device and NVE are
> unmodified,
> > > off
> > > > traverse this IP forwarding node that lies between the End Device
> and
> > > the
> > > > NVE.  It seems like it would require some kind of tunnel, with
> the
> > > End
> > > > Device required to encapsulate/decapsulate the TES traffic into
> and
> > > out of
> > > > encap/decap to the NVE and only serves to make life more
> complicated,
> > > with
> > > > >> > 2) If NVE and TES are not in the same physical device, but
> TES
> > > to
> > > > >> More to the point, in a DC, when will an NVE and TES be
> separated
> > > by a
> > > > >> used, it will surely also be running over L2, which I assume
> (in a
> > > DC
> > > > >If either question has a different answer, an L2 protocol like
> VDP
> > > gets
> > > > >more interesting, as pointed out in a thread between Dimitri and
> I
> > > > >yesterday.
> > > > >In particular:
> > > > protocol with the End Device to negotiate a local .1Q tag for a
> VN on
> > > that
> > > > negotiate a separate local .1Q tag.  It would then translate tags
> as
> > > the
> > > > intermediate device(s) between the End Device and NVE are
> unmodified,
> > > off
> > > > so...assuming the method to keep each VN's traffic separated as
> it
> > > flows
> > > > across this bridge is 802.1Q VLANs (global to the device), then
> this
> > > will
> > > > limit how many VNs can be accessed on the NVE to how many VLANs
> can
> > > be
> > > > trunked on all the ports of this bridge simultaneously.  Since
> this
> > > bridge
> > > > is not running any protocols with the End Device or NVE,  the
> admin
> > > would
> > > > have to statically configure as many VLANs as supported on all
> the
> > > trunk
> > > > device cannot support 4K VLANs on all its ports, this means the
> NVE
> > > must
> > > > be configured to negotiate only the limited VLAN range, and all
> the
> > > End
> > > > traverse this IP forwarding node that lies between the End Device
> and
> > > the
> > > > NVE.  It seems like it would require some kind of tunnel, with
> the
> > > End
> > > > Device required to encapsulate/decapsulate the TES traffic into
> and
> > > out of
> > > > encap/decap to the NVE and only serves to make life more
> complicated,
> > > with
> > > > >> Cc: Paul Unbehagen; [email-masked]; Larry Kreeger (kreeger);
> Lucy
> > > yong;
> > > > >> NAPIERALA, MARIA H
> > > > >> > I'd like to get us on the same page on when VDP is needed
> and
> > > when
> > > > >> > 2) If NVE and TES are not in the same physical device, but
> TES
> > > to
> > > > >> More to the point, in a DC, when will an NVE and TES be
> separated
> > > by a
> > > > >> used, it will surely also be running over L2, which I assume
> (in a
> > > DC
> > > > >> analysis, so it's premature to be trying to be picking
> solutions
> > > here.
> > > > >>
> > > > >> But, my assumption is:
> > > > >>
> > > > >> 1) VDP exists and is already being implemented.  We do of
> course
> > > need
> > > > >> preferred over inventing a new protocol, no matter how
> "simple"
> > > that
> > > > >> new protocol would be?
> > > > >>
> > > > >> > 3) If NVE and TES are not in the same physical device, TES
> to
> > > NVE

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 13 Jul 2012 12:59:34 -0700

> On 7/11/12 10:28 AM, "Luyuan Fang (lufang)" <[email-masked]> wrote:

<snipped>

>       Hypervisor            Access Router/Switch

THANK YOU!

Terminology (e.g., TES) is only useful if it's used consistently and correctly.

> the TES IP addresses within that VN.

Agreed with both parts: virtual switch would run VDP, and the need for it. 

Kireeti

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Sat, 14 Jul 2012 03:16:58 +0000

David,

> approach for an L2 protocol such as VDP.

Actually, this is precisely what we want to avoid and not to be tied to a link-layer.

> An IP-based protocol avoids these L2 complications, 

Yes.

> but it also cannot rely

This is exactly what we want to avoid in a layer 3 solution.

Maria

> > From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Thomas
> > Narten

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Mon, 16 Jul 2012 21:47:57 +0000

> Agreed with both parts: virtual switch would run VDP, and the need for

In a layer 3 VN solution there is no need for VDP. The issue with VDP is that it is tied to the physical location (link-layer) of the information it conveys. It is an example of a protocol where the application payloads ride directly over Ethernet, without a layer 3 header. Designing protocols that put application payloads on top of Ethernet directly is not a good idea. 

Assume that system A (e.g., end-system) is managed by a management station that sends to it a message m1; A then sends a subset of this information as a message m2 to B (e.g., the first-hop switch/router). Now, it might be much more secure to turn this flow information around and make the management station to send m2 directly to B. This will ensure that A does not alter the content of m2. If m2 is an application message that rides directly on a layer 2 protocol (e.g., VDP message) the above is not possible (the management station and B will not be on the same subnet).

The application protocols should ride on top of a transport that can be secured. It would also be reasonable to expect that the application protocol is expressed in a way that is easily extendable. One obvious choice is an XML document on a channel that can be authenticated using TCP/IP at layer 3/4. There are several IETF standardized ways to carry XML documents. XMPP is one such option, there are also other.

---

From: Anoop Ghanwani <[email-masked]>
Date: Thu, 26 Jul 2012 17:02:35 -0700

> in terms of where they hit the control plane.

That scope is the case as defined today, but that can
be changed.  We can always define the capability for
ECP/VDP to be sent to a specific unicast address.
There is a precedent for that with LLDP & LACP.
However, we then have to address the problem for how
to discover that unicast address.

> full participant in the protocol.

This type of operation is less clear to me.

Anoop

---

From: "Guyingjie (Yingjie)" <[email-masked]>
Date: Fri, 27 Jul 2012 01:23:52 +0000

Agree. I just query with IEEE DCB.  ECP and VDP can be sent to specific node, not only the adjacent bridge. It can be sent to bridge, routers, even Firewalls...
The text in VDP standard draft is as following:

" The destination address of the Ethernet frame that contains a ECPDU is specified by the ULP. The address
used is either an individual MAC address or one of the reserved addresses specified in Table 8-1 " 
Whereas, an example of ULP is VDP. 

Best Regards
Gu Yingjie

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Anoop Ghanwani
发送时间: 2012年7月27日 乐乐8:03
收件人: [email-masked]
抄送: [email-masked]; Linda Dunbar
主题: Re: [nvo3] TES-NVE attach/detach protocol security (mobility-issues draft)

Anoop