On Mon, 16 Oct 2006 12:48:57 +0100 (IST)
Paul Jakma <Paul.Jakma at Sun.COM> wrote:

[...]
> b): Have
>       - services pass routing info directly to RIB
>         - using something very akin to PF_ROUTE
>           (if not PF_ROUTE over Unix socket ;) ).
>       - services pass service information to NWAM
>       - define some kind of policy language for NWAM
>         to communicate policy to RIB, but only in terms
>         of service IDs, interfaces, nexthops.
> 
>       [service]<---(NWAM service/config IPC)--->[NWAM]
>           |                                       |
>           |(RIB IPC)                              |(policy)
>           |                                       |
>           |--------->[RIB]<-----------------------|
>                        |
>                        |
>                     [kernel]
> 
> c): Store all information in the RIB
>       - services pass everything to RIB
>       - NWAM describes policy in full to RIB
>       - RIB applies
> 
>       [service]<--------(NWAM config)----[NWAM]
>          |                                 |
>          | (extensible service IPC)        | (policy, full)
>          |                                 |
>          |------------------>[RIB]<--------|
> 
> In our discussions last week, some favoured a, some b. c was suggested 
> here prior to that discussion.
> 
> There isn't a clear winner, but personally I favour 'b', because:
> 
> - We could start converting services to update routing information to
>    the RIB (rather than kernel) independently of the NWAM work (e.g. in
>    advance of, or in parallel with).
>    - the IPC could simply be PF_ROUTE messages, with mild extension, but
>      inter-process over AF_UNIX, thus requiring very few changes to
>      services.

This actually seems to describe c since the service would need to be
changed to talk to both nwam and the rib for b.  With c this
conversation is independent of nwam in that you could change the
services to dump all the info to the rib which could then apply
a static or null policy until nwam comes along to program it with
something different.

> - The policy language between NWAM and RIB would be fairly easy.

My question below is really how this is different between b and c.

> 
> Insight / opinion would be appreciated!

One aspect of c I like better is that the services only need to talk to
the rib.

Can you describe in more detail the difference between b's:

>       - define some kind of policy language for NWAM
>         to communicate policy to RIB, but only in terms
>         of service IDs, interfaces, nexthops.

and c's:

>       - NWAM describes policy in full to RIB

                        mph

> 
> --paulj
> _______________________________________________
> nwam-discuss mailing list
> nwam-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/nwam-discuss

Reply via email to