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

[<[e-mail]>]

> From: Job Snijders [mailto:[e-mail]]
 > Sent: Tuesday, October 10, 2017 2:00 PM
> 
 > On Tue, Oct 10, 2017 at 11:41:32AM +0000, [e-mail] 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'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.
 > 
 > thanks.
 > 
 > Kind regards,
 > 
 > Job

_________________________________________________________________________________________________________________________

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.