From: PamSri <[email-masked]>
Date: Thu, 15 Aug 2002 07:30:53 -0700 (PDT)

I really dont get it. This draft hinges on a very
vague concept : "An INFORM message may be sent to
inform a peer of an error condition which is not
serious enough to warrant the reset of the BGP peering
session."

This can be interpreted in N number of ways by
different vendor. Secondly if the draft wants to deal
the situations explicitly described with INFORM i
think the existing protocol has enough tools to handle
it in other ways and more efficiently. There is
absolutely no reason why a new message should be
introduced. The vagueness of the concept has a
potential to create enough confusion among different
implementations.

sri

Manav Bhatia writes:

> I don't think any of the current implementations out
there in the
> field update their Hold Timer/Keep Alive timer based
on messages
> other than UPDATEs/KEEPALIVEs. But I propose that we
must start
> doing so.

The drawbacks of such change are clear: introduction
of
interoperability issues, need for "migration", etc...

What exactly are the advantages... ? i fail to see
any.

> There can be issues in interoperatability between
two
> implementations ..  one of which supports the above
extension and
> the other one not. For the migration purposes an
interim solution
> can be for an implementation to provide a knob which
switches this
> feature ON and OFF till all the other
implementations adhere to this
> standard.

Pedro.

__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com