Thu, Jan 18, 2018 at 11:10:38AM -0500, Jay Borkenhagen: > [resend - apologies for any dupes] > > Distro cut *way* down. > > Regarding the suggestion for "logging knobs": > > - if it's just logging that a gshut action was taken, that's a local > implementation decision -- no need to mention it in the draft. > > - if it's "Possibly raising alarms when something seems wrong", that > would be a bad idea. There *will* be instances when traffic remains > on the link even after the graceful shutdown initiator has signaled > an approaching shutdown.
This a good point. If the path is the only one, traffic will remain until the path is withdrawn. NOCs deal with enough errors & noise already; this would be a difficult one for an NMS to adjudicate. > To keep things simple and to allow the gshut draft to continue making > progress, I'd prefer to leave it as-is. > > Thanks. > > Jay B. > > > [email protected] writes: > OK, > Thanks Susan. > > --Bruno > > -----Original Message----- > From: Susan Hares [mailto:[email protected]] > Sent: Thursday, January 18, 2018 12:25 PM > To: DECRAENE Bruno IMT/OLN > Cc: [email protected]; [email protected]; [email protected]; > [email protected] > Subject: RE: Opsdir last call review of draft-ietf-grow-bgp-gshut-13 > > Bruno: > > I'm sorry I'm this late for the review. On the editorial nit, if you think > it helps - send it to the RFC > editor. > > On the logging knobs, you understood my point. Logs should cover what is > section 4.2. However, > since the document is in the RFC editor's queue - it is your choice. If you > get a chance to edit it in - > fine. If not, those people who implement the gshut will probably put it in. > > Thanks for asking, Susan Hares > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Thursday, January 18, 2018 6:19 AM > To: Susan Hares > Cc: [email protected]; [email protected]; [email protected]; > [email protected] > Subject: RE: Opsdir last call review of draft-ietf-grow-bgp-gshut-13 > > Hi Susan, > > Thanks for your time reviewing this document and you below comments. > > Please see my replies inline [Bruno] > > Note that however fast I'm answering to your review, that document is now in > RFC editor queue, > and hence technical changes are much more difficult. (AFAIK, would require > specific approval > from the responsible AD). Thanks for taking this into account. > > > > -----Original Message----- > From: Susan Hares [mailto:[email protected]] Sent: Thursday, January 18, 2018 > 9:46 AM > > To: [email protected] Cc: [email protected]; > [email protected]; [email protected] > > Subject: Opsdir last call review of draft-ietf-grow-bgp-gshut-13 Reviewer: > Susan Hares > > Review result: Has Nits Status: Nits The operational procedures described in > this > process for the gshut comment are accurately covered, and SHOULD work well. > The > Appendices A-C add to an operations document and should be retained for > publication. > > [Bruno] ok, thanks. > > Technical nit: > location of technical nit: (section 4.3) The document indicats that the "BGP > implementers > SHOULD provide configuration knobs that utilize teh GRACEFUL_SHUTDOWN > community." > > > What the problem is: > The document does not say is that their should be error reporting knobs to > track the use of > GRACEFUL_SHUTDOWN community. This can go in section 4.3 in one or two > sentences. > > [Bruno] > Could you please elaborate on this? What do you have in mind by "error > reporting knobs"? > Thinking about this, what I could think of would be logs detailing the steps > in section 4.2. Possibly > raising alarms when something seems wrong. (e.g. after waiting for BGP > convergence, there is still > some traffic sent/received over the interface(s) related to the EBGP session) > Is this what you were > thinking about? > > > Editorial nit: > section 3. paragraph 2, p. 3 > > > /This is because alternate paths can be hidden by knodes of an AS./ commment: > The implied > "this" is too vague for a specification. > > > Fix:/This lack of path occurs because alternate paths can be hidden by nodes > of an AS."/ > > > [Bruno] > I agree that your proposed text makes it more explicit, which is always > better in a specification > (when it's not redundant). > However, I would note 2 points: > - section 3 is part of the introduction to the problem space. It explains the > root cause of the > problem. It's not part of the graceful shutdown specification. > - The text you are referring to is a paragraph starting with: "First, some > routers can have no path > toward an affected prefix, and drop traffic destined to this prefix. This is > because alternate paths > can be hidden by nodes of an AS." > Hence "This" refers to the short sentence which is immediately before. I > don't feel that there is > much ambiguity. > > That being said, as you classify your comment as an editorial nit, I could > propose to forward it to > the RFC editor, and let the RFC editor propose a resolution. > Would this be ok for you? > > Thanks, > Best regards, > --Bruno > > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
