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

From: Susan Hares <[email-masked]>
Date: Thu, 18 Jan 2018 00:45:51 -0800

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.

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.

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."/

---

From: <[email-masked]>
Date: Thu, 18 Jan 2018 11:19:15 +0000

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-masked]]
 > Sent: Thursday, January 18, 2018 9:46 AM
 > To: [email-masked]
 > Cc: [email-masked]; [email-masked]; [email-masked]
 > Subject: Opsdir last call review of draft-ietf-grow-bgp-gshut-13
 > 
 > Reviewer: Susan Hares
 > Review result: Has Nits
 > 
 > Status: Nits
 > 

[Bruno] ok, thanks.
 
 > track the use of GRACEFUL_SHUTDOWN community.  This can go in section 4.3 in
 
[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?

 > Fix:/This lack of path occurs because alternate paths can be hidden by nodes of

[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

_________________________________________________________________________________________________________________________

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.

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 18 Jan 2018 06:25:09 -0500

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-masked] [mailto:[email-masked]] 
Sent: Thursday, January 18, 2018 6:19 AM
To: Susan Hares
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Opsdir last call review of draft-ietf-grow-bgp-gshut-13

Hi Susan,

 > From: Susan Hares [mailto:[email-masked]]  > Sent: Thursday, January 18, 2018 9:46 AM  > To: [email-masked]  > Cc: [email-masked]; [email-masked]; [email-masked]  > 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?

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

Thanks,
Best regards,
--Bruno

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.

---

From: <[email-masked]>
Date: Thu, 18 Jan 2018 12:50:46 +0000

OK,
Thanks Susan.

--Bruno

 > Sent: Thursday, January 18, 2018 12:25 PM
 > To: DECRAENE Bruno IMT/OLN
 > 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.
 > 
 > 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.
 > 
 > 
 > 
 >  > From: Susan Hares [mailto:[email-masked]]  > Sent: Thursday, January 18, 2018 9:46 AM  >
 > To: [email-masked]  > Cc: [email-masked]; [email-masked]; [email-masked]  >
 > 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]
 > 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 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."
 > 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.
 > ________________________________________________________________________________
 > _________________________________________
 > 
 > 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.

---

From: Jay Borkenhagen <[email-masked]>
Date: Thu, 18 Jan 2018 11:10:38 -0500

[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-masked] writes:
OK,
Thanks Susan.

--Bruno

-----Original Message-----
From: Susan Hares [mailto:[email-masked]]
Sent: Thursday, January 18, 2018 12:25 PM
To: DECRAENE Bruno IMT/OLN
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
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.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, January 18, 2018 6:19 AM
To: Susan Hares
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Opsdir last call review of draft-ietf-grow-bgp-gshut-13

Hi Susan,

-----Original Message-----
From: Susan Hares [mailto:[email-masked]] Sent: Thursday, January 18, 2018 9:46 AM  >
To: [email-masked] Cc: [email-masked]; [email-masked]; [email-masked]  >
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]

Editorial nit:
/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.

Thanks,
Best regards,
--Bruno

_______________________________________________
GROW mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/grow

---

From: Jay Borkenhagen <[email-masked]>
Date: Thu, 18 Jan 2018 09:36:28 -0500

Distro cut *way* down.

Thanks.

						Jay B.

---

From: heasley <[email-masked]>
Date: Thu, 18 Jan 2018 16:59:14 +0000

>   on the link even after the graceful shutdown initiator has signaled

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.

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Jan 2018 10:21:44 -0500

Jay: 

First of all - I'm fine with whatever you decide.   I do not want to delay
the publication process. This is an important specification for operators.  

On just logging, the question is whether GROW wants to suggest to
implementations that there should be implementation knobs for logging.
How/when/where - logging gets set is an implementation detail.    

If Grow wants that, you can add in a 1 sentence during RFC editor process.
This is language is useful for specification to be clear on what knobs the
users expect.  If Grow does not care, then leave it out. 

Logging could eventually use the "push" yang modules - but that's for IDR 's
yang modules.   As to alarms,  agreed.  Not a good idea.

Thanks for the response.  I'm sorry my review was delayed. 
 
Sue Hares

-----Original Message-----
From: Jay Borkenhagen [mailto:[email-masked]] 
Sent: Thursday, January 18, 2018 9:36 AM
To: [email-masked]
Cc: Susan Hares; [email-masked]
Subject: Re: [GROW] Opsdir last call review of draft-ietf-grow-bgp-gshut-13

Distro cut *way* down.

Thanks.

						Jay B.

[email-masked] writes:
 >  > From: Susan Hares [mailto:[email-masked]]  >  > Sent: Thursday,
January 18, 2018 12:25 PM  >  > To: DECRAENE Bruno IMT/OLN  >  > Cc:
[email-masked]; [email-masked]; [email-masked];
[email-masked]  >  > Subject: RE: Opsdir last call review of
draft-ietf-grow-bgp-gshut-13  >  >  >  > Bruno:
 >  > 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 -  >
 >  > Sent: Thursday, January 18, 2018 6:19 AM  >  > To: Susan Hares  >  >
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]  >  > 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.
 >  >  > From: Susan Hares [mailto:[email-masked]]  > Sent: Thursday,
January 18, 2018 9:46 AM  >  >  > To: [email-masked]  > Cc: [email-masked];
[email-masked]; [email-masked]  >  >  > 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.
 >  > 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?
> 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).
 >  > - 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?
____________________________________________________________________________
____
 >  > 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.
____________________________________________________________________________
_____________________________________________
 >
 > 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,
 > 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.