On Tue, Oct 10, 2017 at 11:41:32AM +0000, [email protected] 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."
I am not sure about the second sentence, it seems hard to read.
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. Reading RFC 2119 the
'RECOMMENDED' seems appropiate, "use 0 unless you have a reason not to".
This is a GROW document and I believe clear-cut guidance will benefit
all.
> 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
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
