Subject: [nvo3] enhancing VXLAN/NVGRE vs creating an new encap

From: Lucy yong <[email-masked]>
Date: Mon, 10 Mar 2014 16:32:30 +0000

Hi All,

GROSS brings a lot of attentions in this IETF meeting. VXLAN and NVGRE defects for Network Virtualization Overlay (NVO) technology were extensively discussed on nvo3 mailing list last year (http://www.ietf.org/mail-archive/web/nvo3/current/msg02779.html) and the enhancements on VXLAN and NVGRE for the technology were also proposed in the draft-yong-l3vpn-nvgre-vxlan-encap-03 and draft-ietf-tsvwg-gre-in-udp-00.

If we look at the geneve proposal, it addresses the defects identified in VXLAN and NVGRE for NVO and has the essential key elements required by NVO in the encapsulation header.

Should we enhance VXLAN and NVGRE for NVO technology or create a new encapsulation protocol for NVO? Industry (or major vendors (authors in gross) in NVO) seems prefer the latter choice now. The benefit of the latter is that having one encapsulation protocol for the NVO technology, which is good for both vendors and operators.  The "cons" is that we have a new encapsulation protocol, which is not compliant with either VXLAN or NVGRE.

So the question is should we quickly face out VXLAN and NVGRE with GENEVE and have one encap. for NVO or we live with this pain ( enhance both VXLAN and NVGRE for NVO and use both in NVO).  IMHO: Having two encapsulation semantics for the same technology is not good, the only reason we do it is for the reality. Is this reality not true anymore by seeing the authors in geneve?

What should IETF do for NVO technology development? With current NVO3 WG progress pace, it is not much except discussing the technology and solution pieces on the mailing list.  In the meanwhile, IETF keeps receiving these informational drafts from the industry (precisely, the nvo leader vendors).  Which one will IETF publish as informational?
Does IETF really want working on NVO technology?

Regarding medadata option in geneve header, I'll express my opinion in a separated mail.

Thanks,
Lucy

---

From: "Anton Ivanov (antivano)" <[email-masked]>
Date: Mon, 10 Mar 2014 16:46:01 +0000

Requirements draft? For metadata?

Document id please?

A.

On 10/03/14 16:32, Lucy yong wrote:
Hi All,

Should we enhance VXLAN and NVGRE for NVO technology or create a new encapsulation protocol for NVO? Industry (or major vendors (authors in gross) in NVO) seems prefer the latter choice now. The benefit of the latter is that having one encapsulation protocol for the NVO technology, which is good for both vendors and operators.  The “cons” is that we have a new encapsulation protocol, which is not compliant with either VXLAN or NVGRE.

Regarding medadata option in geneve header, I’ll express my opinion in a separated mail.

Thanks,
Lucy

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

---

From: Lucy yong <[email-masked]>
Date: Mon, 10 Mar 2014 17:04:27 +0000

Sorry, "Gross" in my previous mail means draft-gross-geneve-00.
The metadata is what is described in this draft.

From: nvo3 [mailto:[email-masked]] On Behalf Of Anton Ivanov (antivano)
Sent: Monday, March 10, 2014 11:46 AM
To: [email-masked]
Subject: Re: [nvo3] enhancing VXLAN/NVGRE vs creating an new encap

Document id please?

A.

Thanks,
Lucy

nvo3 mailing list

---

From: "Anton Ivanov (antivano)" <[email-masked]>
Date: Mon, 10 Mar 2014 17:10:16 +0000

On 10/03/14 17:04, Lucy yong wrote:
Sorry, “Gross” in my previous mail means draft-gross-geneve-00.
The metadata is what is described in this draft.

That is a "ready-baked" solution. It is not requirements.

In order to "face off" GRE, VXLAN, Geneve (and L2TPv3 for that matter) you need to set the field.

If you do not set the field by having requirements you can claim anyone being the winner - it stops being an engineering standards process.

A.

From: nvo3 [mailto:[email-masked]] On Behalf Of Anton Ivanov (antivano)
Sent: Monday, March 10, 2014 11:46 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [nvo3] enhancing VXLAN/NVGRE vs creating an new encap

Document id please?

A.

Thanks,
Lucy

nvo3 mailing list

---

From: Sam Aldrin <[email-masked]>
Date: Mon, 10 Mar 2014 10:25:00 -0700

Before one analyses various encapsulations out there, newly proposed or existing ones, there should be a reference or set of requirements to compare with.
I do not see those *new* requirements in the draft-ietf-nvo3-dataplane-requirements-02. 
It would be prudent for the authors of the documents for ‘new’ encap, to identify them in a new ID or propose those to the existing requirements draft.
Till then it is speculation at best.

-sam
On Mar 10, 2014, at 10:10 AM, Anton Ivanov (antivano) <[email-masked]> wrote:

>> [email-masked]
>> [email-masked]
> [email-masked]

---

From: Eric Gray <[email-masked]>
Date: Mon, 10 Mar 2014 18:36:15 +0000

Lucy,

                Thanks for sending this mail.  It contains a lot of useful information.

                My understanding is that, if we decide to use a new encapsulation
- instead of making the simplest changes possible to existing/deployed NVO
encapsulations - we will already be inflicting some degree of pain on the DCN
industry.

                You ask a good question, though, and - to answer it - we would need
a way to determine which approach will inflict the greatest pain.

                The answer seems obvious: living with more than one additional form
of encapsulation (there already exists one standard form of encapsulation for
the L2 case, at least) will result in a cumulative costs that we can clearly expect
to exceed the expected lower cost of only living with one additional encaps.

                With existing deployments, however, the approach of using a single
new encapsulation inflicts a short-term migration cost on those who already
have deployed solutions.

                Previously, this would be viewed as the risk of early deployment of a
non-standard solution.

                As you are probably aware, though, the industry recently went through
a bit of a fiasco because viewing excessive migration costs as the risk accepted
by customers who have deployed a non-standard solution, is not acceptable to
customers any more.

                In this case (for example) while VxLAN and NVGRE are not standards,
they are very well known mechanisms.

                As I understand it, our present predicament is not the result of having
two solutions that don't work; it results from having two solutions that do work.

                So, in reality, isn't it likely that - if we define yet another encapsulation
approach - we may only be increasing the immediate, short-term costs by quite
a lot on the unrealistic (and unverifiable) presumption that everyone will  switch
to it, and we'll end up with 3 additional encapsulations that need to interwork
(effectively increasing the long term costs of the presumed lower-long-term cost
approach such that it is now higher, rather than lower, than the cost of simply
modifying existing/deployed approaches)?

                In other words, isn't it likely that the real alternatives are:

1) minimal modifications to existing approaches - incurs a long-term cost
     associated with having two alternative  additional encapsulations (requiring
     interworking and other complexities) until such time (if ever) when the DCN
     industry settles on one choice and we move on.
2) create a new encapsulation that meets requirements (that must be over and
     above the requirements satisfied by at least the standard components of the
     current deployed solutions) - and assume that the industry will switch over
     to using this lovely new encapsulation, thus avoiding any issues with having
     multiple additional encapsulation solutions.
3) create a new encapsulation that meets requirements - and find out that the
     industry doesn't entirely switch over to the new (read untried and possibly
     immature) encapsulation, existing deployed alternatives are documented in
     some (possibly non-standard) way and we incur the costs associated with
     living with three alternatives additional encapsulations until such time (if ever)
     when the DCN industry settles on fewer (possibly as few as one) choices, and
     we move on.

                And this means that the real answer to your question (which approach
will result in the least pain) depends very much on which of the 2nd and 3rd
alternatives above actually turn out to be the case.

                I suspect the answer is not as cut-and-dried as some may think it is.

                If - as your mail suggests - there really is a willingness among those
who have currently deployed solutions, to switch to a common encapsulation,
it would be very useful if each and every one of them would please tell us so.

--
Eric

From: nvo3 [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Monday, March 10, 2014 12:33 PM
To: [email-masked]; [email-masked]
Subject: [nvo3] enhancing VXLAN/NVGRE vs creating an new encap

Hi All,

Thanks,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Mon, 10 Mar 2014 18:48:13 +0000

From: nvo3 [mailto:[email-masked]] On Behalf Of Anton Ivanov (antivano)
Sent: Monday, March 10, 2014 12:10 PM
To: [email-masked]
Subject: Re: [nvo3] enhancing VXLAN/NVGRE vs creating an new encap

That is a "ready-baked" solution. It is not requirements.
[Lucy] Agree. The draft itself is the solution draft. The requirements for NVO were discussed in nvo3 mail list extensively. Nvo3 data plane requirement doc. is the place to capture the requirements.

In order to "face off" GRE, VXLAN, Geneve (and L2TPv3 for that matter) you need to set the field.
[Lucy] Sorry, it should be "phase off". This is not what I mean. I mean to say, "phase off VXLAN and NVGRE for NVO", not GRE.
Lucy

A.

Document id please?

A.

Thanks,
Lucy

nvo3 mailing list

nvo3 mailing list

---

From: Shahram Davari <[email-masked]>
Date: Mon, 10 Mar 2014 19:01:56 +0000

Hi Lucy,

I am completely against any new encapsulation such as Geneve. We already have 2 deployed solutions, which is more than enough. I think your drafts to enhance them is the best way forward. Especially the VXLAN enhancement looks very practical and in my opinion pain-free since it is backward compatible with L2 over VXLAN.

Thx
Shahram

From: nvo3 [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Monday, March 10, 2014 9:33 AM
To: [email-masked]; [email-masked]
Subject: [nvo3] enhancing VXLAN/NVGRE vs creating an new encap

Hi All,

Thanks,
Lucy

---

From: Tom Herbert <[email-masked]>
Date: Mon, 10 Mar 2014 12:44:58 -0700

>                 If – as your mail suggests – there really is a willingness
> among those
>
I can speak for one with a currently deployed solution, but not for
one which has deployed either vxlan on nvgre. Without any obvious way
to extend then to include security data to validate the vni they are
nonstarters for deployment.

> GROSS brings a lot of attentions in this IETF meeting. VXLAN and NVGRE
> defects for Network Virtualization Overlay (NVO) technology were extensively
> discussed on nvo3 mailing list last year
> (http://www.ietf.org/mail-archive/web/nvo3/current/msg02779.html) and the
> enhancements on VXLAN and NVGRE for the technology were also proposed in the
> draft-yong-l3vpn-nvgre-vxlan-encap-03 and draft-ietf-tsvwg-gre-in-udp-00.
>
>
>
> If we look at the geneve proposal, it addresses the defects identified in
> VXLAN and NVGRE for NVO and has the essential key elements required by NVO
> in the encapsulation header.
>
>
>
> Should we enhance VXLAN and NVGRE for NVO technology or create a new
> encapsulation protocol for NVO? Industry (or major vendors (authors in
> gross) in NVO) seems prefer the latter choice now. The benefit of the latter
> is that having one encapsulation protocol for the NVO technology, which is
> good for both vendors and operators.  The “cons” is that we have a new
> encapsulation protocol, which is not compliant with either VXLAN or NVGRE.
>
>
>
> So the question is should we quickly face out VXLAN and NVGRE with GENEVE
> and have one encap. for NVO or we live with this pain ( enhance both VXLAN
> and NVGRE for NVO and use both in NVO).  IMHO: Having two encapsulation
> semantics for the same technology is not good, the only reason we do it is
> for the reality. Is this reality not true anymore by seeing the authors in
> geneve?
>
>
>
> What should IETF do for NVO technology development? With current NVO3 WG
> progress pace, it is not much except discussing the technology and solution
> pieces on the mailing list.  In the meanwhile, IETF keeps receiving these
> informational drafts from the industry (precisely, the nvo leader vendors).
> Which one will IETF publish as informational?
>

---

From: Lucy yong <[email-masked]>
Date: Mon, 10 Mar 2014 20:37:57 +0000

Hi Shahram,

Thank you for voicing up your opinion. Yes, starting a new encapsulation is a pain for some vendors. Is it not for others? Love to hear feedback on this.

Thanks,
Lucy

From: nvo3 [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Monday, March 10, 2014 2:02 PM
To: Lucy yong; [email-masked]; [email-masked]
Subject: Re: [nvo3] enhancing VXLAN/NVGRE vs creating an new encap

Hi Lucy,

Thx
Shahram

From: nvo3 [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Monday, March 10, 2014 9:33 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [nvo3] enhancing VXLAN/NVGRE vs creating an new encap

Hi All,

Thanks,
Lucy

---

From: Shahram Davari <[email-masked]>
Date: Mon, 10 Mar 2014 20:46:50 +0000

Hi Lucy,

It is often preferred to enhance an implementation than design and test a new one. Also the fact that VXLAN enhancement is backward compatible, means that existing HW can be reused and does not need to be replaced.

Thx
Shahram

From: Lucy yong [mailto:[email-masked]]
Sent: Monday, March 10, 2014 1:38 PM
To: Shahram Davari; [email-masked]; [email-masked]
Subject: RE: enhancing VXLAN/NVGRE vs creating an new encap

Hi Shahram,

Thanks,
Lucy

From: nvo3 [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Monday, March 10, 2014 2:02 PM
To: Lucy yong; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [nvo3] enhancing VXLAN/NVGRE vs creating an new encap

Hi Lucy,

Thx
Shahram

Hi All,

Thanks,
Lucy

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 12 Mar 2014 15:06:32 -0700

I agree. We should be discussing whether or not we need:

	1) yet another encapsulation. 

	2) how/if/why metadata

	Incidentally point 2 is under discussion and part of the proposed architecture in NSC.

	--Tom

---

From: Lucy yong <[email-masked]>
Date: Wed, 12 Mar 2014 22:31:59 +0000

Tom,

Regarding point 2, IMHO, SFC header should be treated as a metadata when it applies to NVO3 because the SFC header essential is to carry some states from ingress NVE to egress NVE to facilitate NVE egress forwarding. But we should not invent an encapsulation to allow passing arbitrary metadata because it defeats the purpose of metadata: pass some dynamic changed states along with packet. Using metadata is an expensive costs, we should only use when it makes sense and have the market value.

SFC header itself may also contain a metadata that is used for service functions (TSs in NVO3), we should distinguish between two.

Regards,
Lucy

From: nvo3 [mailto:[email-masked]] On Behalf Of Thomas Nadeau
Sent: Wednesday, March 12, 2014 5:07 PM
To: Anton Ivanov (antivano)
Cc: [email-masked]
Subject: Re: [nvo3] enhancing VXLAN/NVGRE vs creating an new encap

            2) how/if/why metadata

            --Tom

On Mar 10, 2014:10:10 AM, at 10:10 AM, Anton Ivanov (antivano) <[email-masked]<mailto:[email-masked]>> wrote:

A.

Document id please?

A.

Thanks,
Lucy

nvo3 mailing list

nvo3 mailing list

---

From: "Russ White" <[email-masked]>
Date: Sun, 16 Mar 2014 07:12:27 -0400

>      immature) encapsulation, existing deployed alternatives are
documented
> in
>      living with three alternatives additional encapsulations until such
time (if
> ever)
>      when the DCN industry settles on fewer (possibly as few as one)
choices,
> and

This is, in fact, the most likely result... Vendors would need to remove
support for the old encaps over time, which isn't going to happen so long as
someone is actually using them, which means support will still be in code,
which means new people will start using them, which means... 

There is also a cost in security when it comes to defining new encap types
we often don't consider -- it's one more tunnel type that needs to be
accounted for by middle boxes, network hardening routines, etc. For every
new encap we create, we also create a lot of work in the security world in
tracking vulnerabilities, understanding the semantics of the protocol, etc.

The right answer, IMHO, is to modify, rather than creating a new encap.

:-)

Russ

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 16 Mar 2014 08:48:33 -0700

Decades of experience tells us what Russ says below. Those who choose to ignore are bound to repeat ...

Dino

> On Mar 16, 2014, at 4:12 AM, "Russ White" <[email-masked]> wrote:
> 
>

---

From: Thomas D Nadeau <[email-masked]>
Date: Sun, 16 Mar 2014 12:09:41 -0400

This road is littered with many examples in recent history of new alternatives presenting the dream of "a new encap/protocol will fix everything" such as crldp, PBT and PBB-TE. let's not make this mistake if we can help it...

Tom 

> On Mar 16, 2014, at 11:48, Dino Farinacci <[email-masked]> wrote:
>

---

From: David Allan I <[email-masked]>
Date: Sun, 16 Mar 2014 19:56:35 +0000

The actual examples cited are artifacts of an industry power structure that may not apply in this case, as far as past performance predicting future outcomes....

D

-----Original Message-----
From: nvo3 [mailto:[email-masked]] On Behalf Of Thomas D Nadeau
Sent: Sunday, March 16, 2014 9:10 AM
To: Dino Farinacci
Cc: Russ White; <[email-masked]>; <[email-masked]>; Lucy yong; Eric Gray
Subject: Re: [nvo3] enhancing VXLAN/NVGRE vs creating an new encap

Tom 

>>>    industry doesn't entirely switch over to the new (read untried 
>>> and
>> possibly
>>>    some (possibly non-standard) way and we incur the costs 
>>> associated
>> with
>> This is, in fact, the most likely result... Vendors would need to 
>> remove support for the old encaps over time, which isn't going to 
>> happen so long as someone is actually using them, which means support 
>> will still be in code, which means new people will start using them, which means...
>> 
>> There is also a cost in security when it comes to defining new encap 
>> types we often don't consider -- it's one more tunnel type that needs 
>> to be accounted for by middle boxes, network hardening routines, etc. 
>> For every new encap we create, we also create a lot of work in the 
>> security world in tracking vulnerabilities, understanding the semantics of the protocol, etc.
>>

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 16 Mar 2014 12:59:17 -0700

Maybe the power struggle should not focus so much on WHAT is delivered but HOW it is developed and delivered. 

A thought offered to me recently from a close friend. 

Dino

> On Mar 16, 2014, at 12:56 PM, David Allan I <[email-masked]> wrote:
>

---

From: Thomas D Nadeau <[email-masked]>
Date: Sun, 16 Mar 2014 17:22:33 -0400

that's kind of what you and russ were saying (and I agreeing): iteration, evolution and refinement have often proven better than revolution.

Tom 

> On Mar 16, 2014, at 15:59, Dino Farinacci <[email-masked]> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Sun, 16 Mar 2014 15:24:24 -0700

> that's kind of what you and russ were saying (and I agreeing): iteration, evolution and refinement have often proven better than revolution.
Iteration, evolution, and refinement are key and in fact this is
precisely a core rationale in GUE and geneve. We need the ability to
scale and adapt the data center to changing needs and threats, this is
the requirement. This translates into a requirement for extensible
protocols that we can modify and evolve as needed and in short
turnaround time.

The example that I give in security: what if next week the latest
Snowden revelations expose some security hole in our data center-- if
this hole can be addressed by adding a token to my packets, then I
want to guarantee I retain the capability to do this. It's not
acceptable that I'd have to go back to standards to change this, and
neither is swapping out new hardware just because I extended a
protocol.

I agree that modifying existing protocols would be the best direction
but that is going to require a real proposal which we can measure
against (no one has suggested a reasonable alternative). In lieu of
modifying an existing protocol, developing a a new one based on known
techniques and mechanisms is prudent.

Tom

---

From: Shahram Davari <[email-masked]>
Date: Mon, 17 Mar 2014 01:12:43 +0000

Tom

There are 2 drafts that propose changes to VXLAN and NVGRE. Is there any requirements that is not addressed by those drafts? 

Regards,
Shahram

> On Mar 16, 2014, at 3:24 PM, "Tom Herbert" <[email-masked]> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Sun, 16 Mar 2014 18:51:46 -0700

On Mar 16, 2014 6:12 PM, "Shahram Davari" <[email-masked]> wrote:
>
> Tom
>
> There are 2 drafts that propose changes to VXLAN and NVGRE. Is there any
requirements that is not addressed by those drafts?

Which drafts are you referring to?

> >> that's kind of what you and russ were saying (and I agreeing):
iteration, evolution and refinement have often proven better than
revolution.
> >>> Maybe the power struggle should not focus so much on WHAT is
delivered but HOW it is developed and delivered.
> >>>> The actual examples cited are artifacts of an industry power
structure that may not apply in this case, as far as past performance
predicting future outcomes....
> >>>> This road is littered with many examples in recent history of new
alternatives presenting the dream of "a new encap/protocol will fix
everything" such as crldp, PBT and PBB-TE. let's not make this mistake if
we can help it...
> >>>>>>> 3) create a new encapsulation that meets requirements - and find
out
> >>>>>>> that the

---

From: "Anton Ivanov (antivano)" <[email-masked]>
Date: Mon, 17 Mar 2014 13:10:42 +0000

> protocols that we can modify and evolve as needed and in short

I am sorry to disappoint you, network protocols are not sold in Walmart
in the "disposables" isle.

Standard network protocol's lifetime is > 10 years. Even if we discard
hardware out of the equation, it is a standard it is still >  5 years.

This is a result of economic realities - depreciation periods on
equipment, RFI, RFQs, costs of training staff, developing debugging,
benchmarking and analysis tools.

People adopt standards so that they do not need to reinvest into these
every 6 months. This is why it is called a "standard" and this is what
IETF does as an organization.

> neither is swapping out new hardware just because I extended a

It is a bit difficult to take seriously an example that extends RFC 3514
from one to 128 evil bit as a security measure. Especially against the
class of adversaries you are referring to.

> techniques and mechanisms is prudent.

That is fine. Provided that you do requirements first.

I have yet to see requirements. Sorry - "This extra 128 RFC 3514 bits
will defend us against the [insert agency name]" is not a requirement
(unless it is the first of April of course).

When I see something that has a decent statement of requirements that
does not read like marchitecture we can have a proper engineering
conversation including how many standard engineering input units
(espressos) does it take to implement it.

A.

---

From: AshwoodsmithPeter <[email-masked]>
Date: Tue, 18 Mar 2014 20:32:13 +0000

I agree enhancing rather than inventing new is a good idea. For example CR-LDP did not create a new encapsulation (it is normal MPLS) nor did it create a new control protocol (its LDP) although it did add some TLV's to LDP of course for the ERO and QOS. It was a simple idea with very small code delta over LPD ... ..oh wait .. I guess that's a bad example ;)

As Dave points out politics is far from impotent here, let's not kid ourselves.

Peter

-----Original Message-----
From: nvo3 [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Sunday, March 16, 2014 3:57 PM
To: Thomas D Nadeau; Dino Farinacci
Cc: Russ White; <[email-masked]>; <[email-masked]>; Lucy yong; Eric Gray
Subject: Re: [nvo3] enhancing VXLAN/NVGRE vs creating an new encap

D

-----Original Message-----
From: nvo3 [mailto:[email-masked]] On Behalf Of Thomas D Nadeau
Sent: Sunday, March 16, 2014 9:10 AM
To: Dino Farinacci
Cc: Russ White; <[email-masked]>; <[email-masked]>; Lucy yong; Eric Gray
Subject: Re: [nvo3] enhancing VXLAN/NVGRE vs creating an new encap

Tom

---

From: "Zhou, Han" <[email-masked]>
Date: Wed, 19 Mar 2014 02:41:26 +0000

Hi,

So let's face the reality: how to enhance VXLAN with the scarce space
left in the header? Extend it with optional fields following the
original header? Would it create similar problems of introducing a new
protocol?

If the fixed 8 bytes size is still preferred, would it be better that
the extension proposals co-work together to make the best use of the
header space? E.g. VXLAN-GPE protocol type doesn't really needs 16 bits
for the possible 3 (or more in the future, but not that huge) values.

Best regards,
Han

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 18 Mar 2014 22:26:15 -0700

You don't need more header space for service chaining. 

An EID can identify a service. And you can assign as many as you want to a physical or virtual system. And EIDs could even be IPv6 addresses where there are plenty of bits to encode all sorts if things. 

Dino

> On Mar 18, 2014, at 7:41 PM, "Zhou, Han" <[email-masked]> wrote:
> 
> Hi,
>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 20 Mar 2014 16:59:12 -0700

"People adopt standards so that they do not need to reinvest into these
every 6 months. This is why it is called a "standard" and this is what
IETF does as an organization."

I believe that standards are primarily to ensure interoperability at
certain level among equipment from multiple vendors. Otherwise you may be
quite happy with single-vendor, a.k.a. proprietary, solution.

Regards,
Greg

On Mon, Mar 17, 2014 at 6:10 AM, Anton Ivanov (antivano) <[email-masked]
> wrote: