Re: [GROW] ISC Response to draft-ietf-grow-unique-origin-as

[Leo Bicknell <[e-mail]>]

In a message written on Wed, Sep 28, 2011 at 06:25:47PM -0400, Danny McPherson wrote:
> The timing of your responses is unfortunate, given that this document 
> has been with the RFC Editor for a while now, and essentially just 
> completed AUTH-48 state.  That said, IMO I do not believe your issues, 
> addressed individually below, would materially influence the current 
> content of the document either way.

I agree the timing is unfortunate, but wanted to comment to be on
record that I don't feel this documents the "Best Current Practice",
which I believe is the point of the exercise.  I feel bad when the
industry recommends to the uninformed a method that may not be the
best.

Having read all the back posts I can find, I think I see part of the
disconnect.

There appears to be two kinds of identification at work here.  There
is identifing the Anycast node that is serving a particular customer,
and then there is identifing if the route should be originated from
a particular node.  It is my feeling that more discussion was given
to the second part in the previous reviews of this draft, while my
response focused almost entirely on the first part.

With respect to detecting hijacked routes I think this proposal is
totally backwards.  There have been efforts in the RIR community
to track the origin ASN of a prefix
(https://www.arin.net/policy/proposals/2006_3.html), which only
allow a single origin ASN to be specified.  Research has been done
on inconsistent-origin ASN's with interesting results
(http://www.routeviews.org/papers/nanog_origin.pdf).  Several of
the BGP monitoring services only allow a single origin ASN when
monitoring a route.  The IETF's own documents recommend using a
consistent origin ASN for troubleshooting purposes
(http://www.ietf.org/rfc/rfc4116.txt, section 3.1.2.2).

The document requires N ASN's, where N is the number of "sites"
in the Anycast cloud.  ISC's current method with F-Root requires a
scant N+1 ASN's, using the +1 to be the consistent origin ASN.  This
is far easier to input into many of the tools (listing one origin
ASN, rather than hundreds), and easier to explain to other operators
(if F isn't originated from 3557, it's wrong).

However, I think the most interesting and relevant quote comes out of
http://irl.cs.ucla.edu/papers/originChange.pdf:

  Only the origin itself (UCLA in our example) could easily and
  accurately distinguish be- tween a legitimate origin change and a prefix
  hijack [4].

The fact is there is no way to detect these events without some
knowledge.  You either have to know the list of valid ASN's (likely
only the origator does), or rely on them to publish you the
information.  Given groups like ARIN are now collecting (a single)
origin ASN with a route, there is a source for this data but only
if the origin is consistent.

In terms of advice to someone new to Anycast who wants to set up their
first cloud I think this is actively harmful advice.  They will find
that inconsistent origins do not square with the history of BGP
recommendations, the tools available today, or the expectations of those
on the other end of the phone.  I see no way such a method could be
called Best Current Practice.

Now, with that out of the way we can return to the more end user facing
problem of identifing an anycast node...

[Re point #1]

> In reading your comment, and the recent discussion of 
> draft-anycast-diagnostics.txt on [e-mail] the last couple 
> of days, I do agree that the definition of "node" is perhaps 

The question is entirely how granular the information in the routing
system should be to enable the functionality this draft seeks to
enable.  For instance an ASN may have 100 servers Anycasted internally
with OSPF, that generates a single external route from that ASN
which is Anycasted with other ASN's.  What level of detection is
required to be useful?

[Re point #2]

> The utility of these reports is relative; I consider them of less utility 
> than you, and in fact largely because today prefixes are originated from 
> the same partitioned origin AS (e.g., the F-root model you outline and 
> similar models employed by many others) in multiple locations, and as a
> result routing system information provides no discriminators of utility
> to aid in visibility and diagnosis of routing problems based solely on 
> origin AS and identifiers for various services therein -- I'd prefer active
> data in the routing system providing this indication, hence the 
> recommendations in the draft.

I think before the IETF renders an entire set of reports useless with a
policy change it would be worth at least seeking out some of the users
of those reports and finding out why and how they use them.  I am
disturbed that none of the folks who commented appear to be users of
these reports, and yet are eager to make them useless.

No additional comment on point #3.

[Point #4]

> False.  Additional routes ("paths") for the prefixes in question exist 
> either way in the respective Adj-RIBs-Ins throughout the routing system, 
> as appropriate, and neither model should result in larger DFZ RIB or 
> derived FIB sizes.  

My comment was not about the difference between the model proposed and
the F-Root model, both of which use an ASN per site.  Rather it was
about the difference between both of those models, and a model which
uses just a single origin ASN with no per-site ASN.

I believe in particular if you think about a router with BGP
multi-path enabled either per-site ASN configuration is likely to
lead to increased routes in the RIB.  Since this is a general
recommendation, more folks doing this mean larer RIBS.

[Point #5]

> This isn't aimed at "end users", although ultimately, it is about adding 
> more transparency to service consumers.  As discussed above, service level 
> capabilities should indeed exist for "end users" and clients, I agree.  This
> capability aims to help network operators and others that analyze routing 
> system information to better diagnose issue with a given services and to 
> ideally identify any anomalous or persistently misbehaving elements.

I see many of the arguments for this proposal were that it helped
in diagnostic capabilities.  Yet in all of the GROW archives I have
read so far, and in the RFC itself I do not see a single example
of how this configuration leads to faster/more accurate troubleshooting
than say the F-Root model.  

As I documented at the start of this mail I believe many BGP jockies
will find this quite counter-intuitive, having been taught in classes
and in the IETF's own other BGP documents that inconsistent origin
ASN is bad/dangerous.  If the IETF is going to advice this document,
than things like RFC 4116 should be updated so they don't appear
to conflict.

But really the crux of the failing to me here is the lack of supportave
examples.  I'd love to see an example detailed where this draft makes
some sort of troubleshooting for Joe BGP Jockey easier, most preferably
in the draft itself.  I sure can't see how it would make anything
easier, but perhaps an example would make me turn around on that.  If
this really does a lot of good, examples should be easy to produce.

-- 
Leo Bicknell; E-mail: [e-mail], Phone: [phone]
INOC*DBA *3357*592; Internet Systems Consortium, Inc.  www.isc.org