Why don't Joel and you have a Vulcan mind meld?

Yours irrespectively,

John

From: Aldrin Isaac [mailto:[email protected]]
Sent: Thursday, September 20, 2012 6:15 AM
To: John E Drake
Cc: Kireeti Kompella; Thomas Nadeau; [email protected]; Balus, Florin Stelian 
(Florin); Joel M. Halpern
Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane

Ok.  But from a use case perspective it's inter working.  Plus I can't change 
my use case slides at this point for today's use cases presentation.


On Thursday, September 20, 2012, John E Drake wrote:
Aldrin,

That's what I thought but Joel seemed adamant.  I am happy to use either term.

Yours irrespectively,

John

From: Aldrin Isaac 
[mailto:[email protected]<javascript:_e(%7b%7d,%20'cvml',%20'[email protected]');>]
Sent: Thursday, September 20, 2012 5:57 AM
To: John E Drake
Cc: Kireeti Kompella; Thomas Nadeau; 
[email protected]<javascript:_e(%7b%7d,%20'cvml',%20'[email protected]');>; Balus, 
Florin Stelian (Florin); Joel M. Halpern
Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane



Generically when we discuss the need for different forms of NVE to communicate, 
wouldnt we describe that as a need to interwork them?

On Thursday, September 20, 2012, John E Drake wrote:

I had an offline discussion with Joel and he suggests using the term 
'encapsulation selection' rather than 'interworking'

Yours irrespectively,

John

> -----Original Message-----
> From: Kireeti Kompella [mailto:[email protected]]
> Sent: Wednesday, September 19, 2012 5:47 PM
> To: Thomas Nadeau
> Cc: Kireeti Kompella; Balus, Florin Stelian (Florin); John E Drake;
> Joel M. Halpern; [email protected]<mailto:[email protected]>
> Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane
>
> Hi Tom,
>
> On Sep 19, 2012, at 4:17 PM, Thomas Nadeau 
> <[email protected]<mailto:[email protected]>>
> wrote:
>
> >
> > On Sep 19, 2012:11:28 AM, at 11:28 AM, "Balus, Florin Stelian
> (Florin)" 
> <[email protected]<mailto:[email protected]>> 
> wrote:
> >
> >> John,
> >> I think more details need to be added here. What happens if one PE
> advertises nvgre encap while the other advertises only vxlan? Do you
> allow asymmetric encapsulations?
> >> What if one NVE supports all 3 which one is chosen, advertised? Just
> a few examples....
> >
> >     That is just not how data centers are built today so that is
> unlikely to happen in the wild. With that in mind, this is an
> interesting corner case that we should handle just in case something is
> misconfigured or someone in the future decides to build such a DC.
>
> As I've said, I like this draft.  However, "interworking" is fraught
> with misinterpretations and pitfalls, and perhaps at this stage
> distracts from other more pressing concerns.
>
> Might I suggest the following reworking of Section 4:
>
> 4.  Multiple Encapsulations
>
>     The Tunnel Encapsulation attribute enables a single control plane
>     to oversee a number of different data plane encapsulations.  This
> can
>     manifest itself in several ways:
>
>     a) a data center may use a single common encapsulation for all
> EVIs, but
>          different data centers may make independent choices.
>     b) within a single data center, a given EVI may use a single
>          encapsulation, but different EVIs may choose different
> encapsulations.
>     c) a single EVI may use multiple encapsulations, one for each PE-PE
> pair,
>          and maybe even use a different encapsulation in each
> direction.
>
>     Going from (a) to (c ) increases generality, but also increases
> complexity.
>     The initial focus will be on (a) and (b); further details for (c )
> will be added if
>     there is sufficient interest.
>
>     In all cases, a PE within a given EVI knows which encapsulations
> other
>     PEs in that EVI support, and, when sending unicast traffic, it MUST
> choose
>     one of the encapsulations advertised by the egress PE.
>
>     For case (c ), an ingress PE that uses shared multicast trees for
> sending
>     Broadcast and Multicast traffic must maintain distinct trees for
> each
>     different encapsulation type.  Further details will be given in a
> future version.
>
>     The topic of interworking encapsulations and "gateway" functions
> will also be
>     addressed in a future version.
>
>
>
> Kireeti.
>
> >     --Tom
> >
> >
> >> Thanks,
> >> Florin
> >>
> >> On Sep 19, 2012, at 9:04 AM, John E Drake 
> >> <[email protected]<mailto:[email protected]>>
> wrote:
> >>
> >>> Joel,
> >>>
> >>> From section 4, the section you referenced in your note below:
> >>>
> >>> "Note that an ingress PE must use the data plane encapsulation
> specified by a given egress PE in the subject MAC Advertisement or Per
> EVI Ethernet AD route when sending a packet to that PE.  Further, an
> ingress node that uses shared multicast trees for sending Broadcast and
> Multicast traffic must maintain distinct trees for each different
> encapsulation type."
> >>>
> >>> Aldrin also recast this into English in his reply to Lucy:
> >>>
> >>> "The imported E-VPN route will determine what the next hop entry in
> the EVI will look like -- whether it will have encapsulation A or
> encapsulation B.  That is determined by the sender of t
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3

Reply via email to