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
