Re: initial draft to bootstrap some discussions

[Mark Prior <]

At 3:58 PM -0400 18/10/01, Florent Parent wrote:
> Nothing specific in mind, but I'm looking if we can specify the same
> rules in IPv6 and IPv4:
>
> Retaking your example:
>
>  import: protocol STATIC into BGP4
>        from AS2764
>        accept AS2764:RS-PROVIDER^0-30
>
> In IPv6, would that be equivalent to the following (abstraction made for
> the prefix length values)? :
>
>  import: protocol IPv6 into BGP4
>        from AS2764
>        accept AS2764:RS-PROVIDER^0-30
>
> Seems that we loose the fact that we wanted to inject static routes only.
> Should the dictionary be extended to specify IPv6 to the protocol values ?
> (OSPF6, RIP6, STATIC6, ...)
>
> That was why I previously mentionned that an extra keyword may be needed:
>
>  import: address-family IPv6 protocol STATIC into BGP4
>        from AS2764
>        accept AS2764:RS-PROVIDER^0-30
>
> Keep in mind that I may fail to see something obvious here. But I can
> learn ;-)
OK that makes sense to me although maybe you can claim that the rule 
is largely address family neutral (although ^0-30 wouldn't mean the 
same thing in IPv6).
I think you have convinced me that adding an optional "address-family 
[ IPv4 | IPv6 ]" construct would be better. Default to IPv4 to avoid 
confusing existing software?

Hopefully you will have guessed by now that I favour orthogonal 
constructs so I would like to minimise any additional objects and 
minimise any additions to existing objects. Therefore I don't much 
like the idea of a STATIC6 but might be able to be cope with OSPF6 
and RIP6 if someone can persuade me that they are needed. If you 
include an address family construct then I would doubt being more 
specific with the IGPs unless the IPv6 versions have features not 
available in the IPv4 ones.

I also think that the smarts should be in the software rather than 
the person reading the policy so if software processing a route 
object understands IPv4 and IPv6 format addresses then I would prefer 
that to duplicating the object. This obviously could cause issues 
with existing software if it is "surprised" by IPv6 addresses 
appearing in route sets along with IPv4 addresses but maybe that just 
means we need to go through a transition process again (like the RIPE 
181 to RPSL transition).

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.

Mark.

--