[Idr] Comments on draft-ietf-idr-aspath-orf-10.txt

[Jeffrey Haas <[e-mail]>]

I must admit to being somewhat dismayed by seeing this draft resurrected.
It's been a while since this draft has been discussed, so I'll fully list my
concerns:

The ORF mechanism is very heavy weight.  Once the ORF has been updated, a
full route-refresh is required in order to apply its changes.  Contrast this
to the lighter weight incremental updates done by RT-Constrain.

ORFs are AFI/SAFI specific.  AS_PATH filters are often address family
agnostic.  This means we not only burn a large part of our capabilities
potentially for the union of all AFI/SAFI to be exchanged.  (ext-opt-param
addresses this point).  But it does mean that we need to exchange
potentially the full set of AS_PATH ORFs redundantly, stretching out any
reconfiguration.

ORFs were originally designed to limit incoming resource impact by pushing
one router's import filters into another router's export path.  Many routers
attempt to optimize outbound route queueing through peer-groups and ORFs
inherently make this messier.  The same issue does hold for RT-Constrain as
well, but I'll argue regex is more costly. :-)



Editorial comments:
Rather than hexadecimal string, I'd suggest either byte string or OCTET
string.  (The latter will be familiar to the SNMP folk.)  

The length field seems to imply that it's a bit-length field.  I'm not sure
this makes sense; it probably should be bytes and thus "trailing bits" would
be irrelevant.

For the anchoring description, it's unclear to me what anchoring vs.
non-anchoring mean based on the examples.  Is the intent to say that the
tokens '^' and '$' are available to anchor the regex?

For the collating element, is the intent to say that the space character is
matched by the '.' token when Bit 1 is 0?  Or is the intent of the two
options to indicate whether or not the '.' token represents a integer
character vs. an integer string?

The section on regular expresses is extremely incomplete and is need of
significant expansion:
- How are route AS_PATHs canonicalized?  I.e. single spaces between AS
  numbers?
- Are AS segment types represented in the canonicalized form?
- When AS segment types are canonicalized, is there any intersection with
  standard regex operators vs. the AS_PATH canonicalized string?  E.g. '[]'
  is used for AS_SET representation in some implementations.
- How are 4-byte ASes canonicalized?  asplain? (See RFC 5396)
- For Bit2 - [] - is the implication that we're doing integer character
  range matching or integer string range matching?  Do we support the NOT
  range, i.e. [^0]?
- Is regex alternation, i.e. '|', permitted?  
- Is grouping, i.e. '()', permitted?  Does it conflict with canonicalized
  output?  What about backreferences?
- What about ranges, e.g. "1 2{2,4} 3"?

What the encoding is for the string?  US-ASCII?  If not and a multi-byte
character set is used, how does this mechanism behave when there's an
encoding failure?  What happens if a character outside the accepted set is
included?

Nit: It looks like an I2NSF draft's XML was used for this document.  I'm
sure it'll be better next time. :-)

While I'm sure we could eventually address all of the technical issues in
the draft, I'd much rather see it be retired and removed from the charter.
It's a very clunky hammer.  If there's a use case for it, let's discuss that
and see if something else fits better.

-- Jeff

On Mon, Jul 06, 2015 at 07:10:17AM -0700, [e-mail] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the Inter-Domain Routing Working Group of the IETF.
> 
>         Title           : Analysis of Existing work for I2NSF
>         Authors         : Susan Hares
>                           Keyur Patel
> 	Filename        : draft-ietf-idr-aspath-orf-10.txt
> 	Pages           : 7
> 	Date            : 2015-07-05
> 
> Abstract:
>    This document defines a new Outbound Router Filter type for BGP,
>    termed "Aspath Outbound Route Filter", that can be used to perform
>    aspath based route filtering.  This ORF-type supports aspath based
>    route filtering as well as regular expression based matching, for
>    address groups.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-idr-aspath-orf/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-idr-aspath-orf-10
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-aspath-orf-10
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr