RE: initial draft to bootstrap some discussions

[Florent Parent <]

Hi Bart,

I haven't finished reading/digesting it, but a quick note that you should
look at rfc2622 instead of rfc2280, since the latter is obseleted. You
will find that filter-set, peering-set, ... are defined in 2622.

Get back on your work later today. Good work!

Florent.

Bart.Peirens@localhost wrote:

> 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.
> >
> >
>

-- 
Florent Parent
Viagénie inc.  http://www.viagenie.qc.ca
+1.418.656.9254 x 227