[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.
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
