Re: Graceful restart comment

[Pedro Roque Marques <[e-mail]>]

Jeffrey Haas writes:

> On Mon, Apr 29, 2002 at 01:58:04PM -0700, Pedro Roque Marques wrote:
>> If you have errors in a PDU the best thing to do is to tear down
>> the session not to selectivly ignore bits... if you can't trust
>> your peer to format updates correctly then you can't trust any of
>> the nlri that it has sent you.

> Pedro,

> Turn your wayback machine to the IDR list when we had the leaking
> confederation segments incident killing parts of the Internet. :-)

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.

> The specific circumstances I have in mind are where we have a
> well-formed packet, but the information is semantically incorrect,
> discard the PDU.

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

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

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.

> Can you think of circumstances where your implementation will drop
> an update where it doesn't drop the peering session?

Drop ? nope... not that i can't think of.

>> I can't think of any scenario where it is reasonable to discard
>> packets from the neighbor while maintaining the session up... if
>> your neighbor is sending you packets for an NLRI that it hasn't
>> negociated, chances are that there is something else wrong with it.

> 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.

> Mind you, I don't really have a problem with the portion I just
> cited, but implementing that without having dynamic capabilities

imho, dynamic capabilities introduce much more uncertainty (you can't
know for sure what is enabled on the session anymore) than what their
worth. At least i wouldn't expect people to be changing their NLRI
often enought that this feature will actually be worthwhile vs the
introduced complexity... i.e. imho it fails the KISS criteria.

> nor
> some sort of informational pushback is asking for your OAM people to
> put your head on a plate. :-)

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.

There are no guarantees that indeed the draconian scenario that i'm
suggesting will happen...

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

  Pedro.