Subject: Review Request: draft-hardie-bounded-longest-match-05.txt

From: Alex Zinin <[email-masked]>
Date: Tue, 18 May 2004 15:03:38 -0700

Folks-

 I've received a request to progress draft-hardie-bounded-longest-match-05.txt,
 "Bounding Longest Match", to the INFORMATIONAL RFC status as an individual
 submission.

 To ensure proper IETF community review, I am soliciting comments on this
 document. Please send your comments to the [email-masked] mailing
 list by June 1st, 2004.

 The document is available at:
  http://www.ietf.org/internet-drafts/draft-hardie-bounded-longest-match-05.txt

 The abstract of the document:

   Some ASes currently use length-based filters to manage the size of
   the routing table they use and propagate.  This draft explores an
   alternative to length-based filters which allows for more automatic
   configuration and which provides for better redundancy.

   Rather than use a filter, this draft proposes a method of modifying
   the BGP longest match algorithm by setting a bound on the prefix
   lengths eligible for preference.  A bound would operate on long
   prefixes when covering route announcements are available; in certain
   circumstances it would cause a router to prefer an aggregate over a
   more specific route announcement.

-- 
Alex
IETF RTG Area co-Director
http://www.psg.com/~zinin/

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 24 May 2004 11:59:09 -0400

I've covered document nits off-list.  I have some concerns which I would
like the broader routing-discussion to consider along with the authors.

NO_EXPORT solves the problem about controlling distribution, but
it also overloads an existing signalling mechanism.  I have some
concerns that it would cause NO_INSTALL to also be used in some
spots it wasn't meant for.  Could we get some clarification on how
we're meant to distinguish NO_EXPORT for bounded longest match
vs. generic policy uses?

The mechanism has some of the issues that other forms of aggregation
have.  If you configure an aggregate and use AS-SET based aggregation
rules, you are presuming anyone who is an aggregate contributor
gets all of the more specifics.  This is, I believe, generally true
for brief aggregation rules as well.

So, in this case, if you have a somehwat contrived situation:

	    D
	    |
    A ----- B ----- C
    |               |
    +---------------+

A has 10/8

D has 10.0.1/24

B declines to gives A transit to D directly.  (Does not export 10.0.1/24 to A)

C thus receives:
10/8 A
10/8 B A
10.0.1.24 B D

Applying the rules for bounded longest match, we never send our
less specific contributor, A, the longer route.  Thus we deny
him reachability to D.

This is admittedly a "it hurts to do this, don't do that", but 
unlike configured aggregation, we have no way to make sure
that the less specific route gets more specifics.  We can't configure
the aggregate contributors to only be sent to those we know contributed
to it - we're prevented from even getting the more specific at all.

This might be solvable if C sends overlapping routes to less specific
contributors - i.e. instead of using NO_EXPORT, only send the
more specifics to those who are sending us overlapping routes.

This now means we would have to muck in our adj-rib-out as well
as adj-rib-in.

Is this a show-stopper?  Don't know.  But it's also reasonably complicated.

And I'm not sure if this really saves us much that good configured
policy wouldn't do in the first place.

The base BGP specification has also had rules in there for some time
about not basing the decision for what you do based on the presence
or absence of other routes.  When weird things like this are in the
spec, it often implies one of two things:

o This is dangerous, but it's up to you to figure out why
o This isn't dangerous, it just generates churn.
o The authors couldn't come to consensus and were brushing this issue
  under the carpet and letting subsequent generations of protocol
  developers trip over them.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 24 May 2004 11:59:09 -0400

D
	    |
    A ----- B ----- C
    |               |
    +---------------+

A has 10/8

D has 10.0.1/24

C thus receives:
10/8 A
10/8 B A
10.0.1.24 B D

-- 
Jeff Haas 
NextHop Technologies

---

From: Russ White <[email-masked]>
Date: Mon, 31 May 2004 08:24:41 -0400 (Eastern Daylight Time)

> NO_EXPORT solves the problem about controlling distribution, but it also
> overloads an existing signalling mechanism.  I have some concerns that it
> would cause NO_INSTALL to also be used in some spots it wasn't meant for.
> Could we get some clarification on how we're meant to distinguish
> NO_EXPORT for bounded longest match vs. generic policy uses?

We could define a new community, but we were trying to avoid doing so in
the case where one exists that already does what we want. When this draft
was first published, there was a new community involved, and we removed it
because of feedback.... :-)

> rules, you are presuming anyone who is an aggregate contributor gets all
> of the more specifics.  This is, I believe, generally true for brief
> aggregation rules as well.

This is true for aggregation in general, I believe.

> Applying the rules for bounded longest match, we never send our less
> specific contributor, A, the longer route.  Thus we deny him reachability
> to D.
>
> This is admittedly a "it hurts to do this, don't do that", but unlike
> configured aggregation, we have no way to make sure that the less
> specific route gets more specifics.  We can't configure the aggregate
> contributors to only be sent to those we know contributed to it - we're
> prevented from even getting the more specific at all.

Two points:

-- How would we solve this with manually configured aggregation? By
configuring an exception to that aggregation, correct? If C is aware of the
problem, and manually configures an exception to the aggregation to work
around B's policy no direct transit for D to A, then C could also manually
configure an exception list for longest match bounding, accomplishing the
same thing. The configuration for the two should be the same.

-- How does C know about this problem? If we inject another hop between A
and C, C isn't the direct upstream for either A or D, and thus has no
interest in fixing it by working around B's policies, correct? This isn't a
problem with bounding the longest match, in other words, it's a problem
with differing local policies (aggregation and no direct transit) in
conflict with one another, really. The only real solution here is to
disallow aggregation.

> contributors - i.e. instead of using NO_EXPORT, only send the more
> specifics to those who are sending us overlapping routes.

In other words, if any peer is sending you any component of a longer
prefix, then always send them prefixes within the same block of addresses.
This is, as you point out, very complex, and it's a solution to a policy
problem, not a routing problem, per se. Of course, if we are going to incur
the complexity of these rules for all aggregation, in the BGP base spec, to
solve the problem with general aggregation, then we could just ride on that
rule change in this draft. <hehe>

IMHO, there are no more difficulties with bounding the longest match than
any other filtering or aggregation mechanism (C could also be filtering the
longer match at its border with A, simply because they don't want to accept
prefixes of that length, or because they don't like one of the communities
set on the prefix as they've received it, or for any other reason).

As for NO_INSTALL, it's really an optimization, rather than anything else,
so it's more local policy rather than something required/etc (?).... Can
you expand on the types of specific rules you'd like to see?

:-)

Russ

__________________________________
[email-masked] CCIE <>< Grace Alone