Re: [GROW] Opsdir last call review of draft-ietf-grow-bgp-gshut-13

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.
> 
> 
> bruno.decraene@orange.com writes:
> OK,
> Thanks Susan.
> 
> --Bruno
> 
> -----Original Message-----
> From: Susan Hares [mailto:shares@ndzh.com]
> Sent: Thursday, January 18, 2018 12:25 PM
> To: DECRAENE Bruno IMT/OLN
> Cc: grow@ietf.org; draft-ietf-grow-bgp-gshut.all@ietf.org; ietf@ietf.org; ops-dir@ietf.org
> 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: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]
> Sent: Thursday, January 18, 2018 6:19 AM
> To: Susan Hares
> Cc: grow@ietf.org; draft-ietf-grow-bgp-gshut.all@ietf.org; ietf@ietf.org; ops-dir@ietf.org
> 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:shares@ndzh.com] Sent: Thursday, January 18, 2018 9:46 AM  >
> To: ops-dir@ietf.org Cc: grow@ietf.org; draft-ietf-grow-bgp-gshut.all@ietf.org; ietf@ietf.org  >
> 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
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
> 
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow