Subject: Re: draft-hardie-bounded-longest-match-05.txt

From: Geoff Huston <[email-masked]>
Date: Thu, 02 Sep 2004 05:09:20 +1000

I've been requested by one of the routing ADs to forward the following
comment I made some time back on draft-hardie-bounded-longest-match-05.txt 
to this list, as the authors are evidently interested in moving
forward with the draft, and some discussion of the approach would be
helpful.

I had observed:

This is another form of proxy aggregation, where some remote AS
performs stripping of more specifics. There are two general approaches
to proxy aggregation as I understand it:

1 - the aggregating AS performs the actions of stripping out more
    specifics based on local configuration

2 - the aggregating AS performs the actions of stripping out the more
    specifics based on signals from the originating AS.

The Bonaventure and NOPEER approaches are essentially implementations
of approach 2 - where the originating address signals some conditions
that should allow the remote AS to strip out the more specifics.

This draft appears to be an implementation of approach 1 where the
actions of prefix stripping are performed without explicit or implicit
signalling.

Personally I'm not convinced that its a productive direction, as use
of this mechanism will have some impacts on current inter-domain
origin-directed traffic engineering practices that leverage the
behaviour that the more specific is always propagated and always wins
in terms of route precedence with any enclosing aggregate.

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

---

From: Pekka Savola <[email-masked]>
Date: Thu, 2 Sep 2004 08:10:44 +0300 (EEST)

>     specifics based on local configuration
[...]

>From the operational perspective, approach 1 seems like a MUST.  The
operators (at least the responsible ones) *do* want to strip out at
least some of the crap from the announcements they propagate.  
Remember, a lot of those is just misconfiguration at the customer
side..

However, the point I think you're making is whether we should go
forward with protocol specifications which would change this from
"local configuration by the operator" to "automatically implemented by
the vendors, and performed if requested or even by default".  And
unless this would be done by default, it would have of arguable
usefulness as those networks which don't filter more specifics
wouldn't bother to turn this on in any case.

I don't have firm opinion either way on that.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Russ White <[email-masked]>
Date: Thu, 9 Sep 2004 10:08:06 -0400 (Eastern Daylight Time)

> This is another form of proxy aggregation, where some remote AS performs 
> stripping of more specifics. There are two general approaches to proxy 
> aggregation as I understand it:

It could also be termed "intelligent filtering," but we could probably 
discuss all day which is which. :-)

> The Bonaventure and NOPEER approaches are essentially implementations of 
> approach 2 - where the originating address signals some conditions that 
> should allow the remote AS to strip out the more specifics.

The latest version of the draft, which you couldn't know about, since it's 
not published (but it is attached here), actually adds in a third 
community, NO_BOUNDING, allowing the originator to signal that a specific 
route shouldn't be bounded. This essentially turns NO_PEER on its head. 
Rather than making the originator try and understand the topology enough to 
know when their route should be filtered, you can always filter the route 
when it's no longer useful, with the caveat that the originator can 
indicate you shouldn't filter the route even there.

Take a look at the latest, and see if it makes more sense....

:-)

Russ

__________________________________
[email-masked] CCIE <>< Grace Alone
_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 20 Sep 2004 15:07:48 -0400

Russ,

Random comments on the included draft:

> indicate you shouldn't filter the route even there.

Especially in light of the attribution of this feature to me I have
to say that this isn't what I meant at all. :-)

It does address the concern I had brought up, namely that there are
situations where the longer prefix might be inadvertantly filtered
(or simply not received) and thus completely deny reachability.
Those situations should, I believe, always be the case where the
advertiser of a shorter does not receive a necessary longer prefix
that is not in its AS.

(It probably should be noted that paranoid operators will already
have to make exceptions to receive their address space from
an external peer since it should otherwise be filtered.)

My concern with the NO_BOUNDING solution is that we get some of
the proposed redistribution community semantics with a lot more
complexity.  Additionally, we also now have a situation where 
the originator of a prefix has the ability to disable the bounding
(the supposed benefit).

IMO, this proposal has gotten extremely complicated.

Draft notes:

RFC 2119 keyword capitalization needs done.

My last name is mis-spelled. 

Also:

>    may choose not to install this prefix into the local RIB, in order to

I believe you mean FIB here.

-- 
Jeff Haas 
NextHop Technologies

---

From: Russ White <[email-masked]>
Date: Mon, 20 Sep 2004 16:15:32 -0400 (EDT)

> > The latest version of the draft, which you couldn't know about, since
> > it's not published (but it is attached here), actually adds in a third
> > community, NO_BOUNDING, allowing the originator to signal that a
> > specific route shouldn't be bounded. This essentially turns NO_PEER on
> > its head.  Rather than making the originator try and understand the
> > topology enough to know when their route should be filtered, you can
> > always filter the route when it's no longer useful, with the caveat
> > that the originator can indicate you shouldn't filter the route even
> > there.
>
> Especially in light of the attribution of this feature to me I have to
> say that this isn't what I meant at all. :-)

That's good.... I meant to attribute not using a new community to you.

> My concern with the NO_BOUNDING solution is that we get some of the
> proposed redistribution community semantics with a lot more complexity.
> Additionally, we also now have a situation where the originator of a
> prefix has the ability to disable the bounding (the supposed benefit).

The only real added complexity is the intelligence to figure out where to
filter dynamically. The problem with redistribution communities and no_peer
is we're assuming, I think, the end user has some idea of where filtering
is "safe," or rather, won't cause a loss of connectivity, and to
reconfigure things when the network changes so they need to advertise
something beyond their immediate peer, etc.

> IMO, this proposal has gotten extremely complicated.

I actually think it's still pretty simple. Lots of options, but that's
okay. :-)

> RFC 2119 keyword capitalization needs done.

'kay.

> My last name is mis-spelled.

Maybe we weren't talking about you!!!! <hehe> I'll fix this.

> I believe you mean FIB here.

No, it would block installs from the BGP table into the RIB.

:-)

Russ

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 20 Sep 2004 16:50:17 -0400

On Mon, Sep 20, 2004 at 04:15:32PM -0400, Russ White wrote:
> filter dynamically.

The actual problem is probably best solved on the part of the party
providing the bounded longest matching, not the the sending party.
The sending party has no guarantee that their routes wont be filtered
at all - that's up to the arrangements of those operating the Net.

Only the party performing the bounding can determine if, topologically,
there exists situations where not propagating the more specifics
can cause reachability issues.  These issues are, after all, no 
different than when one is using proxy aggregation and filtering
the more specifics.  In that case, you intentionally leak the more
specifics where it is appropriate.

In longest match... this seems to imply you must do this for the
entire Internet.

> The problem with redistribution communities and no_peer

Exactly.  In the case of NO_PEER, I think that's quite reasonable.

In the case of the proposed redistribution communities, the WG's
past issues have been that it implies significant topological knowledge
of the end user of networks beyond their own.

(Personally, I think that for very small AS diameters (<=2) away from the 
party adding those communities, this may be reasonable.)

> No, it would block installs from the BGP table into the RIB.

:   The effect of this community would be for any BGP speaker receiving a
:   prefix with this community set to treat the prefix normally in the
:   BGP bestpath computation, and to forward bestpaths marked as
:   NO_INSTALL to iBGP peers, but to simply fail to install such prefixes
:   in the local routing table.

BOUNDED already says don't export this.

By not installing stuff into the RIB (Adj-Rib-In/Loc-Rib/Adj-Rib-Out),
you're implying that BGP shouldn't pass the routes along to anyone.
(Actually, by not installing it in Adj-Rib-In, you're implying dump
the route as if it never existed.)

I suspect you mean something else, but this definitely doesn't fit
into the abstract RIB model BGP uses.

-- 
Jeff Haas 
NextHop Technologies

---

From: Russ White <[email-masked]>
Date: Mon, 20 Sep 2004 17:03:24 -0400 (EDT)

> > The only real added complexity is the intelligence to figure out where
> > to filter dynamically.
>
> providing the bounded longest matching, not the the sending party. The
> sending party has no guarantee that their routes wont be filtered at all
> - that's up to the arrangements of those operating the Net.
>
> there exists situations where not propagating the more specifics can
> cause reachability issues.  These issues are, after all, no different
> than when one is using proxy aggregation and filtering the more
> specifics.  In that case, you intentionally leak the more specifics where
> it is appropriate.

Correct... That's my impression, as well.

> In longest match... this seems to imply you must do this for the entire
> Internet.

?? :-) It is, I suppose, by definition, all the routes you have in your
local tables.

> party adding those communities, this may be reasonable.)

It depends on the customer. :-)

> (Actually, by not installing it in Adj-Rib-In, you're implying dump the
> route as if it never existed.)
>
> I suspect you mean something else, but this definitely doesn't fit into
> the abstract RIB model BGP uses.

I think the collision is between the formal language of the BGP spec, and
the more informal language most of us actually use. :-) The adj-rib-in,
adj-rib-out, etc, are what I'm calling, collectively, the "BGP tables,"
above. The RIB, is the real RIB, the local routing table built from the
information inserted by all the routing protocols running on the box, and
which the FIB is built from. I think, from BGP's perspective, these are
both the same thing. From a router's perspective, it's the difference
between the routing table and the CEF table, say, or something like that
(depending the acronym you use to say "the forwarding table.").

:-)

Russ

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 20 Sep 2004 17:09:28 -0400

> ?? :-) It is, I suppose, by definition, all the routes you have in your

This seems.... like a very big job.

> (depending the acronym you use to say "the forwarding table.").

Hence why I said "the FIB".  For this to fit into the abstract
model, routes must be installed in all 3 abstract ribs (In, loc-rib, out).

The step you seem to be wanting to step (and which seems to be an
ok idea) is not propagating the route into the FIB and thus affecting
forwarding.

It just occurred to me that this thread is going through routing-discussion
rather than GROW.  While I'd encourage the route leaking issue on
the bounding to remain visible to either of those lists, we can probably
take the draft details off list. :-)

-- 
Jeff Haas 
NextHop Technologies

---

From: Russ White <[email-masked]>
Date: Mon, 20 Sep 2004 17:11:48 -0400 (EDT)

> This seems.... like a very big job.

Not if it's automated?? I would hope not.... No more than any other form of
"normal" filtering.

> The step you seem to be wanting to step (and which seems to be an ok
> idea) is not propagating the route into the FIB and thus affecting
> forwarding.

Correct. I'll change the draft to say "fib" to be in line with the BGP
drafts, rather than with my "common usage."

> It just occurred to me that this thread is going through
> routing-discussion rather than GROW.  While I'd encourage the route
> leaking issue on the bounding to remain visible to either of those lists,
> we can probably take the draft details off list. :-)

Oh, they aren't paying attention, anyway.... <hehe>

:-)

Russ