Re: [GROW] Genart last call review of draft-ietf-grow-bgp-gshut-11

[Ben Maddison]

Hi all,

On 10 Oct 2017 5:50 pm, Jay Borkenhagen  wrote:
Job Snijders writes:
 > > The LOCAL_PREF choice here is a simple thing -- don't make it more
 > > complicated than it needs to be.
 > >
 > > Job's suggested text says all that's necessary:
 > >
 > > "The LOCAL_PREF value SHOULD be lower than any of the alternative
 > > paths.  Zero being the lowest value, it MAY be used whichever
 > > LOCAL_PREF values are used by the AS."
 >
 > The above comes from Bruno's hand, I actually proposed the following:
 >
 > "The LOCAL_PREF value SHOULD be lower than any of the
 > alternative paths. It is RECOMMEND to use 0, the lowest LOCAL_PREF
 > value."
 >
 > Kind regards,
 >
 > Job


Sorry for my mis-citing / mis-quoting.  Let me try my hand:

 The LOCAL_PREF value SHOULD be lower than any of the alternative
 paths.  The RECOMMENDED value is 0.

That formulation gets my vote. If operators have a good reason to deviate from 
the recommendation, they will know that without it being pointed out in the 
document.



Thanks.

Jay B.

Cheers,

Ben



___
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

Re: [GROW] Genart last call review of draft-ietf-grow-bgp-gshut-11

[Jay Borkenhagen]

David Farmer writes:
 > I would prefer a normative RECOMMENDED, the rest of the sentence in
 > RFC2119, just means you should explain the constraints on the alternatives.
 > How about something like this;
 > 
 > "The LOCAL_PREF value SHOULD be lower than any of the alternative
 > paths.  A LOCAL_PREF
 > value of Zero is RECOMMENDED, however any LOCAL_PREF value lower than all
 > other LOCAL_PREF values used within an AS is an acceptable alternative.
 > The LOCAL_PREF value used, Zero or otherwise, SHOULD NOT also
 > have another use or meaning within the AS."
 > 


The LOCAL_PREF choice here is a simple thing -- don't make it more
complicated than it needs to be.

Job's suggested text says all that's necessary:

"The LOCAL_PREF value SHOULD be lower than any of the alternative
paths.  Zero being the lowest value, it MAY be used whichever
LOCAL_PREF values are used by the AS."


Thanks.

Jay B.



___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Genart last call review of draft-ietf-grow-bgp-gshut-11

[David Farmer]

On Tue, Oct 10, 2017 at 7:33 AM,  wrote:

> > From: Job Snijders [mailto:j...@ntt.net]
>  > Sent: Tuesday, October 10, 2017 2:00 PM
> >
>  > On Tue, Oct 10, 2017 at 11:41:32AM +, bruno.decra...@orange.com
> wrote:
>  > >  > Any attribute (origin, as_path, aggregator) anywhere can be
> overloaded
>  > >  > to mean something only significant to the local network. I think
> the
>  > >  > document is simpler without this and see no point in mentioning
> this. I
>  > >  > propose:
>  > >  >
>  > >  > OLD:
>  > >  > The LOCAL_PREF value must be lower than the one of the
> alternate
>  > >  > path. 0 being the lowest value, it can be used in all cases,
> except
>  > >  > if it already has a special meaning within the AS.
>  > >  > NEW:
>  > >  > The LOCAL_PREF value SHOULD be lower than any of the
> alternative
>  > >  > paths. It is RECOMMEND to use 0, the lowest LOCAL_PREF value.
>  > >
>  > > What is really needed is "The LOCAL_PREF value SHOULD be lower than
>  > > the one of the alternative path." Looks reasonable to extend it to
>  > > your proposition " The LOCAL_PREF value SHOULD be lower than any of
>  > > the alternative paths." So I'm changing for this.
>  > >
>  > > Now the value is truly local to an AS, and I'm not sure to see the
>  > > technical reason to RECOMMEND (SHOULD) a specific value. MAY seems
>  > > more appropriate to me. Hence I'm proposing to keep "Zero being the
>  > > lowest value, it MAY be used whichever LOCAL_PREF values are used by
>  > > the AS."
>  >
>  > So the total of the new text is as following?
>  >
>  > "The LOCAL_PREF value SHOULD be lower than any of the alternative
>  > paths.  Zero being the lowest value, it MAY be used whichever
>  > LOCAL_PREF values are used by the AS."
>
> Yes, that is correct.
>
>  > I am not sure about the second sentence, it seems hard to read.
>
> I'm open to reformulation.
>
>  > I see value in just recommending a value for people moving between ASNs
>  > (debugging other organisation's networks via BGP looking glasses) to
>  > recognise as a highly undesirable path.
>
> I agree.
>
> > Reading RFC 2119 the
>  > 'RECOMMENDED' seems appropiate, "use 0 unless you have a reason not to".
>
> I'm fine with that part, but the subsequent RFC 2119 text "but the full
> implications must be understood and carefully weighed before choosing a
> different course." seems too strong for me, as there is just no issue with
> an AS choosing a different value.
>
>
>  > This is a GROW document and I believe clear-cut guidance will benefit
>  > all.
>
> OK. What about using lower case "recommended" ?
> Proposed NEW: Zero is the lowest value and MAY be used whichever
> LOCAL_PREF values are used by the AS, hence the use of LOCAL_PREF 0 is
> recommended.
>
> (possibly adding "for consistency between ASes and implementations" )
>
> Thanks again for your comments.
> Kind regards,
> --Bruno
>

I would prefer a normative RECOMMENDED, the rest of the sentence in
RFC2119, just means you should explain the constraints on the alternatives.
How about something like this;

"The LOCAL_PREF value SHOULD be lower than any of the alternative
paths.  A LOCAL_PREF
value of Zero is RECOMMENDED, however any LOCAL_PREF value lower than all
other LOCAL_PREF values used within an AS is an acceptable alternative.
The LOCAL_PREF value used, Zero or otherwise, SHOULD NOT also
have another use or meaning within the AS."

-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Genart last call review of draft-ietf-grow-bgp-gshut-11

[bruno.decraene]

Job,

> From: Job Snijders [mailto:j...@ntt.net]
 > Sent: Tuesday, October 10, 2017 12:06 PM
> 
 > On Tue, Oct 10, 2017 at 09:56:45AM +, bruno.decra...@orange.com wrote:
 > > > Minor issues:
 > > >
 > > > In Section 4. "EBGP graceful shutdown procedure", it states that 0
 > > > can used in all cases except where the AS already has a special
 > > > meaning for 0. It seems to me more ought to be said, but I admit I'm
 > > > not well-versed on (I) BGP and might be seeing dragons where only
 > > > windmills are present.
 > >
 > > [Bruno]
 > > I'm not seeing much more to say. It's intended as a warning that an AS
 > > may already use LOCAL_PREF zero to mean something specific. In which
 > > case, the AS knows the specifics,  authors/IETF/draft/RFC do not.
 > > I'm changing to the following reformulation. Please feel free to
 > > suggest text if you prefer.
 > >
 > > OLD: The LOCAL_PREF value must be lower than the one of the alternate
 > > path. 0 being the lowest value, it can be used in all cases, except if
 > > it already has a special meaning within the AS.
 > > NEW: The LOCAL_PREF value SHOULD be lower than the one of the
 > > alternate path. Zero being the lowest value, it MAY be used whichever
 > > LOCAL_PREF values are used by the AS. If LOCAL_PREF zero already has a
 > > special meaning within the AS, and there is a need to distinguish both
 > > usages, another low value MAY be used.
 > 
 > Any attribute (origin, as_path, aggregator) anywhere can be overloaded
 > to mean something only significant to the local network. I think the
 > document is simpler without this and see no point in mentioning this. I
 > propose:
 > 
 > OLD:
 > The LOCAL_PREF value must be lower than the one of the alternate
 > path. 0 being the lowest value, it can be used in all cases, except
 > if it already has a special meaning within the AS.
 > NEW:
 > The LOCAL_PREF value SHOULD be lower than any of the alternative
 > paths. It is RECOMMEND to use 0, the lowest LOCAL_PREF value.

What is really needed is "The LOCAL_PREF value SHOULD be lower than the one of 
the alternative path."
Looks reasonable to extend it to your proposition " The LOCAL_PREF value SHOULD 
be lower than any of the alternative paths." So I'm changing for this.

Now the value is truly local to an AS, and I'm not sure to see the technical 
reason to RECOMMEND (SHOULD) a specific value. MAY seems more appropriate to 
me. Hence I'm proposing to keep
"Zero being the lowest value, it MAY be used whichever LOCAL_PREF values are 
used by the AS."

I'm open to remove "If LOCAL_PREF zero already has a special meaning within the 
AS, and there is a need to distinguish both usages, another low value MAY be 
used." If you believe that this sentence add complexity. I'd agree that it is 
somewhat redundant, although it does provides a specific point to consider.

 
 > Kind regards,
 > 
 > Job
 > 
 > ps. I-D.ietf-idr-shutdown can reference RFC 8203 now.

Thanks. Fixed.

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

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Genart last call review of draft-ietf-grow-bgp-gshut-11

[Job Snijders]

On Tue, Oct 10, 2017 at 09:56:45AM +, bruno.decra...@orange.com wrote:
> > Minor issues:
> > 
> > In Section 4. "EBGP graceful shutdown procedure", it states that 0
> > can used in all cases except where the AS already has a special
> > meaning for 0. It seems to me more ought to be said, but I admit I'm
> > not well-versed on (I) BGP and might be seeing dragons where only
> > windmills are present.
>  
> [Bruno] 
> I'm not seeing much more to say. It's intended as a warning that an AS
> may already use LOCAL_PREF zero to mean something specific. In which
> case, the AS knows the specifics,  authors/IETF/draft/RFC do not.
> I'm changing to the following reformulation. Please feel free to
> suggest text if you prefer.
>  
> OLD: The LOCAL_PREF value must be lower than the one of the alternate
> path. 0 being the lowest value, it can be used in all cases, except if
> it already has a special meaning within the AS.
> NEW: The LOCAL_PREF value SHOULD be lower than the one of the
> alternate path. Zero being the lowest value, it MAY be used whichever
> LOCAL_PREF values are used by the AS. If LOCAL_PREF zero already has a
> special meaning within the AS, and there is a need to distinguish both
> usages, another low value MAY be used.

Any attribute (origin, as_path, aggregator) anywhere can be overloaded
to mean something only significant to the local network. I think the
document is simpler without this and see no point in mentioning this. I
propose:

OLD:
The LOCAL_PREF value must be lower than the one of the alternate
path. 0 being the lowest value, it can be used in all cases, except
if it already has a special meaning within the AS.
NEW:
The LOCAL_PREF value SHOULD be lower than any of the alternative
paths. It is RECOMMEND to use 0, the lowest LOCAL_PREF value.

Kind regards,

Job

ps. I-D.ietf-idr-shutdown can reference RFC 8203 now.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Genart last call review of draft-ietf-grow-bgp-gshut-11

[Matthew Miller]

Reviewer: Matthew Miller
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-grow-bgp-gshut-11
Reviewer: Matthew A. Miller
Review Date: 2017-10-09
IETF LC End Date: 2017-10-11
IESG Telechat date: N/A

Summary:

This document is ready to be published as an Informational document, but
there is one issue that I think clarification would help.

Major issues:

NONE

Minor issues:

In Section 4. "EBGP graceful shutdown procedure", it states that 0 can
used in all cases except where the AS already has a special meaning for
0. It seems to me more ought to be said, but I admit I'm not well-versed
on (I) BGP and might be seeing dragons where only windmills are present.


Nits/editorial comments:

* I suggest using RFC 8174 and its terminology boiler plate to help
  disambiguate "may" versus "MAY".

* A number of acronyms are used throughout without being spelled out (e.g.,
  RR, IBGP, FIB, EBGP, AS), but some (e.g., ASBR) are spelled out.  I would
  find it helpful to be consistent here, preferably by spelling them out on
  first use.

* In Section 1. "Introduction", second paragraph, the word "operation"
  seems to be missing from the first sentence:

  """
  This document discusses operational procedures to be applied in order
  to reduce or eliminate loss of packets during a maintenance.
  """

* Throughout the Appendices, there are some inconsistent uses of some terms,
  especially when compared to the rest of the document:

  - "Local-Pref" versus "LOCAL_PREF"
  - "nexhop" versus "NEXT_HOP"

* In Appendix A. "Alternative techniques with limited applicability", the
  phrase "describe them" ought to be "describes them".


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow