Subject: Re: Response to some comments on IS-IS VPLS

From: sajassi <[email-masked]>
Date: Mon, 02 Apr 2012 10:44:23 -0700

Hi Robert,

The connectivity between the two VMs is provided by L2VPN over MPLS/IP -
e.g.,, VM1/VLAN1 an VM2/VLAN1 are mapped to the same L2VPN. Why do you
think, the encap/decap must be done on the end-host (hypvervisor, OVS,etc.).

Cheers,
Ali

On 3/30/12 2:48 AM, "Robert Raszuk" <[email-masked]> wrote:

> Ali,
> 
>> Third, before bashing E-VPN/PBB-EVPN, I would recommend that you
>> understand what it is.
> 
> Great point indeed.
> 
> Could you share a pointer to the list which describes VM 1 on Host A's
> hypervisor to VM 2 on host B's hypervisor interconnect model for both
> above solutions just assuming that you have IP or MPLS reachability
> between such hosts ?
> 
> The requirement of my question is that any encapsulation/decapsulation
> required for such interconnection should happen on the end hosts
> (kernel, OVS, NIC etc ...) and not on the "network".
> 
> Best regards,
> R.
> 
> 
> 
>

---

From: Jon Hudson <[email-masked]>
Date: Mon, 2 Apr 2012 10:54:27 -0700

In my experience it's because it would require the virtualization folks to open a ticket and interact with the network team.

Many want to be able to on a whim create wormholes from any hypervisor(s) to any hypervisors(s) without dependencies on other teams that would require a ticket, change control or approval by a steering committee.

J  

On Apr 2, 2012, at 10:44 AM, sajassi <[email-masked]> wrote:

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

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 2 Apr 2012 14:43:07 -0400

Hi Jon,
For application to be able to do what you've described requires network to be designed accordingly. IMHO, support of implicit requirements is rather accidental and support of explicit requirements is limited by laws of physics.

	Regards,
		Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jon Hudson
Sent: Monday, April 02, 2012 10:54 AM
To: sajassi
Cc: [email-masked]; [email-masked]; <[email-masked]>
Subject: Re: [nvo3] Response to some comments on IS-IS VPLS

J  

On Apr 2, 2012, at 10:44 AM, sajassi <[email-masked]> wrote:

> Hi Robert,
> 
> The connectivity between the two VMs is provided by L2VPN over MPLS/IP 
> - e.g.,, VM1/VLAN1 an VM2/VLAN1 are mapped to the same L2VPN. Why do 
> you think, the encap/decap must be done on the end-host (hypvervisor, OVS,etc.).
> 
> Cheers,
> Ali
> 
> 
>> Could you share a pointer to the list which describes VM 1 on Host 
>> A's hypervisor to VM 2 on host B's hypervisor interconnect model for 
>> both above solutions just assuming that you have IP or MPLS 
>> reachability between such hosts ?
>> 
>> The requirement of my question is that any 
>> encapsulation/decapsulation required for such interconnection should 
>> happen on the end hosts (kernel, OVS, NIC etc ...) and not on the "network".
>> 
>> Best regards,
>> R.
>> 
>> 
>> 
>> 
>

---

From: sajassi <[email-masked]>
Date: Mon, 02 Apr 2012 12:24:39 -0700

The interaction can be automated via the use of some protocol (e.g., VDP in
802.1Qbg) which is being talked about in NOV3.

Cheers,
Ali

On 4/2/12 10:54 AM, "Jon Hudson" <[email-masked]> wrote:

> In my experience it's because it would require the virtualization folks to
> open a ticket and interact with the network team.
> 
> Many want to be able to on a whim create wormholes from any hypervisor(s) to
> any hypervisors(s) without dependencies on other teams that would require a
> ticket, change control or approval by a steering committee.
> 
> J  
>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 02 Apr 2012 22:34:59 +0200

> Why do you think, the encap/decap must be done on the end-host
 > (hypvervisor, OVS,etc.).

Very simple.

Because I do not want to buy, install and operate network equipment from 
vendors even if this is interoperable across N vendors and rubber 
stamped by IETF.

It is not only about cost savings, velocity about enhancement delivery 
speed by vendor, but also about service differentiation between my 
network and competition.

Best,
R.

---

From: Jon Hudson <[email-masked]>
Date: Mon, 2 Apr 2012 13:36:25 -0700

I have been assured that this whole neutrino "measurement issue" is just a temporary setback

---

From: Jon Hudson <[email-masked]>
Date: Mon, 2 Apr 2012 13:42:09 -0700

Very true.

And personally I like a coordinated solution. However the argument I repeatedly get is " but we want to just do it ourselves. If we have to engage another group minutes become days"

Not saying right or wrong, just what customers I speak to usually tell me when I ask what their perceived value of encap/decap in the hypervisor is.

---

From: Jon Hudson <[email-masked]>
Date: Mon, 2 Apr 2012 13:43:28 -0700

Bingo

On Apr 2, 2012, at 1:34 PM, Robert Raszuk <[email-masked]> wrote:

> Because I do not want to buy, install and operate network equipment from vendors even if this is interoperable across N vendors and rubber stamped by IETF.
> 
> It is not only about cost savings, velocity about enhancement delivery speed by vendor, but also about service differentiation between my network and competition.
> 
> Best,
> R.
> 
>> Hi Robert,
>>

---

From: Ken Gray <[email-masked]>
Date: Mon, 2 Apr 2012 14:33:02 -0700

The description below, of self-contained isolationism ..isn't a candidate
for a standard at all.  If you're writing it yourself, and you're not
using any vendor's equipment (I'll do it all with COTS power and my own
coding) ... I'd suggest that a proprietary solution is just fine for you
(that's not meant as sarcasm ...I'm honoring the motivation of being
independent of someone else's development cycles).

On 4/2/12 4:43 PM, "Jon Hudson" <[email-masked]> wrote:

>> Because I do not want to buy, install and operate network equipment
>>from vendors even if this is interoperable across N vendors and rubber
>>stamped by IETF.
>> 
>>>-

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 02 Apr 2012 23:43:13 +0200

Hi Ken,

I knew someone will misinterpret it.

Where do you see in my message that I proposing isolated solution ? 
Where do you see that I am against standard based service NNI ? BGP is a 
perfect candidate for such NNI interface too. I like BGP or XMPP 
extension proposal. Do you think that standards based solutions are 
possible only to be build and delivered by few vendors ? I think those 
times are over ....

I specifically said that I would like to have a solution which does not 
require to depend on hardware vendors which offer software + hardware 
bundles. Doing encap/decap in OVS on hypervisor completely does not mean 
that I am going to focus on my own "isolated" proprietary control plane 
solution. That very wrong interpretation completely opposite to the real 
goals.

Contrary NVO3 could standardize a control plane solution which does not 
result in locking customers to vendors. That's the point.

Best,
R.

> On 4/2/12 4:43 PM, "Jon Hudson"<[email-masked]>  wrote:
>
>>
>> Bingo
>>
>> On Apr 2, 2012, at 1:34 PM, Robert Raszuk<[email-masked]>  wrote:
>>
>>>

---

From: "Yves Hertoghs (yhertogh)" <[email-masked]>
Date: Tue, 3 Apr 2012 14:28:28 +0200

And lets not forget the hybrid case: NVO3 should support the use case of
connectivity of VM's connected to a virtual switch to servers or network
appliances connected to a 'real' switch.  The control plane for host to
location mapping should be the same for all three cases:
* real switch to real switch
* virtual switch to virtual switch
* real to virtual switch

Yves

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Robert Raszuk
Sent: Monday, April 02, 2012 23:43
To: Ken Gray
Cc: [email-masked]; [email-masked]; Ali Sajassi (sajassi); Jon Hudson
Subject: Re: [nvo3] Response to some comments on IS-IS VPLS

Hi Ken,

Best,
R.

> The description below, of self-contained isolationism ..isn't a 
> candidate for a standard at all.  If you're writing it yourself, and 
> you're not using any vendor's equipment (I'll do it all with COTS 
> power and my own
> coding) ... I'd suggest that a proprietary solution is just fine for 
> you (that's not meant as sarcasm ...I'm honoring the motivation of 
> being independent of someone else's development cycles).
>
>
>
>>> It is not only about cost savings, velocity about enhancement 
>>> delivery speed by vendor, but also about service differentiation 
>>> between my network and competition.
>>>
>>> Best,
>>> R.
>>>
>>>> Hi Robert,
>>>>
>>>> e.g.,, VM1/VLAN1 an VM2/VLAN1 are mapped to the same L2VPN. Why do

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 03 Apr 2012 16:33:52 +0200

Yves,

Use case is to make sure the connectivity can be achieved in all 3 below 
cases - no doubt.

However it seems to me like clear mistake to mandate one control plane 
to fit all. I can interwork with BGP control plane or with LISP for that 
matter just fine and still program my OVSes or switches with the control 
plane of my choice so end points would inter-operate just fine.

Best,
R.

> The control plane for host to

---

From: sajassi <[email-masked]>
Date: Tue, 03 Apr 2012 17:09:28 -0700

Hi Robert,

Is this NTT strategy for both their SPDC and MSDC ?

BTW, in case of SPDC, if the connectivity among DCs needs to span across
different ASes, how do you plan to accommodate that?

Cheers,
Ali

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 04 Apr 2012 11:33:55 +0200

Hi Ali,

> different ASes, how do you plan to accommodate that?

There are many choices for such interconnect today. Both regarding 
interconnect between your own ASes as well as between your 
partners/customers own DCs.

The interconnect signalling can be realized on multiple levels: 
application level (network just provides IP connectivity), service level 
(APIs between your orchestration tools), network level (VPN like service 
with well defined NNI).

I see you and Kireeti for obvious reasons are pushing for BGP based 
network level interconnect standard. I think interconnect standard at 
application level or service level could be much more attractive from 
NVO3 pov. Network could be left alone assuming IP connectivity is there 
any to any (including native multicast if needed :).

As I said I have nothing against BGP in itself - it is very simple 
protocol and very easy to operate. The showstopper agianst BGP is that 
my hosts do not run it even if I would introduce hierarchy of RRs to 
deal with session scaling. If those with BGP implementations commit to 
open source it and submit to all major linux distributions we could 
perhaps start conversation about BGP. XMPP is an alternative too as 
proposed by Pedro.

Best,
R.