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 protected]; 'Kireeti Kompella'; [email protected] 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 protected]; 'Kireeti Kompella'; > [email protected] > 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 protected]; 'Kireeti Kompella'; > [email protected] > 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 protected] [mailto:[email protected]] 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 protected]; 'Kireeti > Kompella'; > > [email protected] > > 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 protected] > > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
