Subject: [Idr] I-D Action: draft-ietf-idr-aspath-orf-10.txt

From: [email-masked]
Date: Mon, 06 Jul 2015 07:10:17 -0700

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/

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 10 Jul 2015 17:01:11 -0400

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, [email-masked] wrote:
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Randy Bush <[email-masked]>
Date: Fri, 10 Jul 2015 14:22:10 -0700

> I must admit to being somewhat dismayed by seeing this draft resurrected.

what gets me is the threat model.  you can trust me to tell you what you
can trust from me.

randy

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 13 Jul 2015 15:42:13 -0400

> what gets me is the threat model.  you can trust me to tell you what you

There's perhaps an amusing element of "trust, but verify" to ORFs.  In
theory, they may be generated by your inbound policy sent out as an ORF.
This doesn't mean you shut off your inbound policy, just that you hope that
by pushing it outward you have to do less work.

-- Jeff

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 13 Jul 2015 15:54:20 -0400

> by pushing it outward you have to do less work.

... and you can argue that the cost to the sending router ends up being low, nil or even negative, making it a win-win. This is because, while on the one hand the sending router has to evaluate extra policy, on the other hand it may construct and transmit fewer updates. Of course whether this ends up being borne out in practice depends on details of the implementation and the contents of the Loc-RIB and the ORFs.

--John

---

From: Randy Bush <[email-masked]>
Date: Mon, 13 Jul 2015 13:42:19 -0700

> There's perhaps an amusing element of "trust, but verify" to ORFs.

as the recipient, how do i verify in a fashion, and at a cost, that does
not essentially obviate the orf data?

randy