Hooray, and thanks Peter for this work! Without any consideration of whether I agree with you, I *really* appreciate this work to abstract the functional discussion into something that can be debated in terms of requirements and architectures without recourse to endless debates about whose putative protocol solution is prettiest.
I hope the list is able to work with Peter's starting point to enhance it, add detail, and make changes as necessary. Cheers, Adrian > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > AshwoodsmithPeter > Sent: 20 April 2012 22:26 > 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
