Subject: Re: [nvo3] call for adoption: draft-lasserre-nvo3-framework-02

From: "LASSERRE, MARC (MARC)" <[email-masked]>
Date: Mon, 2 Jul 2012 14:50:27 +0200

Eric,

Thanks. I'm fine with this proposal.
I will remove the limitiations listed in the introduction.
The introduction will be revised to be as follows:

Introduction

   This document provides a framework for Data Center Network
   Virtualization over L3 tunnels. This framework is intended to aid in
   standardizing protocols and mechanisms to support large scale
   network virtualization for data centers.

   Several IETF drafts relate to the use of overlay networks for data
   centers.

   [NVOPS] defines the rationale for using overlay networks in order to
   build large data center networks. The use of virtualization leads to
   a very large number of communication domains and end systems to cope
   with.

   [OVCPREQ] describes the requirements for a control plane protocol
   required by overlay border nodes to exchange overlay mappings.

   This document provides reference models and functional components of
   data center overlay networks as well as a discussion of technical
   issues that have to be addressed in the design of standards and
   mechanisms for large scale data centers.

Marc

________________________________
From: Eric Gray [mailto:[email-masked]]
Sent: Friday, June 29, 2012 9:43 PM
To: LASSERRE, MARC (MARC)
Cc: [email-masked]
Subject: Re: [nvo3] call for adoption: draft-lasserre-nvo3-framework-02

Marc,

    Let's not try to make something hard out of this.

    Janos suggested that certain statements made in your draft are not particularly
true (or applicable) if existing standard capabilties have been deployed.

    You responded (paraphrasing) that - while this is true - there are networks where
these capabilities are not part of the layer-2 deployment, and there are customers
who would prefer a layer-3 solution.

    So far, I have no gripe with this.

    However, Joel points out that the current wording makes it appear that the driving
justification for doing this work in layr-3 is that existing layer-2 standards/solutions
won't work.  He further points out that this is not consistent with your own admission
that there are well-known layer-2 standards/solutions that address the limitations you
list.

    Apparently, it was not your intent to make it sound this way.

    Without going line by line through the introduction, the general changes required
to bring what you are saying back into alignment with what we all apparently agree
is the case are relatively obvious and simple.

1) The simplest change would be to remove the statements about layer-2 limitations
    as Janos has suggested.  I think we all understand why perhaps this is not the
    way you want to go.  Fine.
2) If you are going to list the limitations that you now list, you need to make it clear
    these are "perceived" limitations based on currently deployed layer-2 networking
    technology, in some networks.
3) If one of the key reasons why we want to define a layer-3 solution is that there is
    a demand from customers for a layer-3 solution, simply say that rather than giving
    inaccurate second-hand information about "perceived" reasons for this preference
    based on out-of-date layer-2 deployments.

    Does this help?

--
Eric

---

From: <[email-masked]>
Date: Mon, 2 Jul 2012 13:19:12 +0000

Hi all,

This is good: the right place to explain the motivation for NVO3 really 
should be the problem statement draft, since the framework draft 
essentially aims at framing the terminology and spelling out the concepts.

Now, it can be useful to document the limitations (both the real and the 
perceived ones) of Ethernet that contributed to motivate people to seek 
an overlay solution. Reflecting this requires looking at what is most 
largely deployed ; this is the intent for some people when they say 
"Ethernet". For some others "Ethernet" is an 802.1-wildcard, including 
more recent, less used improvements.  I think that a reasonable approach 
would be to avoid "Ethernet" as an ambiguous label, and word motivation 
about NVO3 that relate to Ethernet, in terms of specific pieces of 
Ethernet, e.g. 802.1q.

-Thomas

LASSERRE, MARC (MARC) a écrit :
> *Introduction*
>     ------------------------------------------------------------------------
>     *From:* Eric Gray [mailto:[email-masked]]
>     *Sent:* Friday, June 29, 2012 9:43 PM
>     *To:* LASSERRE, MARC (MARC)
>     *Cc:* [email-masked]
>     *Subject:* Re: [nvo3] call for adoption:
>     draft-lasserre-nvo3-framework-02
>
>     Marc,
>     technology, /*in some networks*/.
>     a demand from customers for a layer-3 solution, simply say
>     /*that*/ rather than giving
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: David Allan I <[email-masked]>
Date: Mon, 2 Jul 2012 14:55:42 -0400

Hi Thomas:

As the latest edition of 802.1Q (2011) embodies most recent amendments .1ad, .1ag., .1ah etc.) , that is not really going to help. And referring to an older edition will simply perpetuate the problem...folks will not get the subtlety....

As for the etiquette of crapping on another SDO's older technology... I have issue with that as this is really marketing not technology. It does not pass the sniff test.

Cheers
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, July 02, 2012 6:19 AM
To: [email-masked]
Subject: Re: [nvo3] call for adoption: draft-lasserre-nvo3-framework-02 / limitations of "Ethernet"

Hi all,

This is good: the right place to explain the motivation for NVO3 really should be the problem statement draft, since the framework draft essentially aims at framing the terminology and spelling out the concepts.

Now, it can be useful to document the limitations (both the real and the perceived ones) of Ethernet that contributed to motivate people to seek an overlay solution. Reflecting this requires looking at what is most largely deployed ; this is the intent for some people when they say "Ethernet". For some others "Ethernet" is an 802.1-wildcard, including more recent, less used improvements.  I think that a reasonable approach would be to avoid "Ethernet" as an ambiguous label, and word motivation about NVO3 that relate to Ethernet, in terms of specific pieces of Ethernet, e.g. 802.1q.

-Thomas

---

From: <[email-masked]>
Date: Tue, 3 Jul 2012 08:00:38 +0000

Hi Dave,

2012-07-02, David Allan I:
>
> As the latest edition of 802.1Q (2011) embodies most recent
> amendments .1ad, .1ag., .1ah etc.) , that is not really going to
> help. And referring to an older edition will simply perpetuate the
> problem...folks will not get the subtlety....

What would you suggest as a reference to designate plain VLAN tagging, 
which most people refer to as dot1q ?

> As for the etiquette of crapping on another SDO's older technology...
> I have issue with that as this is really marketing not technology. It
> does not pass the sniff test.

For sure documenting the motivations for NVO3 would require keeping it 
factual. It would be hard to do without, for instance, mentioning the 4k 
limits of plain VLAN tagging ; but we can agree this would not equate to 
saying that the 802.1Q 2011 is "crap".

Or we could also choose to not document the motivations...

-Thomas

> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Monday, July 02, 2012 6:19 AM To: [email-masked] Subject: Re:
> [nvo3] call for adoption: draft-lasserre-nvo3-framework-02 /
> limitations of "Ethernet"
>
> Hi all,
>
> This is good: the right place to explain the motivation for NVO3
> really should be the problem statement draft, since the framework
> draft essentially aims at framing the terminology and spelling out
> the concepts.
>
> Now, it can be useful to document the limitations (both the real and
> the perceived ones) of Ethernet that contributed to motivate people
> to seek an overlay solution. Reflecting this requires looking at what
> is most largely deployed ; this is the intent for some people when
> they say "Ethernet". For some others "Ethernet" is an 802.1-wildcard,
> including more recent, less used improvements.  I think that a
> reasonable approach would be to avoid "Ethernet" as an ambiguous
> label, and word motivation about NVO3 that relate to Ethernet, in
> terms of specific pieces of Ethernet, e.g. 802.1q.
>
> -Thomas
>
>
>> Eric, Thanks. I'm fine with this proposal. I will remove the
>> limitiations listed in the introduction. The introduction will be
>> revised to be as follows: *Introduction*
>>
>> Virtualization over L3 tunnels. This framework is intended to aid
>> in standardizing protocols and mechanisms to support large scale
>> [NVOPS] defines the rationale for using overlay networks in order
>> to build large data center networks. The use of virtualization
>> leads to a very large number of communication domains and end
>> systems to cope with. [OVCPREQ] describes the requirements for a
>> control plane protocol required by overlay border nodes to exchange
>> overlay mappings.
>>
>> This document provides reference models and functional components
>> of data center overlay networks as well as a discussion of
>> technical issues that have to be addressed in the design of
>> standards and mechanisms for large scale data centers.
>>
>> Marc
>>
>> *Sent:* Friday, June 29, 2012 9:43 PM *To:* LASSERRE, MARC (MARC)
>> *Cc:* [email-masked] *Subject:* Re: [nvo3] call for adoption:
>> Marc, Let's not try to make something hard out of this. Janos
>> suggested that certain statements made in your draft are not
>> particularly true (or applicable) if existing standard capabilties
>> have been deployed. You responded (paraphrasing) that - while this
>> is true - there are networks where these capabilities are not part
>> of the layer-2 deployment, and there are customers who would prefer
>> a layer-3 solution. So far, I have no gripe with this. However,
>> Joel points out that the current wording makes it appear that the
>> driving justification for doing this work in layr-3 is that
>> existing layer-2 standards/solutions won't work.  He further points
>> out that this is not consistent with your own admission that there
>> are well-known layer-2 standards/solutions that address the
>> limitations you list. Apparently, it was not your intent to make it
>> sound this way. Without going line by line through the
>> introduction, the general changes required to bring what you are
>> saying back into alignment with what we all apparently agree is the
>> case are relatively obvious and simple. 1) The simplest change
>> would be to remove the statements about layer-2 limitations as
>> Janos has suggested.  I think we all understand why perhaps this is
>> not the way you want to go.  Fine. 2) If you are going to list the
>> limitations that you now list, you need to make it clear these are
>> "perceived" limitations based on currently deployed layer-2
>> networking technology, /*in some networks*/. 3) If one of the key
>> reasons why we want to define a layer-3 solution is that there is a
>> demand from customers for a layer-3 solution, simply say /*that*/
>> rather than giving inaccurate second-hand information about
>> "perceived" reasons for this preference based on out-of-date
>> layer-2 deployments. Does this help? -- Eric
>>
>>
>>
>> _______________________________________________ nvo3 mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/nvo3
>
>
>  Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> que les pieces jointes. Les messages electroniques etant susceptibles
> d'alteration, France Telecom - Orange decline toute responsabilite si
> ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should not
> be distributed, used or copied without authorisation. If you have
> received this email in error, please notify the sender and delete
> this message and its attachments. As emails may be altered, France
> Telecom - Orange is not liable for messages that have been modified,
> changed or falsified. Thank you.
>
> _______________________________________________ nvo3 mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/nvo3
>

---

From: David Allan I <[email-masked]>
Date: Tue, 3 Jul 2012 10:09:51 -0400

HI Thomas:

2012-07-02, David Allan I:
>>
>> As the latest edition of 802.1Q (2011) embodies most recent amendments 
>> .1ad, .1ag., .1ah etc.) , that is not really going to help. And 
>> referring to an older edition will simply perpetuate the 

>What would you suggest as a reference to designate plain VLAN tagging, which most people refer to as dot1q ?

Unfortunately there is no obvious reference.

>For sure documenting the motivations for NVO3 would require keeping it factual. It would be hard to do without, for instance, mentioning the 4k limits of >plain VLAN tagging ; but we can agree this would not equate to saying that the 802.1Q 2011 is "crap".

>Or we could also choose to not document the motivations...

I'd prefer the latter. A technology neutral description of the requirements should be sufficient.

Cheers
Dave

> draft essentially aims at framing the terminology and spelling out the 
> concepts.
>
> the perceived ones) of Ethernet that contributed to motivate people to 
> seek an overlay solution. Reflecting this requires looking at what is 
> most largely deployed ; this is the intent for some people when they 
> say "Ethernet". For some others "Ethernet" is an 802.1-wildcard, 
>> standardizing protocols and mechanisms to support large scale network 
>> virtualization for data centers.
>>
>> with. [OVCPREQ] describes the requirements for a control plane 
>> protocol required by overlay border nodes to exchange overlay 
>> mappings.
>>
>> have been deployed. You responded (paraphrasing) that - while this is 
>> true - there are networks where these capabilities are not part of 
>> the layer-2 deployment, and there are customers who would prefer a 
>> layer-3 solution. So far, I have no gripe with this. However, Joel 
>> points out that the current wording makes it appear that the driving 
>> justification for doing this work in layr-3 is that existing layer-2 
>> standards/solutions won't work.  He further points out that this is 
>> not consistent with your own admission that there are well-known 
>> layer-2 standards/solutions that address the limitations you list. 
>> Apparently, it was not your intent to make it sound this way. Without 
>> going line by line through the introduction, the general changes 
>> required to bring what you are saying back into alignment with what 
>> we all apparently agree is the case are relatively obvious and 
>> simple. 1) The simplest change would be to remove the statements 
>> about layer-2 limitations as Janos has suggested.  I think we all 
>> understand why perhaps this is not the way you want to go.  Fine. 2) 
>> If you are going to list the limitations that you now list, you need 
>> to make it clear these are "perceived" limitations based on currently 
>> deployed layer-2 networking technology, /*in some networks*/. 3) If 
>> one of the key reasons why we want to define a layer-3 solution is 
>> that there is a demand from customers for a layer-3 solution, simply 
>> say /*that*/ rather than giving inaccurate second-hand information 
>> about "perceived" reasons for this preference based on out-of-date
> ______________________________________________________________________
> ___________________________________________________
>
> received this email in error, please notify the sender and delete this 
> message and its attachments. As emails may be altered, France Telecom 
> - Orange is not liable for messages that have been modified, changed 
> or falsified. Thank you.
>

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Anoop Ghanwani <[email-masked]>
Date: Wed, 25 Jul 2012 17:17:50 -0700

> Unfortunately there is no obvious reference.

You could use C-VLAN bridge as defined in 802.1Q-2011.  That would
be pretty unambiguous.

Anoop