Re: [Idr] AD Review of draft-ietf-idr-bgp-gr-notification-13

["John G. Scudder" <[e-mail]>]

(as co-author and WG member)

Hi Bruno,

Discussion in line below.

> On Apr 10, 2018, at 4:52 AM, [e-mail] wrote:
> 
> Hi John,
>  
> Thank you for the updated draft.
> In general -14 looks good to me, but I have 2 comments below, and more inline [Bruno] in your email.
>  
> 1)
> In case of Hard Reset “encapsulating” another notification, I had a comment about which Error (sub)Code is to be indicated to the network operator (e.g. in Yang, SNMP, Syslog…) I’m not seeing an answer nor clarification in the draft. (I’m not sure there is a good answer, but I’d prefer a consistent answer from all implementations)

Part of my takeaway from the comments Jeff just sent is that there are limits on how much we can specify in this document since the various management layers that might be used have different semantics and constraints. How about something like this, as a new management considerations section?

"When reporting a hard reset to network management, the error code and subcode reported MUST be CEASE, Hard Reset. If the network management layer in use permits it, the information carried in the Data portion SHOULD be reported as well." 

While it would be nice to tell the management layer that it has to report the encapsulated code and subcode in a useful, structured way, I can't see that as being in-scope for this document.
 
> 2) 
> Following the change introduced, I wish that the meaning of the N bit were slightly clarified: does it enable/disable the gr-notification capability for the subsequent/future event (à la BGP capability) or for the past one (à la GR "F" bit)? More below
>  
> §2:
> "   If a BGP speaker which previously advertised the "N" bit opens a new
>    session without advertising that bit, normal BGP Graceful Restart
>    procedures documented in [RFC4724] apply."
>   
> FYI when first reading this new sentence, I have been wondering whether this was meant as aborting the gr-notification procedures underway (a la "F" bit). Then I tough probably not. If so may be :s/apply/will apply      (or apply from this Open till the next Open; or will apply for subsequent Notification). But really up to you.
>  
> But then section 4.1 is changed with the addition of
> "The sentence "To deal with possible consecutive restarts, a route
>    (from the peer) previously marked as stale MUST be deleted" only
>    applies when the "N" bit has not been exchanged with the peer:"
>   
> Which may be understood as saying that not sending the N bit will result in aborting the gr-notification procedure.

These are good points and underscore the subtlety of the problem. You might recall that we introduced the new text and structure to deal with Alvaro's objection to the previous formulation, which said something to the effect of "if the N bit goes away, you shouldn't use that as a trigger to abort a GR in progress". As you point out, the GR capability has two functions -- to say what actions should be applied to routes from the previous session (or potentially previous sessionS in the case of this draft), and what actions should be applied at the termination of the current session. Trying to cover both of these in a way both clear and precise is proving challenging.

As a practical matter, I almost don't care about whether "a route (from the peer) previously marked as stale MUST be deleted" because the difference would only come into force if there were two or more resets in quick succession, *and* the final one removed the N bit. And even then, the difference in behaviors would necessarily be transient. So this is a very edgy edge case. 

However, of course it's still desirable to be clear, which requires us to decide what exactly we want. It seems to me that a desirable way to spec and implement is that up until the GR capability has been exchanged, sans F bit, the previous F bit based semantics should apply, and after it has been exchanged, the new semantics should apply. What this comes down to is,

- Don't try to retrospectively go back and say "oh because the previous session was reset due to a holdtime expiration, and now I don't have the F bit, I'd better act as though it had been hard reset". 
- Do apply the quoted text to any already-stale detritus of previous sessions.

Perhaps a sufficient clarifying change would be:

OLD:
   If a BGP speaker which previously advertised the "N" bit opens a new
   session without advertising that bit, normal BGP Graceful Restart
   procedures documented in [RFC4724] apply."

NEW:
   If a BGP speaker which previously advertised the "N" bit opens a new
   session without advertising that bit, normal BGP Graceful Restart
   procedures documented in [RFC4724] apply once the session has 
   transitioned into ESTABLISHED state".

Unless there's objection or more discussion I'll update the draft accordingly.

> Especially given that §4 says
> "   When such a BGP speaker has received the "N" bit from its peer, and
>    receives from that peer a BGP NOTIFICATION message other than a Hard
>    Reset, it MUST follow the rules for the Receiving Speaker mentioned
>    in Section 4.1."
>   
> While section 4.1 only explicitly covers "detects termination of the TCP session for a BGP session" which may be understood as only TCP “issues” and not the termination of the BGP session following the reception of a Notification.

Yes, as discussed above, creativity about this clause was largely what the text is trying to prevent.

> From: John G. Scudder [mailto:[e-mail] <mailto:[e-mail]>] 
> Sent: Friday, April 06, 2018 5:16 PM
> To: DECRAENE Bruno IMT/OLN
> Cc: [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; idr@ietf. org; Alvaro Retana
> Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-gr-notification-13
>  
> Hi Bruno,
>  
> I've just posted a -14 which I believe addresses all comments so far (yours and Alvaro's) other than this one, for which some discussion below.
>  
> On Apr 6, 2018, at 4:57 AM, [e-mail] <mailto:[e-mail]> wrote:
>  
> Hi John,
>  
> Sorry to turn this thread into a general call for comment while the document is post WGLC…
>  
> Better now than when it gets to IETF Last Call.
>  
> When:
> 1)     a BGP session is established (OPEN1)
> 2)     then GR or draft-ietf-idr-bgp-gr-notification triggers a new BGP open (OPEN2)
> 3)     this BGP OPEN2 triggers a Notification OPEN Message Error
> 4)     draft-ietf-idr-bgp-gr-notification is used to handle this Notification using GR
>  
> It’s not crystal clear to me whether the BGP speakers should behave (in term of OPEN capability/parameters) as per OPEN1 or as per OPEN2.
> Indeed, OPEN2 is the latest but was erroneous and explicitly refused.
> Then again, the answer may be subcode specific… (with “Unacceptable Hold Time” it’s unlikely to accept the (Hold Time) parameter(s) from OPEN2).
>  
> I think if the OPEN2 still exchanges the "N" bit it's already sufficiently specified, or maybe the point is moot.
> [Bruno] To be more specific, at step “4”, does the BGP speaker uses the GR parameters such as “Restart Time”, “GR AFI/SAFI” from OPEN1 or OPEN2? Same question for the “Forwarding State (F) » bits. Same question for parameters in LLGR capability.
> From your answer, you seem so say that the “N” bit from OPEN2 needs to be considered and taken into account. 

That wasn't what I meant to say. Rather I meant that if OPEN1 carried the N bit and OPEN2 also carries the N bit, then it's immaterial whether we're considering the N bit status of OPEN1 or OPEN2 since they're the same anyway. But if pressed, I'd say the status of OPEN1 is the one that applies. Possibly the new text I propose above (that adds "once the session has transitioned into ESTABLISHED state" is sufficient?

> I’d like this to be clarified.  
>  
> OTOH if OPEN2 doesn't exchange the "N" bit (either because it removes the GR capability entirely or because it removes the bit) then maybe there is some clarification required. Unfortunately RFC 5492 doesn't seem to say when a capability is said to have been successfully exchanged, probably because at time of writing (or at least at time of writing the predecessor) the idea of keeping around previous-session state didn't exist. 
> [Bruno] Exactly. That’s why I believe the burden to clarify/specify this falls on draft-ietf-idr-bgp-gr-notification
>  
> Tentatively, my answer is to say "a capability is only considered to have been exchanged when the session carrying it transitions to ESTABLISHED state". In the situation under discussion, that wouldn't happen, so gr-notification type semantics would continue to remain in effect.
> [Bruno] Any answer works for me. I particularly like your proposition being clear and very general. However, it seems to say that the BGP capability advertised in OPEN2 should not be considered. While in your above answer, you seem to take it into consideration (“if the OPEN2 still exchanges the "N"”)

I hope my comments above clarify this point.

[rest trimmed]

Regards,

--John