Subject: Re: [nvo3] NVo3 abstract model

From: AshwoodsmithPeter <[email-masked]>
Date: Wed, 9 May 2012 17:47:34 +0000

Thanks Linda, 

Sorry for the late reply.

Yes you are correct, the model as is incorrectly generalizes away that requirement so they have to be separated which adds a middle group identifier.

Peter

-----Original Message-----
From: Linda Dunbar 
Sent: Monday, April 30, 2012 6:38 PM
To: AshwoodsmithPeter; Stiliadis, Dimitrios (Dimitri); Ivan Pepelnjak; 'Igor Gashinsky'
Cc: 'Thomas Narten'; 'Yakov Rekhter'; [email-masked]; 'Kireeti Kompella'; [email-masked]
Subject: Overlay abstract model

Peter, 

If "id.mid" includes the local VID, the pair of <id.in, global.glob> will be mapped to different "id.mid" under different overlay boundary point ("id.out"). This is due the fact that VID is locally significant. 

Under this circumstance, your Middle<=>Inner (i.e. ARP resolution) has to be different for different Overlay Boundary points. i.e. need an additional attribute: 

	- PUT ( < id.in, group.glob, id.out> , id.mid )
	- GET ( < id.in, group.glob, id.out> ) -> id.mid

Basically there are two different types of "local ID": Your current "global.loc refers to the local identifier facing "underlay network" (like MPLS local TAG).

There is another local group identifier:  (for lack of better name) "group.loc-towards-Host" for local VID or other identifiers facing towards VMs, blade servers, or servers. 

Linda 

> -----Original Message-----
> From: AshwoodsmithPeter
> Sent: Monday, April 30, 2012 8:38 AM
> To: Linda Dunbar; Stiliadis, Dimitrios (Dimitri); Ivan Pepelnjak; 'Igor
> Gashinsky'
> Cc: 'Thomas Narten'; 'Yakov Rekhter'; [email-masked]; 'Kireeti Kompella';
> [email-masked]
> Subject: RE: [nvo3] NVO3 charter 1530UK 12April
> 
> Thanks Linda,
> 
> Actually I was just thinking that the middle identifier id.mid could
> actually include the vid or vid pair so from the models perspective its
> one big identifier or would something 'not work' if its grouped that
> way?
> 
> Peter
> 
> 
> -----Original Message-----
> From: Linda Dunbar
> Sent: Friday, April 27, 2012 5:34 PM
> To: AshwoodsmithPeter; Stiliadis, Dimitrios (Dimitri); Ivan Pepelnjak;
> 'Igor Gashinsky'
> Cc: 'Thomas Narten'; 'Yakov Rekhter'; [email-masked]; 'Kireeti Kompella';
> [email-masked]
> Subject: RE: [nvo3] NVO3 charter 1530UK 12April
> 
> Peter,
> 
> Very good analysis of the needed protocols.
> 
> Is it correct to assume the following?
>   -  "id.in" refers to VM/host's IP address,
>   - "id.mid" refers to VM/host's MAC address,
>   - "id.out" refers to overlay boundary point's IP address,
>   - "group.loc" is the label encoded in the data packet, like NvGRE or
> VxLan's key field, or MPLS ID if MPLS is used,
>   - "group.glob" is the globally unique client id, which can be same as
> "group.loc" if NvGRE or VxLAN encapsulation is used.
> 
> Then, I think we should also introduce the "id.mid.VID", which is the
> local VLAN id or C-VLAN id.
> When hosts or VMs are on hop away from the "overlay boundary point",
> that is when MAC address and c-VLAN is added to the data frame. In
> order to enable more than 4K's client isolation, the c-VLAN has to be
> locally significant.
> The "PUT" action by Overlay boundary point (Hypervisor or ToR) has to
> indicate its local c-VLAN. When the packet reaches to the Overlay
> egress point, the egress node has to change the c-VLAN in the payload
> of the encapsulated data frame to the correct local c-VLAN.
> 
> Linda
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
> > AshwoodsmithPeter
> > Sent: Friday, April 20, 2012 4:26 PM
> > To: Stiliadis, Dimitrios (Dimitri); Ivan Pepelnjak; 'Igor Gashinsky'
> > Cc: 'Thomas Narten'; 'Yakov Rekhter'; [email-masked]; 'Kireeti
> Kompella';
> > [email-masked]
> > Subject: Re: [nvo3] NVO3 charter 1530UK 12April
> >
> >
> > > Let's forget about BGP for a moment, and let's concentrate on
> > > the functionality.
> > > Whatever you want to call it, it is pretty much a
> > > publish/subscribe model
> >
> > Agreed.. Dimitri, in that spirit FWIW here is a crack at a neutral
> > names/no-types/protocols 'model' based on some of the debate so far.
> >
> > 1) We have inner,middle,outer untyped identifiers in the millions.
> >     { id.in, id.mid, id.out}
> >
> > 2) We have global, local untyped names for a group in the 10s of
> > thousands.
> >     { group.glob, group.loc}
> >
> > 3) We have a way to PUT ( <key>, value ) and GET(<key>)->value
> >    pairs and to SUBSCRIBE to changes at all outer addressable
> >    devices that are members of at least one group very quickly.
> PUB/SUB.
> >
> > Here is trival example where inner id's are {a1...c3}, outer
> > id's are {A,B,C} and the middle are am1..
> >
> > b1 -bm1-+                +-- am1 - a1
> >         |                |
> > b2 -bm2-+ B ---------- A +-- am2 - a2
> >         |  \         /   |
> > b3 -bm3-+   \       /    +-- am3 - a3
> >              \     /
> >               \   /
> >                 C
> >              +--+--+
> >              |  |  |
> >            cm1 cm2 cm3
> >              |  |  |
> >             c1 c2  c3
> >
> > 3) Unicast Data Plane model supports encapsulation which is superset
> of:
> >
> >      [id.out] [group.local] [id.mid] [id.in]
> >
> > 4) Multicast is by ? serial unicast only strong requirement?
> > 5) Loop prevention by ? - not discussed
> >
> > 6) Control Plane model supports a superset of:
> >
> >    Membership resolution
> >        - PUT( < id.out, group.glob > , group.loc)
> >        - GET( < id.out, group.glob > ) -> group.loc
> >        - GET (< * , group.glob > ) -> { <group.loc, id.out> .. }
> >
> >    Middle<=>Outer tunnel resolution
> >        - PUT ( < id.mid, group.glob> , id.out )
> >        - GET ( < id.mid, group.glob>) -> id.out
> >
> >    Middle<=>Inner (i.e. ARP resolution)
> >        - PUT ( < id.in, group.glob> , id.mid )
> >        - GET ( < id.in, group.glob> ) -> id.mid
> >
> > Clearly there is lots of interesting stuff to debate without getting
> > into what it looks like with any specific types/protocols and of
> course
> > the gap analysis then take the form of where an existing protocol
> > differs from an agreed 'good' abstract model.
> >
> > Peter Ashwood-Smith
> > _______________________________________________
> > nvo3 mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/nvo3