[Idr] draft-keyur-bgp-enhanced-route-refresh-01

[John Leslie <[e-mail]>]

Susan Hares <[e-mail]> wrote:
> 
> The authors request that: 
> 
> draft-keyur-bgp-enhanced-route-refresh-00
> 
> is accepted as a working group item.
> 
> This starts a two week call for adoption. It will end on 11/25/10. 

   I must admit to some reservations about proceeding this way in
extending route-refresh.

   Plain-Old Route-Refresh [RFC 2918] is designed to avoid storing
all routes-as-advertised from a peer. (I haven't paid much attention
to it, being uninterested in programming routers with "insufficent"
memory.)

   The Introduction of draft-keyur... speaks of "consistency
validations"; so I assume that is what drives this work. (I must
admit I don't worry about these much, and when forced to worry I
generally try for a graceful restart -- hardly an elegant solution.)
It might help for some of us to give examples of consistency issues
that would lead to using this tool...

   Regardless, I'd rather see the re-advertisement(s) be out-of-band
from the usual UPDATEs; and if we're enhancing, I'd like to be able
to request smaller blocks of re-advertisement.

   I'd also like to make the out-of-band (re)advertisements capable
of things which have become interesting in the last ten years, such
as alternate routes; and I'd dearly love for (re)advertisements to
be capable of end-running things which now call for session-reset
(or at least "treat-as-withdraw"). This really _does_ seem achievable
to me.

   I'd welcome questions on any of the stuff I'm asking for: but the
"end-run session-reset" is such an obvious question that I'll treat
it briefly in this email:

   The proposal currently suggesting "treat-as-withdraw" instead of
session-reset calls for blindly withdrawing "junk" NLRI. I'd like
to be able to respond (instead) with a "request-readvertisement
because I couldn't make sense of this" flavor of route-refresh,
listing only the CIDR block which I would otherwise treat-as-withdraw.
The offending peer could reasonably re-advertise in simpler form. In
the meantime, I know the peer has claimed to be able to reach that
block, so I needn't discard the route if I have none other; but I'd
want to prefer an alternative "likely" to be more trustworthy; and
of course I'd want to "eventually" disincent the "bad" route more...

   While facing the "junk" route, I know I can't be sure of actual
AS_PATH length, or even whether a routing loop may exist; so using
it entails "some" risk -- it might even prove necessary to rate-limit
traffic using it, though that is an implementation decision, not a
protocol issue.

   If asked to re-advertise a "junk" route, it would be reasonable
to advertise it at a disincentive to reflect "plausible" guesses
at what my peer couldn't decode. Alternatively, I could advertise
a withdraw to say I can't be bothered. So long as these are "out-of-
band" of the usual UPDATEs, there need be no confusion.

   In any case, passing the "I couldn't make sense of this" message
to the maintainers of the code for your router would be an appropriate
way to start resolving the actual issue. (Actually, passing it to
_both_ sender code-maintainers and receiver code-maintainers would
help, though IMHO "be conservative in what you send" works better
than "be liberal in what you accept"...)

--
John Leslie <[e-mail]>