> 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
