Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification

[Job Snijders <[e-mail]>]

Hi Jeff,

On Mon, Mar 20, 2017 at 03:44:14PM -0400, Jeffrey Haas wrote:
> > Furthermore, shouldn't the "Hard Reset" be called "Really Really
> > Really Reset"? I am skeptical whether the principles of graceful
> > restart should be applied to the notification mechanism. In
> > https://tools.ietf.org/html/draft-iops-grow-bgp-session-culling-00 we are
> > describing a procedure that strongly relies on the currently
> > understood semantics of expiration of BGP Hold Timers and the
> > Administrative Shutdown: "STOP sending traffic".
> 
> I haven't yet read this draft, so take my further comments with that under
> consideration.

ack. Please read the draft. We may have a fundamental problem on our
hands here.

> > I find it hard to reconcile how we can have both "My control-plane
> > temporarily going away, but keep sending traffic" and "data-plane is
> > broken, bgp subsequently dies, don't send traffic". The exact failure
> > scenario which triggers the expiration of the BGP Hold Timers cannot be
> > known at OPEN when the capabilities are exchanged. The GR NOTIFICATION
> > seems to distort the congruency between data-plane and control-plane.

1/ To emphasize the congruency issue here: BGP Hold Timer expiration
often (from the Operator's perspective) an unplanned event. BGP Hold
Timers usually expire because there is an issue with the lower layer
network. If there is an issue with the lower layer network, we should
not continue to forward traffic over that path. If I understand
draft-ietf-idr-bgp-gr-notification correctly, that is what would happen
if both sides through capabilities negotation understand they both
support draft-ietf-idr-bgp-gr-notification.

"make before break" or "ignore this break" are doable when events are
planned, but this draft touches upon scenarios which happen without
planning from the operator's side, where we should be careful with our
assumptions about why a Hold Timer expired.

> > Perhaps there should be an implementation guideline which encourages
> > vendors to by default, disable this mechanism on non-RFC3021/RFC6164
> > links?
> > 
> > Has draft-idr-bgp-gr-notification been vetted in the wild? What were
> > the results and under which circumstances is the mechanism useful?
> > Am I missing something?
> 
> The non-obvious connection is it's a requirement of
> draft-uttaro-idr-bgp-persistence (long-lived graceful restart).
> There's code shipping for this feature.  I *believe* that it's another
> vendor as well, but can't confirm from memory.  
> 
> There has been some discussion that LLGR needs to be resurrected from
> zombie draft state.

2/ So draft-uttaro-idr-bgp-persistence is zombie from IETF perspective,
but there is shipping code, so in order to resurrect
draft-uttaro-idr-bgp-persistence properly (and finish the project?),
draft-ietf-idr-bgp-gr-notification needs to move forward, is that the
chain of events?

3/ If I may ask, why isn't BGP Cease NOTIFICATION message subcode 4
"Administrative Reset" used to perform the 'hard reset' function, and
isn't subcode 9 (the suggested value) requested as a new feature called
'soft reset'? This way we don't break people's preconceptions about what
it means to type in "clear neighbor 1.2.3.4"..

By declaring "subcode 9" to be a hard clear, it appears to me the
meaning of 'Administrative Reset (subcode 4)' is redefined, and
redefining existing constructs might not be an easy task.

Kind regards,

Job