Subject: [OPSAWG] virtual switches an network management systems

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Mar 2011 10:43:13 +0200

Hi,

concerning the presentation involving virtual switches (layer two
bridges, draft-okita-ops-vnetmodel-04), I wonder whether the problem
is not just a lack of implementations of standard bridge management
interfaces in common hypervisor platforms. Once hypervisors export
standard bridge management interfaces, network management systems will
gain visibility into the virtual bridges and the problem might be
solved to some larger extend.

If I am correct, then the problem is an implementation problem (lack
of network management support in hypervisors), not a lack of standards
per se.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Yingjie Gu(yingjie)" <[email-masked]>
Date: Mon, 28 Mar 2011 09:05:50 +0000

My question is "except for learning whole network topology including both physical and virtual switches, what's the other benefits we can gain from this model?" If the topology is the only reason, LLDP is enough.
Well, when I attend other SDOs, I talked with HP, VMware and IBM representatives, they said, surprisingly consistent, they would do most, if not all, physical switches functions on their Hypervisors, and the network side needn't do many changes to adapt to server virtualization.  And they wouldn't let the network manager to manage their virtual switches. 

________________________________________
发件人: [email-masked] [[email-masked]] 代表 Juergen Schoenwaelder [[email-masked]]
发送时间: 2011年3月28日 16:43
到: [email-masked]
主题: [OPSAWG] virtual switches an network management systems

Hi,

/js

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Mon, 28 Mar 2011 22:11:10 +1100

Greetings Juergen,

<hat off>
	I'm not sure that's the extent of the problem, Juergen.  I know within my infrastructure here in Telstra, a standard "bridge management layer" doesn't really solve the issues.  Server migration, large network domains, desire to avoid a flat fabric (from a management point of view) for VERY large networks, all leads this to potentially a different problem space.  

</hat off>

	Chris

> of network management support in hypervisors), not a lack of standards

---
李柯睿
Check my PGP key here:
https://www.asgaard.org/~cdl/cdl.asc

---

From: <[email-masked]>
Date: Tue, 29 Mar 2011 01:57:30 +0900

Yingjie,

Thank you for your comments to my draft/presentation.

> My question is "except for learning whole network topology 
> including both physical and virtual switches, what's the 
> other benefits we can gain from this model?" 
> If the topology is the only reason, LLDP is enough.

As you said, LLDP is enough to get a topology information.
However, IMO, it is not enough to get "both of" virtual 
topology and physical topology. Please assume the case that 
all VSWs on a host speak LLDP, and an chassis ID is allocated 
to each VSW for lldpLocChassisId or lldpRemChassisId. In this 
case, we cannot identify the physical server that has own 
chassis ID. It leads to loss of the physical-topology information.

> Well, when I attend other SDOs, 

Could you tell me which SDO you attended? The DCB-TG of IEEE 802.1 
or the SVPC WG of the DMTF?

> I talked with HP, VMware and IBM representatives, they said, 
> surprisingly consistent, they would do most, if not all, 
> physical switches functions on their Hypervisors, and the 
> network side needn't do many changes to adapt to server virtualization.

Of course, I can understand their motivation to deploy the 
physical-switch features to their VMMs. It may help network 
operators to expand their management scope into virtual switches.

> And they wouldn't let the network manager to manage their virtual switches. 

I would appreciate if you would let me know what this means.
Does it mean that the management of virtual switches should be 
handled by other management system than the "network manager"?

Best regards,

Hideki Okita
[email-masked]