RE: initial draft to bootstrap some discussions

[Mark Prior <]

At 8:25 PM +0200 19/10/01, Peirens, Bart wrote:
>  >
> >  I will have to leave commenting in detail on Bart's email to tomorrow
> >  but just a quick comment while I here :-)
> >
> >  As you may have guessed I don't like the suggestions for adding
> >  attributes to the route object to support multicast (mandatory or
> >  optional). I don't really see the need for it. If you are going to
> >  treat some routes differently then I would have expected the user to
> >  create a route set to mark the objects that need special treatment.
> >  For example if you have a peer you want to announce a subset of
> >  routes as multicast routes then I would have expected an autnum
> >  fragment such as
> >
> >  export: to AS1
> > 	action nlri=multicast
> > 	announce RS-MULTICAST
> >  export: to AS1
> > 	action nlri=unicast
> > 	announce RS-ROUTES
> >
> >  where RS-MULTICAST is a route set containing the multicast routes and
> >  RS-ROUTES a similar set for unicast routes.
> yes, this is one of the possible alternative ways to describe such things,
>  others would using a filter-set (in case you want to describe a more
>  generic policy in the aut-num object without having to specify routes)
>  It's probably not exactly want you want if you interpret it with the
> current
>  described standard. (you're actually rewriting routes above, not filtering)
Well in fact if I was doing this I would be using an import statement 
and injecting the static route into BGP with the appropriate NLRI 
instead.

> another example like above could for example be:
>
> filter-set: AS1::FLTR-MCAST
> filter: nlri(multicast)  #shortcut for nlri.contains(multicast)
>
> aut-num: AS1
> export: to AS2
>      announce AS1:AS-CUSTOMERS AND AS1:FLTR-MCAST
How popular are filter sets?

> you can always create route-sets specific for unicast/multicast prefixes
>  but nothing in it actually would specify that they are actually routes
>  with nlri unicast or multicast. It would be more a remark: line. In
>  other words it would be imposing people to use a less flexible way for
>  defining mixed unicast/multicast policies then for unicast only policies.
I think all of this belongs in an "import: protocol STATIC" statement 
using some filtering mechanism to select the routes that need unicast 
and/or multicast treatment.

Mark.
--