RE: initial draft to bootstrap some discussions

["Peirens, Bart" <]

hi,

alternative  proposal below :)

I'll leave the aut-num part for the end as that's  most  messy. comments on that
 part and suggestions for changes to peering-set and filter-set objects welcome.

multicast  vs ipv6:
 while initially  thinking  of  using the same way of documenting these later
 investigation  showed  that this  might   not be desirable. A clear example
 problem case would be the route: object changes described  below. As such
 the proposal covers different ways for fixing the v6  and the mcast  problem.
 Attention has been  taken  for backwards  compatibility as we have  to assume
 lots of current tools rely on the current format. However  the RPSL spec has
 notes on things  like  unrecognized  attributes /options which should be ignored by 
 existing tools (or warnings  printed)

the information of concern we document in the objects can be of:
- data exchanged over sessions: (prefixes)
- session information: (bgp session endpoints, tunnels)
- policy: (nlri negotiation on sessions, nlri based filtering)


"route:" object:
----------------
- mcast:
  when doing  multicast the same or different  routes are originated by a BGP
  speaker for  unicast/multicasts and  announced with a  different within a
  different  AFI when peers  have negotiated for this. However as the primary
  key of a route: object if  the  advertised  prefix (and  origin) which
  _can_ and typically  are  the same  for unicast and multicast we require
  the ability to  or:
  - create a different  object type (undesirable and would not make  sense 
    wrt to some other route: attributes like rev-srv)
  - have a way  to document  in the  same  route: object unicast only,
    multicast only or  unicast/multicast prefixes.
  as such the proposal  would  be  for  an additional attribute. If we do
  not want to make it a  mandatory one and still be able to describe a 
   multicast  only route in a positive way we might even need two.

   proposal with mandatory  attribute  which   can have  multiple  instances:
   route: 10.0.0.0/8
   afi: ipv4-unicast
   afi: ipv4-multicast

   having  a  default  in absence of making  the attribute  mandatory would
   require you to describe mcasts  only  routes like:  
   route: 10.0.0.0/8
   afi: no-ipv4-multicast
   afi: ipv4-multicast

   proposal without mandatory  attributes (but  two new  ones)
   route: 10.0.0.0/8
   unicast: yes|no
   multicast: yes|no

   where we can define a default  of 'unicast: yes' when the attribute is 
   missing for backwards compatibility.

   aggr-mtd:, holes:,  aggr-bndry: for be  different for the nlri unicast
    and nlri  multicast route with the same address-prefix. Apart from
    holes: this is probably not a too  big concern. As all these attributes
    can appear more then once  in the  same object it could be handled by a
    extension of the info these  attributes can contain.

- ipv6:
  the best way to do this with backwards compatibility for  existing 
  tools/clients would be a 'route6:' object and is in line with the
  current database design  I guess (e.g. inetnum <->inet6num)
  both above frameworks for multicast can be added to a route6 object as
  well.

  components:, export-comps: and holes: could  in the  route6: definition  refer
     to their v6 datatype counterparts for simplicity and backwards  compatibility
     then.  (<filter> specification)

  inject: would again be non-backwards compatible here so we could have;
     inject: at <router-expression> action next-hop = <ipv4-addr>; upon static

   <router-expression> is not  documented  with a typedef in rfc2280 and
     it's current  description  would be  v6  compliant.   Database
     implementations  might  require  slight  changes  to allow ipv6 
     addresses as well however.
---
from rfc2280:
	<router-expression> is an expression
	over router IP addresses and DNS names using operators AND, OR, and
	NOT. The DNS name can only be used if there is an inet-rtr object for
	that name that binds the name to IP addresses.  This form identifies
	all the peerings between any local router in <router-expression> to
	any of their peer routers in the ASes in <as-expression>.  If
	<router-expression> is not specified, it defaults to all routers of
	the local AS.
---
    Q:  is RaToolset  currently using this  attribute? (RtConfig)


<intermezzo>
rp-attributes:
--------------
   actions  can  be done  on  rp-attributes:
   following 'rp-attributes:' types defined  in rfc2280 would need some tuning:

	rp-attribute: # next hop router in a static route
              next-hop
              operator=(ipv4_address)       # a router address
              operator=(enum[self])         # router's own address
     => proposal, add a next-hop6 rp-attribute:

  furthermore following  additional rp-attributes: could be considered useful:
    rp-attribute: # IPv6 next hop router in a static route
              next-hop6
              operator=(ipv6_address)       # a router address
              operator=(enum[self])         # router's own address

    rp-attribute: # nlri information
              nlri
              operator=(enum[unicast,multicast])

    not  directly related  to  mcasts or v6 but usefull when updating the  standard anyhow:
    - rp-attribute  for  extended  communities (any  volunteers  for  writing a typedef?)
    - add  'local-as' to the  community_elm typedef
    - 
</intermezzo>

   so now  we can have:

     route: 10.0.0.0/8
     origin: AS64512
     inject: at <router-expression> action next-hop = <ipv4-addr>; upon <condition>

     route6: xxxxx::/xx
     inject:  at <router-expression>  action next-hop6  = <ipv6-addr>; upon <condition>


     when <condition> is not 'STATIC' but HAVE-COMPONENTS {} or EXCLUDE {} it should
     refer to v6 prefixes instead of v4 in the dictionary  description
   

     Q: this  would still allow  bogus actions to be defined  like  setting  a next-hop6
        for a route: if we don't want  to split up the dictionary with two sets of actions
        to make the specification  unambiguous. We could always  stick to a single
        next-hop: rp-attribute but that would give the same problem without a way to
        eventually  specify things in a unambiguous way. [probably not a too big concern]


inet-rtr:
---------
adding a  'if6addr:' attribute  would be advisable here. (again this
  compared  to extending  the ifaddr:  attribute  for backwards compatibility)

currently ifaddr: is  mandatory and multi-valued. In case of ipv6 only
 routers this can be seen as an issue.

Q: would removing the this requirement break anything for backwards compatibility?

proposal is  to make both ifaddr: and  if6addr: optional, multi-valued

if6addr:  would require  a way  to specify  EUI addressing on an interface as well (so just the prefix)

furthermore the current peer: attribute  requires ipv4 information as well, again
  the proposal is to add a peer6: attribute. Note that this would only specify that
  the link to the remote end is using v6 address space, not the information exchanged 
  over it which  can  still be ipv4 or ipv6 just like ipv6 prefixes could be exchanged
  over sessions  established  between v4  endpoint.
a typical peer: attribute straight from the RFC would be:
    peer:     BGP4 192.87.45.195 asno(AS3334), flap_damp()
 the type of information exchanged over this could be specified by using additional
 optional protocol parameters (to be added to dictionary but also used at some
 other places. further discussion  on  possibilities  for this  on the aut-num: object proposal.

note that in a peer6: attribute you want to enforce using a fully specified
 IPv6 address and not  an EUI prefix which could be considered ok as well for
 an if6addr: attribute. As such we will require two different definitions in
 the dictionary  for this. In case  of EUI prefix  you would like to force the mask to /64 however.


wrt  Florent's remark that the ipv6site object contains additional information wrt
 tunnels this could  be added to the inet-rtr specification in some way. ifaddr:
 and ifaddr6: are defined as:

      ifaddr = <ipv4-address> masklen <integer> [action <action>]
      ifaddr6 = <ipv6-address|eui-prefix> masklen <integer> [action <action>]

so some defined action to  contain tunnel information (for both v4 and/or v6 tunneled over v4 or v6)


route-set: class
----------------
rfc2280:
   Attribute    Value                          Type
   route-set    <object-name>                  mandatory, single-valued,
                                               class key
   members      list of <address-prefixes> or  optional, single-valued
                <route-set-names>
   mbrs-by-ref  list of <mntner-names>         optional, single-valued

for backwards compatibility you want a members6: attribute here. This 
  way route-set's could contain both v4 and v6 route.
Q: is there any  part of the rpsl spec which could have  problems with this? 

As route sets can reference eachother or set's with v4 routes  could via 
 the mbrs-by-ref: attribute include sets with v6 routes the only way to
 avoid this would be a different class which I think  is a bit overkill
 but we have  to make  sure we're not breaking things. (e.g. route6-set and RS6-xxxx)

as route-set's do not refer to route objects  but list prefixes  or ranges 
 documenting the unicast/multicast difference  in the existing route: object
 which we keep the same when announcing both  or only one of  nlri 
 unicast/multicast was probably a good choice above.

in  5.3 of rfc2280 it is mentioned  that you can also use an ASN or AS-SET in
 the members line. Keeping  a different members: and members6: attribute still
 allows constructing route-set's with only v4 or v6 prefixes for the  set  this way.


filter-set;
-----------
not part of current RPSL rfc?
to be added to rfc?
XXX stuff missing here

peering-set:
------------
not part of current RPSL rfc?
to be added  to rfc?
peering: attribute info of peering-set discussed in aut-num object

XXX stuff missing here

as-set:  class
--------------
no required changes I can imagine yet!

aut-num: class
--------------
if you managed to read this far, here comes the ugly part:

pointss of  concern:
1) import: / export attributes:
	- requirement to express different policies for ipv4/ipv6 and  multicast (for each bgp4 afi)
		(handle in actions/filters/protocol specification extensions?)
	- requirement to specify ipv6 endpoints as well as ipv4
		(this covers the <peering> definition in rfc2280)
2) default: attribute: can probably be handled by extending  existing 
   attribute,  Q: Rtconfig using  this?
   example problem cases:
   default: to <peering> [action <action>] [networks <filter>]
   default: to AS2 7.7.7.2 at 7.7.7.1
   default: to AS2 networks { 128.9.0.0/16 }
3) additional action specifications required for expressing  policy:
    see also rp-attribute intermezzo above.
4) filter-specifications: additions  for nlri matching  and v6 prefixes required

the problem here is to extend the aut-num spec with breaking backwards
 compatibility as less as possible. As most parts of  rfc2280 which are
 problematic here are other specs like <peering>, <filter>,  etc which
 are used all over in  other objects things are not too trivial.


wrt the protocol mechanisch described below  by Mark the original idea 
in the spec was to specify routing   protocols and not various IP protocols.
 The idea however makes sense and was our original idea for documenting 
  multicast which we discussed with ripe-dbm some months ago.

The proposal would be to add optional options  similar  to the flap_dampen() 
to the BGP4 protocol specification in the dictionary

e.g.
protocol: BGP4
	OPTIONAL  nlri_afi(enum[ipv4-unicast,
					ipv4-multicast,
					ipv6-unicast,
					ipv6-multicast])

 an example option nlri or afi would then allow  constructs like:

aut-num: AS64512
import: protocol BGP4 flap_damp(), afi(ipv4-unicast)
        {
         FROM AS100 accept AS-FOO;
         FROM AS200 accept AS-BAR;
        }
import: protocol BGP4 flap_damp(), afi(ipv4-multicast)
        {
        FROM AS100 accept AS-MCASTFOO;
        FROM AS200 accept AS-MCASTBAR;
        }


currently the aut-num  object spec does not allow to specify the
 protocol options in the import/export line where the inetrtr peer:
 attribute allows for example. This would need to be added on
 the import/export attribute spec thus. (but would again be  ugly as the
 asno() option is again mandatory in the  current  BGP4 protocol definition
  which does not  make sense in this context.)

import protocol <protocol> into <protocol> should be kept for current
 use I think, being redistribution between  protocols. While it's true
 that there is probably little to none public data with this people are
 also using RPSL style databases internally.


this would also allow to use these protocol options in other places where protocol 
 specifications  are used then. e.g.  the component: attribute of the  route: object.


another possible issue in the import/export:  attribute definition
 is the current definition of <peering> in RPSL:
 <peer-as> [<peer-router>] [at <local-router>]

where <peer-router> and <local-router> are currently assumed to
 be v4 addresses by tools/scripts

we could just extend the <peering> definition and potentially break
 things or add a new <peering6> definition  which has <peer-router> 
 and <local-router> defined as v6 address types. This <peering6>
 construct could then be used in a import6/export6 attribute:
 (to specify the transport of the session, not the information
 exchanged over it as in the proposal of florent)

this does still not fix all potential issues  as the <filter>
 specification  of an import/export definition can directly list
 a prefix instead of referring to e.g. a route-set.

I don't have a clean backwards compatible proposal for this yet except
 not  allowing  direct references to v6 prefixes but force  people to
 use route-set's (which tools  would understand and just ignore the
 members6 attributes in it then)


other suggestions welcome.

regards
bart
--


> > I think that you don't need to introduce new attributes (import6,
> > export6) to the autnum object to support IPv6 as there is 
> an existing
> > mechanism which is probably only currently used to inject static
> > routes into BGP.
> >
> > You can just overload the protocol mechanism, ie
> >
> > import: [protocol <protocol1>] [into <protocol2>]
> >             <import-expression>
> >
> > so if you wanted to just specify a rule for IPv6 you could say
> >
> > import: protocol IPv6
> > 	from AS2764
> > 	accept { 2001:210::/35 }
> >
> > omitting the protocol clause would imply any protocol and if you
> > wanted it to just apply to IPv4 you would use "protocol IPv4".
> 
> I like that. I prefer a more flexible (and scalable) way to 
> specify IPv6
> other address families (like what you have here).
> 
> If we overload the protocol field this way, aren't we losing the
> capability of specifying, say "protocol RIP" for IPv6 ?  Would it be
> preferable to add a new optional "address-family" syntax ?
> 
>  import: [address-family <>] [protocol <protocol1>] [into <protocol2>]
>              <import-expression>
> 
> The address-family would be IPv4 by default (backward compatibility).
> 
> > Also I'm not sure you need to go into what defines an address prefix
> > range as it is just the same as for IPv4. All you really need to say
> > is the same constructs apply to IPv6 as well as IPv4. If 
> you spell it
> > out for IPv6 then you run the risk of getting out of sync with the
> > base document.
> 
> Good point. I'll clean that up and maybe keep a few examples instead.
> 
> Thanks Mark.
> 
> Florent.
> 
>