Re: Graceful restart comment

[Jeffrey Haas <[e-mail]>]

On Mon, Apr 29, 2002 at 03:04:41PM -0700, Pedro Roque Marques wrote:
> There have been several incidents in the past related to information
> that was propagated incorrectly and/or crashed the receivers... do you
> mind providing a pointer to the specific incident that you want to
> refer to... ? also in some of those incidents, the "rumor" explanation
> tends to sometimes differ from reality.

IDR list, approximately last week of June 2001.  Subject of
"Re: RFC 3065, confeds.."

In this particular case, the rumor was "private as's were killing
peering sessions".  In reality, confederation AS segments were 
leaking outside of a confederation boundary due to someone's bug,
propagating across the entire Internet, and killing the peering
session of some implementations that chose to read the specification
as saying "if you're not a confederation peer, I should never see
confederation segments from you".

> So, if you detect that your peer is sending you semantically incorrect
> information shouldn't you discard all information that the peer sent
> you ?

In some cases, no.  The confed case above is one example.  Another
example would be an ORIGIN of value 4 or higher.

> If the peer is leaking you bad attributes of some kind how do you know
> which attributes to accept... ?

That is the challenge.

> The tradeoff here is that while by droping the session one may be
> rejecting NLRI that would otherwise have a valid path, by resseting it
> one makes sure that you don't accept information that may poison other
> valid routes. In pratice i believe that the worse incidents that we
> have faced have been the ones related to poison information... thus my
> preference to err on the side of reseting the session.

I would tend to agree with the exception of the fact that stuff
from "far away" that is propagated may kill your session with your
peer, just because they chose to propagate it.

Discarding bad PDU's blackholes some reachability for you.  Killing
your peering session blackholes it all.

> > RFC 2858, section 6, paragraph 1. :-)
> 
> Which suggests that one 'may' zap the other guy... imho, one should do
> it if the routers support capability negociation.

If one doesn't support dynamic capabilities, one should probably
drop the entire peering session.  Otherwise you start discarding
routes and you may not know why - exactly the scenario you were
worried about.

> imho, the best way to keep OAM people happy is to make things fail in
> a detectable and most predictable way... having an information msg hit
> the logs somewhere while you are propagating bogus information would
> be an unfriendly thing to do.

The point is that one should discard the reachability that is questionable
and not propagate it.

> However pesonally i'm very sceptic of the informational message
> concept...

The big motivator is the ability to tell your peer that they're
doing something you don't like without dropping the peering session.

>   Pedro.

-- 
Jeff Haas 
NextHop Technologies