Re: [Idr] Re: Last Call: 'Graceful Restart Mechanism for BGP' to Proposed Standard (draft-ietf-idr-restart)

Curtis Villamizar <curtis@occnc.com> Thu, 01 June 2006 17:14 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flqkn-0005BP-DV; Thu, 01 Jun 2006 13:14:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flqkm-0005BH-Gj; Thu, 01 Jun 2006 13:14:36 -0400
Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flqkl-0002QE-6h; Thu, 01 Jun 2006 13:14:36 -0400
Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id k51HKOS5029074; Thu, 1 Jun 2006 13:20:24 -0400 (EDT) (envelope-from curtis@workhorse.brookfield.occnc.com)
Message-Id: <200606011720.k51HKOS5029074@workhorse.brookfield.occnc.com>
To: Pekka Savola <pekkas@netcore.fi>
Subject: Re: [Idr] Re: Last Call: 'Graceful Restart Mechanism for BGP' to Proposed Standard (draft-ietf-idr-restart)
In-reply-to: Your message of "Thu, 01 Jun 2006 18:34:45 +0300." <Pine.LNX.4.64.0606011809380.21619@netcore.fi>
Date: Thu, 01 Jun 2006 13:20:24 -0400
From: Curtis Villamizar <curtis@occnc.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: idr@ietf.org, curtis@faster-light.net, iesg@ietf.org
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: curtis@faster-light.net
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org

In message <Pine.LNX.4.64.0606011809380.21619@netcore.fi>
Pekka Savola writes:
>  
> I personally believe that IETF documents should be useful to 
> non-vendors as well.. and more than just bare bones spec required for 
> interoperability would be useful to have. Given that we already have a 
> section 'Deployment Considerations', it could easily be expanded to 
> include useful information.  Likewise, security considerations would 
> (perhaps in addition to above) need to better discuss the hazards of 
> delayed convergence, i.e., routing packets into a black hole instead 
> of rerouting around the problem.
>  
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


Pekka,

Sorry to trim so much.

The things I pointed out were mostly regarding an alternative to
graceful restart and some of the implication of the various ways of
supporting a spare route processor (one or more).  That sort of thing
does seem beyond the scope of the document.

I do support this document and I don't feel that it needs to be a
review paper on the convergence properties of the various approaches
to handling route processor failure or planned maintenance.  At most
it should briefly describe how it is intended to improve this
situation, which is does in Section 5 "Operation".  Section 7
"Deployment Considerations" points out the transient blackhole or loop
problem if things change.  It is safe to assume that the reader knows
that blackholes and route loops are bad and knows in detail what the
consequences are.  I don't see that omiting an embedded review paper
makes this useful only to vendors unless you consider protocol
specification in general to be of no use to providers or researchers
or anyone but vendors.

Curtis

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr