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
