Subject: [nvo3] NVO3 Functionality [Was: NVO3 charter 1530UK 12April]

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 20 Apr 2012 22:37:35 +0100

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-masked] [mailto:[email-masked]] On Behalf Of
> AshwoodsmithPeter
> Sent: 20 April 2012 22:26
> To: Stiliadis, Dimitrios (Dimitri); Ivan Pepelnjak; 'Igor Gashinsky'
> Cc: 'Thomas Narten'; 'Yakov Rekhter'; [email-masked]; 'Kireeti Kompella';
> [email-masked]
> 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-masked]
> https://www.ietf.org/mailman/listinfo/nvo3

---

From: AshwoodsmithPeter <[email-masked]>
Date: Sun, 22 Apr 2012 02:37:46 +0000

Thanks Adrian, nice to get some kudos on a Friday. 

I'll be happy to try to edit such a model as the debate proceeds, definitely be good to raise the debate up a level or 3.

Definitely be useful for gap analysis because the existing solution gaps can be expressed against the model, not against each other.

Peter. 

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Friday, April 20, 2012 5:38 PM
To: AshwoodsmithPeter
Cc: [email-masked]
Subject: NVO3 Functionality [Was: NVO3 charter 1530UK 12April]

Cheers,
Adrian

it
then