RE: initial draft to bootstrap some discussions

["Peirens, Bart" <]

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

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

now these could be more considered as 'hacks' on the current attributes
 imho as what they really say is
- how you filter things
- how you rewrite things
- etc..

it does not specify what the protocol negotiates, or what actually lives
 in your routing table of things you originate or have redistributed.
more below:


wrt to your example above I think correct syntax would be more like:

export: to AS1 announce RS-MULTICAST nlri(multicast)
# would match route when it's in the MRIB (but route could also exist in URIB)


export: to AS2 announce RS-MULTICAST nlri == { multicast}
#would only do exact match! if route exist both in URIB and MRIB -> not-announced

export: to AS3 action nlri = {multicast} announce RS-MULTICAST 
#would announce RS-MULTICAST routes and rewrite the nlri to multicast only even
  if original entry only existed in URIB. used when giving mcast connectivity to
  parties without mbgp implementation. syntax above would not announce the route
  with NLRI anymore however but does not look in the MRIB to select what it's announcing!

now all above entries only specify what you announce or filter or rewrite,
 it does not specify what the protocol agrees to the remote end which should
 be a protocol option eventual.

example of a BGP session negotiated for unicast only where updates are 
 rewritten inbound to have nlri unicast/multicast to deliver multicast
 connectivity to parties without working mbgp implementation:

import: protocol BGP4 nlri(ipv4-unicast), flap_damp()
      {
	FROM AS1 import AS1:AS-CUSTOMERS action nlri .= {multicast};
      }

(note that the two nlri's above are different, the first is a
 protocol option, the second a rp-attribute)

typedef: nlri_elm
	   enum[unicast|multicast]
typedef: nlri_list list of nlri_elm

rp-attribute: # BGP nlri attribute
              nlri
              # set to a list of nlri's
              operator={afi_list}
              # append nlri
              operator.=(afi_list)
              append(afi_elm, ...)
              # a filter: true if one of the nlri values is contained
              contains(afi_elm, ...)
              # shortcut to contains: nlri(ipv4-unicast, ...)
              operator()(afi_elm, ...)
              # order independent equality comparison
              operator==(afi_list)

and change the protocol: BGP definition as:

# we need different typedefs to use in route/route6 objects below for
# ipv4/ipv6, not a requirement for the protocol bgp option or nlri rp-attribute.
typedef: afi_ipv4_elm
 	    enum[ipv4-unicast|ipv4-multicast]
typedef: afi_ipv6_elm
 	    enum[ipv6-unicast|ipv6-multicast]
typedef: afi_ipv6_list list of afi_ipv6_elm
typedef: afi_list list of (afi_ipv4_list, afi_ipv6_list)

protocol: BGP4
          # as number of the peer router
          MANDATORY asno(as_number)
          # enable flap damping
          OPTIONAL flap_damp()
          OPTIONAL flap_damp(integer[0,65535],
                             # penalty per flap
                             integer[0,65535],
                             # penalty value for supression
                             integer[0,65535],
                             # penalty value for reuse
                             integer[0,65535],
                             # halflife in secs when up
                             integer[0,65535],
                             # halflife in secs when down
                             integer[0,65535])
                             # maximum penalty
         OPTIONAL nlri(afi_list)


aut-num:    <as-number>
as-name:    <object-name>
import:    from <peering> action <action> accept <filter>
export:    to <peering> action <action> announce <filter>

now as peering: is defined as:
peering: as_expression opt_router_expression opt_router_expression_with_at
| TKN_PRNGNAME

you would not be able to use this in nlri() option in the aut-num
 <peering> part of the import/export attribute but can still use a
 protocol clause around it where you specify BGP options

to use this in a aut-num object you could use something like below 
which I think would be a valid syntax:

import: protocol BGP4 nlri(ipv4-unicast), flap_damp()
      {
	FROM AS200 10.0.0.1 at 10.0.0.2
      ACCEPT AS200:AS-CUSTOMERS
      }

in a inet-rtr object this would look like:
inet-rtr: <..>
local-as: AS100
peer: BGP4 10.0.0.1 asno(AS200), nlri(ipv4-unicast,ipv4-multicast), flap_damp()


with all above we have:
- described what we negotiate to exchange between peers (protocol options)
- what we filter on in/outbound
- what we rewrite in/outbound

but still have not described what we would have internal to the network if
 you look in the routing table. (the origination of the route) which would
 allow to describe some of the above import/export policies in a more simple
 and straightforward way compared to current syntax when that functionality
 was available. (but above would still be required to allow specifying various
 policies)

I think that functionality should still belong in the route: object as such IMHO

with e.g.
Attribute     Value                      Type
   route         <address-prefix>           mandatory, single-valued,
                                            class key
   origin        <as-number>                mandatory, single-valued,
                                            class key
   nlri          <afi_ipv4_list>            optional, multi-valued

and:
   route6        <address-prefix>           mandatory, single-valued,
                                            class key
   origin        <as-number>                mandatory, single-valued,
                                            class key
   nlri          <afi_ipv6_list>            optional, multi-valued


the only problem here would be if you make it a optional attribute and
 assume ipv4-multicast or ipv4-unicast as default it becomes difficult
 to specify a ipv4-multicast or ipv6-multicast only route. As such making
 this a mandatory attribute would make life more easy but less handy for
 people updating database stuff. (a migration of existing objects to add
 'nlri: ipv4-unicast' would be required when this functionality is added
 in a RPSLng server.

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.


bart
--