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

[<[e-mail]>]

Hi John,

Please see inline [Bruno2]

From: Idr [mailto:[e-mail]] On Behalf Of John G. Scudder
Sent: Tuesday, April 10, 2018 4:29 PM
To: DECRAENE Bruno IMT/OLN
Cc: [e-mail]; idr@ietf. org; [e-mail]
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-gr-notification-13

(as co-author and WG member)

Hi Bruno,

Discussion in line below.

On Apr 10, 2018, at 4:52 AM, [e-mail]<mailto:[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.

[… skipping the easy point]



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.

[Bruno2] Another case is a first reset (following the erroneous OPEN  i.e. my example) followed by some time e.g. around GR Restart Time. So I’m not sure that this is necessary quick enough not to care about (although I agree that this is very unlikely)

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.

[Bruno2] Looks good to me. Thanks.
Yet this text only applies to the “N” bit and does not specify the behavior for other GR parameters. e.g. change in Restart Time. May be the following text would cover all GR parameters:
NEW2:
   If a BGP speaker which previously advertised the "N" bit opens a new
   session with different Graceful Restart parameters, these new parameters
 apply once the session has
   transitioned into ESTABLISHED state".

But I leave this to you.

Thanks,
Regards,
--Bruno




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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.