Subject: [nvo3] Question of the terminology used in draft-kreeger-nvo3-overlay-cp-00

From: Linda Dunbar <[email-masked]>
Date: Wed, 7 Mar 2012 18:14:51 +0000

Larry, Dinesh, Thomas, David, and Murari:

The definition of "overlay boundary points" in your draft gives people an impression that the network in the middle is "overlay". But then, the next definition of "underlaying network" states that it provides the connectivity among all Overlay Boundary Points. So "underlaying network" is actually the middle of the network which connect all the " boundary points". 

Question: is it more accurate to call the network in the middle as "overlay network" or should it be called "underlay network"? 

If the middle network is called "underlay", then is it more accurate to call the boundary points as "underlay boundary points"?

Overlay network is more like a Client-Server relationship. The Server Network provides the connectivity among all boundary points (or nodes which perform the encapsulation/decapsulation). The client traffic (or Client Network) are carried over by the "Server Network". 

Can we use "Client Network" and "Server Network" in NV03? 
For TRIL/L2VPN/L3VPN/MPLS, there is a clear name for the network which carry the user traffic. This "overlay" and "underlay" can make it more difficult for accurate description. 

Another issue with the definition of "underlaying network":  
The draft states: "The Underlying Network can be completely unaware of the VN of packets carried within the encapsulation". 
Actually the underlaying network has to be able to segregate different virtual networks of user traffic. That is why 24 bits VNID is introduced. So your "underlaying network" IS aware of the Virtual Network of packets carried within the encapsulation.  Just that "underlaying network" don't see the address space carried within the encapsulation. 

If the "Server Network" and "Client Network" term are adopted, accurate description can be easier. E.g. 

Server network: This is the network that provides the connectivity between the OBPs. The addresses in client network are transparent in server network.  Addresses within the Server Network are also
referred to as "outer addresses" because they exist in the outer
encapsulation. The Server Network can use a completely
different protocol (and address family) from Client network. 

Linda Dunbar

---

From: "Pat Thaler" <[email-masked]>
Date: Wed, 7 Mar 2012 20:03:18 +0000

Linda,

I think that Server Network would be confusing because the end systems are often called servers. Perhaps use Tenant Network (Client network would work, but since there is a Tenant Network ID, Tenant Network is more consistent) and Provider Network.

Some underlying networks are completely unaware of the VN of the packets carried within the encapsulation. In those networks, the traffic segregation is handled entirely by the overlay boundary encapsulation and decapsulation and only the boundary ports use the VN. E.g VxLAN and NVGRE are intended to work that way. Some other underlaying networks do have intermediate devices that use the VN. "The Underlying Network can be completely unaware of the VN of packets carried within the encapsulation" is accurate because it says that they can be unaware but not that they must be unaware or are always unaware.

Pat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, March 07, 2012 10:15 AM
To: Larry Kreeger; Thomas Narten; [email-masked]; Murari Sridharan; Dinesh Dutt
Cc: [email-masked]
Subject: [nvo3] Question of the terminology used in draft-kreeger-nvo3-overlay-cp-00

Linda Dunbar

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

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 7 Mar 2012 20:34:01 +0000

I agree "Client network" <-> "provider network" is better. 

As for your second point: 
both NV03 charter and its problem statement indicate that the "overlay network" must be able to isolate traffic from different virtual networks of "clients". So "overlay network" is aware of which Virtual network a packet belong to, just it uses a different identifiers (e.g. 24 bits ID). 

So "unaware" is not accurate. Maybe you can say that "overlay network" doesn't see the client virtual network ID, instead it uses its own identifier to differentiate traffic from different virtual networks from clients. 

Linda

> From: Pat Thaler [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2012 2:03 PM
> To: Linda Dunbar; Larry Kreeger; Thomas Narten; [email-masked];
> Murari Sridharan; Dinesh Dutt
> Cc: [email-masked]
> Subject: RE: Question of the terminology used in draft-kreeger-nvo3-
> overlay-cp-00
> 
> Linda,
> 
> I think that Server Network would be confusing because the end systems
> are often called servers. Perhaps use Tenant Network (Client network
> would work, but since there is a Tenant Network ID, Tenant Network is
> more consistent) and Provider Network.
> 
> Some underlying networks are completely unaware of the VN of the
> packets carried within the encapsulation. In those networks, the
> traffic segregation is handled entirely by the overlay boundary
> encapsulation and decapsulation and only the boundary ports use the VN.
> E.g VxLAN and NVGRE are intended to work that way. Some other
> underlaying networks do have intermediate devices that use the VN. "The
> Underlying Network can be completely unaware of the VN of packets
> carried within the encapsulation" is accurate because it says that they
> can be unaware but not that they must be unaware or are always unaware.
> 
> Pat
> 
> The definition of "overlay boundary points" in your draft gives people
> an impression that the network in the middle is "overlay". But then,
> the next definition of "underlaying network" states that it provides
> the connectivity among all Overlay Boundary Points. So "underlaying
> network" is actually the middle of the network which connect all the "
> boundary points".
> 
> Question: is it more accurate to call the network in the middle as
> "overlay network" or should it be called "underlay network"?
> 
> If the middle network is called "underlay", then is it more accurate to
> call the boundary points as "underlay boundary points"?
> 
> 
> Overlay network is more like a Client-Server relationship. The Server
> Network provides the connectivity among all boundary points (or nodes
> which perform the encapsulation/decapsulation). The client traffic (or
> Client Network) are carried over by the "Server Network".
> 
> For TRIL/L2VPN/L3VPN/MPLS, there is a clear name for the network which
> carry the user traffic. This "overlay" and "underlay" can make it more
> difficult for accurate description.
> 
> The draft states: "The Underlying Network can be completely unaware of
> the VN of packets carried within the encapsulation".
> Actually the underlaying network has to be able to segregate different
> virtual networks of user traffic. That is why 24 bits VNID is
> introduced. So your "underlaying network" IS aware of the Virtual
> Network of packets carried within the encapsulation.  Just that
> "underlaying network" don't see the address space carried within the
> encapsulation.
> 
> 
> Server network: This is the network that provides the connectivity
> between the OBPs. The addresses in client network are transparent in
> server network.  Addresses within the Server Network are also

---

From: Larry Kreeger <[email-masked]>
Date: Wed, 07 Mar 2012 15:03:02 -0800

Hi Linda,

My replies are inline below.

 - Larry

On 3/7/12 10:14 AM, "Linda Dunbar" <[email-masked]> wrote:

> The definition of "overlay boundary points" in your draft gives people an
> impression that the network in the middle is "overlay". But then, the next
> definition of "underlaying network" states that it provides the connectivity
> among all Overlay Boundary Points. So "underlaying network" is actually the
> middle of the network which connect all the " boundary points".

Can you tell me what specifically gave you the impression that the
Underlying Network is called the overlay network?  The figures all show the
OBPs connecting to the Underlying Network.
> 
> Question: is it more accurate to call the network in the middle as "overlay
> network" or should it be called "underlay network"?

Yes, the figures show this and the terminology section says the following:

   Underlying Network:  This is the network that provides the
      connectivity between the OBPs.  The Underlying Network can be
      completely unaware of the VN of packets carried within the
      encapsulation.  Addresses within the Underlying Network are also
      referred to as "outer addresses" because they exist in the outer
      encapsulation.  The Underlying Network can use a completely
      different protocol (and address family) from that of the overlay.

> 
> If the middle network is called "underlay", then is it more accurate to call
> the boundary points as "underlay boundary points"?

The OBPs are the entry into the Virtual Networks which are carried as an
overlay across the Underlying Network.  Many different overlay networks can
be carried across the Unerlying Network.  If you look at packets on the wire
in the Underlying Network, they will have two headers: The outer header
corresponding to the address family of the Underlying Network, and an inner
header corresponding to the Virtual Networks which are carried over it.  The
OBP encapsulates the packets and therefore act as the entry point to the
overlay.  So, the OBP as on the border of both the overlay networks and the
Underlying Network that carries it, but we shouldn't confuse the two.

>  
> Overlay network is more like a Client-Server relationship. The Server Network
> provides the connectivity among all boundary points (or nodes which perform
> the encapsulation/decapsulation). The client traffic (or Client Network) are
> carried over by the "Server Network".
> 
> For TRIL/L2VPN/L3VPN/MPLS, there is a clear name for the network which carry
> the user traffic. This "overlay" and "underlay" can make it more difficult for
> accurate description.

IMO using the term client network and server network would be pretty
confusing.  These terms are very overloaded.
> The draft states: "The Underlying Network can be completely unaware of the VN
> of packets carried within the encapsulation".
> Actually the underlaying network has to be able to segregate different virtual
> networks of user traffic. That is why 24 bits VNID is introduced. So your
> "underlaying network" IS aware of the Virtual Network of packets carried
> within the encapsulation.  Just that "underlaying network" don't see the
> address space carried within the encapsulation.

No, the Underlying Network is completely unaware of the 24 bit VNID.
Segmenting the traffic is only done by the OBPs which see the VNID within
the encapsulation.

> Server network: This is the network that provides the connectivity between the
> OBPs. The addresses in client network are transparent in server network.
> Addresses within the Server Network are also

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 7 Mar 2012 22:59:49 +0000

My detailed comments and suggested wording improvement are marked on the attached PDF file. In case the attachment can't be accepted by the ietf mailing list, here are my comments details and the suggested wording improvement:

Section 2 Terminology:

End Station:
The current definition of "end station" in the draft mixes the function of "end station" with OBP. Even though OBP may be embedded in end station, the terminology section should strictly describe each individual term. Strictly speaking:

      End station is a device which originates and terminates data frames. End station doesn't switch data frames.

In the context of NV03, I think "Client device" should be used instead of "End-Station" because traffic coming to OBP may come from devices which themselves encapsulate traffic from their clients. Then, those devices are not really "End Stations".

Network Service Appliance:
      The current definition extends to explain how OBP function can be embedded with Network Service Appliance. I think it is more clear if "Terminology" section can describe Network Service Appliance independently from OBP.
      Later in the draft body, description can be given on how to embed OBP function on Network Service Appliance.

Section 3: Control Plane Protocol Functionality:

I suggest to have a separate sub-section describing OBP functionality. Then, followed by a subsection on standalone OBP,  a sub-section on OBP being embedded in hypervisor, and another sub-section on OBP embedded with Network Service Appliance.

Here is my suggested wording:

      3.1. OBP Functionality:

      OBP provides overlay encapsulation for traffic from client network to traverse "underlay network", decapsulation for traffic exiting "underlay network" towards client network.

      OBP function can be on devices which are physically separate from end stations (e.g. ToR switch), or can be embedded within a hypervisor or a Network Service Appliance.

      3.2 OBP embedded in Hypervisor

      3.3 OBP embedded in Network Service Appliance

      3.4 OBP on external networking device

The current wording under 3.1&3.2 should be put under the subsection of OBP Functionality.
      The last sentence of current 3.1 says that "one goal of NV03 is to eliminate flooding". But the NV03 charter states that "one control plane is via learning, which is appropriate for smaller data centers"

The current wording under 3.3 should be put under the subsection of "OBP on external networking device"

      In the second paragraph of the current wording of 3.3, you state "When an OBP is external, a protocol is needed between a client device making use of external OBP".
      But sometimes you don't have control over client devices.  Therefore, the requirement shouldn't rely on Client device giving any signal when joining or leaving the attachment to OBP.

The draft also states "OBP must be notified when a client device require connection..". This requirement is too harsh. Data Center network may not have control on if server/hypervisor sending out notification when VMs move in and move out. It is more reasonable to require "OBP to monitor all its attached client devices", e.g. "sending ARP/ND requests periodically to monitor the directly attached client devices"

Comments to wording under 3.4:
      The draft states that "A protocol for OBP to get this mapping is a useful function". Why do you need a protocol? A global mapping of Local-VLAN&OBP-ID <-> Overlay-VN-ID has to be planned and maintained by operator's management tool. The mapping shouldn't change very much. So the global table can be downloaded to each OBP.

Linda Dunbar

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 7 Mar 2012 23:31:56 +0000

Larry, 

> From: Larry Kreeger [mailto:[email-masked]]

> Underlying Network is called the overlay network?  

"OBP: Overlay boundary Point". When you say XXX boundary point, it is so easy to interpret that the "XXX" is surrounded by the "points". i.e. XXX is in the middle. 

In addition, in the NV03 charter statement, many places used "overlay network" to represent the network carrying the client traffic. For example, in the last paragraph of the charter:
 "Packets forwarded across the boundary would simply need to have the tenant identifier on the overlay side mapped into a corresponding VPN identifier on the VPN side"

The "overlay" side is put in parallel as VPN side, doesn't it mean "overlay" is the network which carry the client traffic? 

> confusing.  These terms are very overloaded.

How about Pat's suggestion of "Client network" and "Provider Network"? 

> Segmenting the traffic is only done by the OBPs which see the VNID

[Linda] But the NV03 charter states that it is necessary to isolate traffic from various client virtual networks. It is especially important in Data center environment. 

Linda

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 7 Mar 2012 23:34:55 +0000

In the NV03 charter statement, it states that one control plane will use a learning mechanism similar to IEEE802.1D. 

IEEE802.1D doesn't have VLAN based learning. I would think it should be IEEE802.1Q. Is it intentional to have IEEE802.1D there? 

Thanks, Linda

---

From: "Pat Thaler" <[email-masked]>
Date: Wed, 7 Mar 2012 23:59:22 +0000

Linda, thanks for pointing this out again.  I sent a similar comment on Feb 17 and haven't seen a response. Pat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, March 07, 2012 3:35 PM
To: Larry Kreeger; Thomas Narten; David Black; Murari Sridharan; Dinesh Dutt
Cc: [email-masked]
Subject: [nvo3] NV03 Charter question

Thanks, Linda

---

From: Thomas Narten <[email-masked]>
Date: Wed, 07 Mar 2012 18:08:52 -0700

> Linda, thanks for pointing this out again.  I sent a similar comment
>  on Feb 17 and haven't seen a response. Pat

Bad reference on my part. Next version will reference 802.1Q.

Thanks!

Thomas

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 8 Mar 2012 20:48:20 +0000

There are two IETF WGs providing solutions to interconnect L2 networks: one is L2VPN, and the other is TRILL. L2VPN transparently pass all L2 traffic across the "underlay" network (i.e. MPLS), while as TRILL's RBridge edge terminates all the L2 BPDUs.   

If taking encapsulation format out of the picture, is NV03 more like L2VPN or more like TRILL?

Linda Dunbar

---

From: David Allan I <[email-masked]>
Date: Thu, 8 Mar 2012 16:17:24 -0500

Hi Linda:

I'm not sure that is a useful classification. As far as Ethernet is concerned, all end up supporting some form of a bridging overlay independent of the scope of any subtending network. And how an implementation handles L2 networking things like STP or G.8032, or 802.3ad (LAG) is the implementation's business...

What is likely a more accurate taxonomy would be:

We have Ethernet over Ethernet solutions (e.g. SPBM)
We have Ethernet over L2.5 solutions (e.g. TRILL, MPLS)
We have Ethernet over L3 solutions (where NVO3 would aspire to be)

We have not yet explored Ethernet over HTTP, but give the industry time ;-)

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Thursday, March 08, 2012 3:48 PM
To: Thomas Narten
Cc: [email-masked]
Subject: [nvo3] Another question on NV03 charter

Linda Dunbar

---

From: John E Drake <[email-masked]>
Date: Thu, 8 Mar 2012 13:48:42 -0800

Dave,

I would characterize L2 & L3 VPNs as both over L3, and I think NV03 aspires to provide exactly the same functionality.  (This is very clear from the proposed charter.)

Because to this point L2 & L3 VPNs have largely been deployed by SPs, the NV03 proponents assert that these technologies do not apply to the problems they wish to address.

Thanks,

John

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> David Allan I
> Sent: Thursday, March 08, 2012 1:17 PM
> To: Linda Dunbar; Thomas Narten
> Cc: [email-masked]
> Subject: Re: [nvo3] Another question on NV03 charter
> 
> Hi Linda:
> 
> I'm not sure that is a useful classification. As far as Ethernet is
> concerned, all end up supporting some form of a bridging overlay
> independent of the scope of any subtending network. And how an
> implementation handles L2 networking things like STP or G.8032, or
> 802.3ad (LAG) is the implementation's business...
> 
> There are two IETF WGs providing solutions to interconnect L2 networks:
> one is L2VPN, and the other is TRILL. L2VPN transparently pass all L2
> traffic across the "underlay" network (i.e. MPLS), while as TRILL's
> RBridge edge terminates all the L2 BPDUs.
>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 8 Mar 2012 22:01:22 +0000

David, 

> From: David Allan I [mailto:[email-masked]]

> And how an

[Linda] Control plane is different for TRILL whose edge nodes terminate L2BPDU and for L2VPN/MAC-in-MAC whose edge nodes don't terminate L2BPDN. My question is simply the scope of NV03. 

Linda

---

From: David Allan I <[email-masked]>
Date: Fri, 9 Mar 2012 12:40:07 -0500

HI Linda:

Understood. That makes more sense....

I would assume NOT a greenfield deployment model, so the requirement should be called out.

Cheers
Dave 

-----Original Message-----
From: Linda Dunbar [mailto:[email-masked]] 
Sent: Thursday, March 08, 2012 5:01 PM
To: David Allan I; Thomas Narten
Cc: [email-masked]
Subject: RE: Another question on NV03 charter

David, 

Linda

---

From: Larry Kreeger <[email-masked]>
Date: Fri, 09 Mar 2012 16:56:57 -0800

Linda,

The main use case for Network Virtualization Overlays is to carry packets
send from End Systems (e.g. VMs or Network Appliances) across the overlay.
In other words, the Overlay Border Points are all the way at the edge of the
network with only End Stations connected to them, not bridges.  No BPDUs
should ever arrive from these devices.  So, unlike an L2VPN device which is
likely to be connected near the WAN edge of the data center (and therefore
to a bridge, an Overlay Border Point would not.

Given that, I would probably recommend detecting BPDUs and dropping them
and/or notifying the admin that there is potentially a misconfiguration.

 - Larry

On 3/8/12 2:01 PM, "Linda Dunbar" <[email-masked]> wrote:

> [Linda] Control plane is different for TRILL whose edge nodes terminate L2BPDU
> and for L2VPN/MAC-in-MAC whose edge nodes don't terminate L2BPDN. My question
> is simply the scope of NV03.
> 
> Linda 
>

---

From: "Stiliadis, Dimitrios (Dimitri)" <[email-masked]>
Date: Fri, 9 Mar 2012 23:34:53 -0600

Larry,

I can see use cases where this not  accurate. Consider a blade server, where one wants to associate a whole blade with an overlay and the OVB is the ToR switch. Alternatively, consider one of the new types of systems with low power processors, with an internal fabric and a ToR as an OVB. In both of these cases, the End System is a processor, and there is at least one L2 hop between the End System and the OVB.

Not only that, but it might be that the End System is multihomed to multiple ToRs that provide the OVB function (example a blade system with multiple uplinks to multiple ToRs where the ToRs are the OVBs). It is also possible that each processor is multihomed to two blade switches, which in turn are multihomed to dual ToRs,providing the OVB function. I can also see environments that mix new and old, where an old VLAN based network is connected to an overlay.

I am not sure we can restrict all the use cases to a very limited configuration, that assumes point to point connectivity between End Systems and OVB.

Dimitri

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 22 Mar 2012 19:56:28 +0000

Agree with Dimitri. 
However, if NV03 only considers encapsulating an overlay header for data frames from End Systems, then the scope is very clear, which has less debate on various Layer 2 issues (and simpler than L2VPN). 

Linda

> From: Stiliadis, Dimitrios (Dimitri) [mailto:dimitri.stiliadis@alcatel-
> lucent.com]
> Sent: Friday, March 09, 2012 11:35 PM
> To: Larry Kreeger
> Cc: Linda Dunbar; David Allan I; Thomas Narten; [email-masked]
> I can see use cases where this not  accurate. Consider a blade server,
> where one wants to associate a whole blade with an overlay and the OVB
> is the ToR switch. Alternatively, consider one of the new types of
> systems with low power processors, with an internal fabric and a ToR as
> an OVB. In both of these cases, the End System is a processor, and
> there is at least one L2 hop between the End System and the OVB.
> 
> Not only that, but it might be that the End System is multihomed to
> multiple ToRs that provide the OVB function (example a blade system
> with multiple uplinks to multiple ToRs where the ToRs are the OVBs). It
> is also possible that each processor is multihomed to two blade
> switches, which in turn are multihomed to dual ToRs,providing the OVB
> function. I can also see environments that mix new and old, where an
> old VLAN based network is connected to an overlay.
> 
> I am not sure we can restrict all the use cases to a very limited
> configuration, that assumes point to point connectivity between End
> Systems and OVB.
> 
> Dimitri
> 
>

---

From: Larry Kreeger <[email-masked]>
Date: Thu, 22 Mar 2012 14:52:20 -0700

Hi Linda,

We are currently considering the overlays to be terminated at the edge of
the network on either side of the wire connecting a server to the network.
Specifically, this means either inside the hypervisor or in the access
switch it is connected to.

As Dimitri brings up below, it is interesting to consider blade server
systems that have a bridge-like function built into them, where the access
switch is outside of the blade server system.  In that case, there is a type
of bridging element.  I can't speak for all blade systems, but I know of
more than one that attempt to make the integrated "bridge-like"
functionality look more like a host to the network switches that they are
connected to.  For example, they do not switch traffic between uplinks and
therefore do not run STP (after all, they are often administered by server
admins and not network admins).  Since these "bridge-like" devices are in a
bit of a limbo between acting like an end system and acting like a bridge, I
think it is worthwhile trying to see how the network overlay can still be
terminated at the access switch they are connected to (since these access
switches are administered by the network admin).

 - Larry

On 3/22/12 12:56 PM, "Linda Dunbar" <[email-masked]> wrote:

> Agree with Dimitri.
> However, if NV03 only considers encapsulating an overlay header for data
> frames from End Systems, then the scope is very clear, which has less debate
> on various Layer 2 issues (and simpler than L2VPN).
> 
> Linda
>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 22 Mar 2012 22:53:05 +0000

Larry, 

Personally I think NV03 should cover the blade switch scenario because there is a possibility that some servers in a data center can perform encapsulating and some servers can't. Then you have an overlay network with some overlay boundary points at servers and other overlay boundary points at access switches. 
Besides, you may have Layer 2 to data center gateway. Then the overlay boundary at the gateway has a very large Layer 2 network attached. 

L2VPN has done a lot of work in this area, e.g. split horizon among all access ports to prevent loops, etc. 

Linda 

> Sent: Thursday, March 22, 2012 4:52 PM
> To: Linda Dunbar; Stiliadis, Dimitrios (Dimitri)
> Cc: David Allan I; Thomas Narten; [email-masked]
> >>> In other words, the Overlay Border Points are all the way at the
> edge
> >> of the
> >>>> and for L2VPN/MAC-in-MAC whose edge nodes don't terminate L2BPDN.
> My
> >> question

---

From: Rakesh Saha <[email-masked]>
Date: Thu, 22 Mar 2012 21:02:00 -0700

Hi All,
Many switching entities inside blade chassis have full layer 2 and layer 3 
capabilities. In essence they behave like edge switches.
There are variations which are not full layer 2 ( and layer 3). Examples 
are HP Virtual Connect and Cisco UCS Flex.

Regards,
Rakesh.

From:   Larry Kreeger <[email-masked]>
To:     Linda Dunbar <[email-masked]>, "Stiliadis, Dimitrios 
(Dimitri)" <[email-masked]>
Cc:     [email-masked], "[email-masked]" <[email-masked]>, 
David Allan I <[email-masked]>
Date:   03/22/2012 02:53 PM
Subject:        Re: [nvo3] Another question on NV03 charter
Sent by:        [email-masked]

Hi Linda,

As Dimitri brings up below, it is interesting to consider blade server
systems that have a bridge-like function built into them, where the access
switch is outside of the blade server system.  In that case, there is a 
type
of bridging element.  I can't speak for all blade systems, but I know of
more than one that attempt to make the integrated "bridge-like"
functionality look more like a host to the network switches that they are
connected to.  For example, they do not switch traffic between uplinks and
therefore do not run STP (after all, they are often administered by server
admins and not network admins).  Since these "bridge-like" devices are in 
a
bit of a limbo between acting like an end system and acting like a bridge, 
I
think it is worthwhile trying to see how the network overlay can still be
terminated at the access switch they are connected to (since these access
switches are administered by the network admin).

 - Larry

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 23 Mar 2012 14:46:07 +0000

Very good point, Rakesh.

Your point makes it more important for Overlay to consider bridged Layer 2 before the Overlay boundary points.

Thanks,

Linda

From: Rakesh Saha [mailto:[email-masked]]
Sent: Thursday, March 22, 2012 11:02 PM
To: Larry Kreeger
Cc: David Allan I; Stiliadis, Dimitrios (Dimitri); Linda Dunbar; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [nvo3] Another question on NV03 charter

Hi All,
Many switching entities inside blade chassis have full layer 2 and layer 3 capabilities. In essence they behave like edge switches.
There are variations which are not full layer 2 ( and layer 3). Examples are HP Virtual Connect and Cisco UCS Flex.

Regards,
Rakesh.

From:        Larry Kreeger <[email-masked]>
To:        Linda Dunbar <[email-masked]>, "Stiliadis, Dimitrios (Dimitri)" <[email-masked]>
Cc:        [email-masked], "[email-masked]" <[email-masked]>, David Allan I <[email-masked]>
Date:        03/22/2012 02:53 PM
Subject:        Re: [nvo3] Another question on NV03 charter
Sent by:        [email-masked]
________________________________

Hi Linda,

- Larry

---

From: Larry Kreeger <[email-masked]>
Date: Fri, 23 Mar 2012 11:20:18 -0700

Rakesh,

Assuming the BOF turns into a WG, we can discuss whether we need to support
this.  I hate to further complicate the overlay solution.  There are plenty
of other L2VPN technologies that can be placed at the DC WAN edge and need
to deal with this issue.

My preference is to keep the encap function at the edge with no bridges
between the end systems connecting to a Virtual Network and the encap/decap
function.  If there is a full function bridge in the blade chassis, there
are two choices.  Encap/decap in the server, or do it in the full function
bridge within the chassis.

 - Larry

On 3/22/12 9:02 PM, "Rakesh Saha" <[email-masked]> wrote:

>>> <mailto:dimitri.stiliadis@alcatel->
>>> >> lucent.com]
>>>>>> >>>>> From: David Allan I [mailto:[email-masked]
>>>>>> <mailto:[email-masked]> ]
>>>>> >>>> 
>>>>> >>>> 
>>>>>> >>>>> And how an
>>>>> <https://www.ietf.org/mailman/listinfo/nvo3>
>>>> >>> 
>>>> <https://www.ietf.org/mailman/listinfo/nvo3>
> 
> <https://www.ietf.org/mailman/listinfo/nvo3>
> 
> 
> 
>