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

<bruno.decraene@orange.com> Tue, 10 October 2017 11:42 UTC

Return-Path: <bruno.decraene@orange.com>
X-Original-To: grow@ietfa.amsl.com
Delivered-To: grow@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60879134D14; Tue, 10 Oct 2017 04:42:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level:
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hxOvkiBBgc6; Tue, 10 Oct 2017 04:42:26 -0700 (PDT)
Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5D7F134D1B; Tue, 10 Oct 2017 04:41:35 -0700 (PDT)
Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 766A1C027E; Tue, 10 Oct 2017 13:41:34 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 2C0D8C0079; Tue, 10 Oct 2017 13:41:34 +0200 (CEST)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0361.001; Tue, 10 Oct 2017 13:41:33 +0200
From: bruno.decraene@orange.com
To: Job Snijders <job@ntt.net>
CC: Matthew Miller <linuxwolf+ietf@outer-planes.net>, "gen-art@ietf.org" <gen-art@ietf.org>, "grow@ietf.org" <grow@ietf.org>, "draft-ietf-grow-bgp-gshut.all@ietf.org" <draft-ietf-grow-bgp-gshut.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Thread-Topic: [GROW] Genart last call review of draft-ietf-grow-bgp-gshut-11
Thread-Index: AQHTQa9tDslAGW/G/EKGxib2aUqD/aLc8mvA
Date: Tue, 10 Oct 2017 11:41:32 +0000
Message-ID: <26657_1507635694_59DCB1EE_26657_410_1_53C29892C857584299CBF5D05346208A478A9426@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <150759929173.18515.8831141207586025582@ietfa.amsl.com> <2413_1507629407_59DC995F_2413_449_1_53C29892C857584299CBF5D05346208A478A8FE2@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20171010100621.GA75071@Vurt.local>
In-Reply-To: <20171010100621.GA75071@Vurt.local>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/grow/vmcMIpsqQpEUmcCaC2cMG5ap5HA>
Subject: Re: [GROW] Genart last call review of draft-ietf-grow-bgp-gshut-11
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/grow/>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Oct 2017 11:42:29 -0000

Job,

> From: Job Snijders [mailto:job@ntt.net]
 > Sent: Tuesday, October 10, 2017 12:06 PM
> 
 > On Tue, Oct 10, 2017 at 09:56:45AM +0000, bruno.decraene@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.