some more thoughts on ipv6 objects syntax

[Marc Blanchet <]

- just want to inject (;-)) some thoughts on the definition of the new 
rpslng objects.
- if we want to include multiple address families in the future , then I 
think we should keep in mind that:
 + peering is done using an IP protocol: either IPv4 or IPv6.  (Another IP 
protocol is far, but you never know... ;-)))
 + next_hop/peers could only be either IPv4 or IPv6.
 + addresses/routes/... are of all kinds: ipv4, ipv6, multicast, vpn, 
optical, ...

So I think we should keep this in mind in the new definition of objects:
- whenever there is peering/next_hop info, only two IP protocols are 
defined, so I would suggest to have different object names (or different 
tag names depending on the case) and this is not a problem of scaling, 
since we only have two IP protocols.
- whenever there is address info, then we should not define new names for 
the objects, but have some form of address-family added tag that identify 
the address-family before the actual address or prefix, with the default 
(implicit) being IPv4. In this case, this would be additional words 
(address-family <address-family>) on the current objects.

Also, since we only have right now BGP as the EGP protocol, but there is 
some ideas/work underway to define a new EGP protocol, then we should keep 
the objects syntax generic enough, not using the specifics of BGP.

Having this idea in mind (and taking the comments from Mark and Bart),
here is my 2 cents on the syntax.

Comments and bashing are welcome...

Marc.


---------------
address-family
---------------
address-family possible values, others to be defined:
 ipv4   (implying unicast)
 ipv6   (implying unicast)
 ipv4-multicast
 ipv6-multicast

To keep the examples short for the moment, the examples below are pnly for 
IPv4 and IPv6.
However, this is easily generalized to any address family based on the 
previous paragraph.

---------------
route
---------------

route: address-family <address-family> <address-prefix>

address-family <address-family>  is optional. if not present, ipv4 
(unicast) is implied.

examples (only for IPv4 and IPv6, [ipv4|ipv6]-multicast could be added):

route: 128.9.0.0/16
origin: AS226

route: address-family ipv6 3ffe:ffff::/32
origin: AS123

---------------
route-set
---------------
route-set: <object-name>
members: address-family <address-family> <address-prefix>

address-family <address-family>  is optional. if not present, ipv4 
(unicast) is implied.

examples (only for IPv4 and IPv6, [ipv4|ipv6]-multicast could be added):

route-set: rs-foo
members: 128.9.0.0/16, 128.9.0.0/24

route-set: rs-bar
members: 128.7.0.0/16, rs-foo

route-set: rs-foooo
members: address-family ipv6 3ffe:ffff::/32, address-family ipv6 2001:0410::/29

route-set: rs-bar
members: 5.0.0.0/8^+, 30.0.0.0/8^24-32

route-set: rs-barbar
members: address-family ipv6 3ffe:ffff::/32^+


---------------
import
---------------
Since import/export includes some peering info, we will define a new one: 
import6.
however, the routing info is based on an address-family spec.

which gives:

import6: from <AS> <ipv6address> at <ipv6address> accept { address-family 
<address-family> <prefix }

address-family <address-family>  is optional. if not present, ipv4 
(unicast) is implied.


If one uses routing protocols (OSPF, BGP), then same tags are used, since 
it is implicit depending on the
 import or import6. Unless a new version/special case of the routing 
protocol is necessary to specify.

import: from AS2 7.7.7.2 at 7.7.7.1 accept { 128.9.0.0/16 }
import: from AS2 7.7.7.2 at 7.7.7.1 accept { address-family 2001::/16 }

import6: from AS2 3ffe:ffff::1 at 3ffe:ffff::2 accept {address-family ipv6 
2001::/16 }
import6: from AS2 3ffe:ffff::1 at 3ffe:ffff::2 accept {128.9.0.0/16 }

---------------
export
---------------
see import: i.e. export6 is defined, similar syntax.


---------------
default
---------------
see import: i.e. default6 is defined, similar syntax.

---------------
filters
---------------
whenever there is a routing info, you add "address-family <address-family>" 
before the prefix.


---------------
---------------
Since the "address-family" maybe long to type, we could shorten it to "af".


-------------
Marc Blanchet
Viagenie
http://www.viagenie.qc.ca
tel: +1-418-656-9254 x225
-------------
IPv6 easy connectivity: http://www.freenet6.net
RFC/W3C/IANA searchable repository: http://www.normos.org
-------------