Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)

<bruno.decraene@orange.com> Thu, 20 October 2016 13:38 UTC

Return-Path: <bruno.decraene@orange.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510CF129619 for <idr@ietfa.amsl.com>; Thu, 20 Oct 2016 06:38:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.329
X-Spam-Level:
X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_DUL=0.001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 I6beqI9-ITKt for <idr@ietfa.amsl.com>; Thu, 20 Oct 2016 06:38:50 -0700 (PDT)
Received: from relais-inet.orange.com (relais-aub40.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 956EA1295F9 for <idr@ietf.org>; Thu, 20 Oct 2016 06:38:50 -0700 (PDT)
Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 4A140C00C8; Thu, 20 Oct 2016 15:38:48 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id A7061180040; Thu, 20 Oct 2016 15:38:48 +0200 (CEST)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0319.002; Thu, 20 Oct 2016 15:38:46 +0200
From: <bruno.decraene@orange.com>
To: DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com>, Job Snijders <job@ntt.net>
Thread-Topic: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)
Thread-Index: AQHSKtPQCrBkk4eGMkON0rEBH5hX56CxU01ggAAE3ZA=
Date: Thu, 20 Oct 2016 13:38:45 +0000
Message-ID: <2588_1476970728_5808C8E8_2588_648_1_9ab4dc04-d856-449d-b978-8ea1960a25d1@OPEXCLILMA1.corporate.adroot.infra.ftgroup>
References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> <20161019185405.GA12214@puck.nether.net> <01ab01d22ab2$2b54f8e0$4001a8c0@gateway.2wire.net> <515_1476964767_5808B19F_515_1079_1_53C29892C857584299CBF5D05346208A0FA0799F@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20161020131349.GL1033@Vurt.local> <10701_1476970482_5808C7F2_10701_5009_1_53C29892C857584299CBF5D05346208A0FA07C6E@OPEXCLILM21.corporate.adroot.infra.ftgroup>
In-Reply-To: <10701_1476970482_5808C7F2_10701_5009_1_53C29892C857584299CBF5D05346208A0FA07C6E@OPEXCLILM21.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.3]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/A02Vdc8nssX0dtFFFnnBLI6unkQ>
Cc: IETF IDR WG <idr@ietf.org>, Sue Hares <shares@ndzh.com>
Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Oct 2016 13:38:53 -0000

Correction (sorry for the spam)

> making it clear in the document that
 > the community space starting with NNNN: "belongs" or is "assigned" by AS NNNN.

that AS NNNN, owns/control the assignment of the community space starting with NNNN:

(Such correction is expected to handle cases where NNNN is not an assigned AS number. e.g. 0000. )

--Bruno

 > -----Original Message-----
 > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
 > Sent: Thursday, October 20, 2016 3:35 PM
 > To: Job Snijders
 > Cc: IETF IDR WG; Sue Hares
 > Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to
 > 10/31/2016)
 > 
 > Hi Job,
 > 
 > > From: Job Snijders [mailto:job@ntt.net]  > Sent: Thursday, October 20, 2016 3:14 PM
 > >
 >  > Hi Bruno,
 >  >
 >  > Do you feel it is not already clear enough from the introduction?
 >  >
 >  > """
 >  >    To address these shortcomings, this document defines a Large BGP
 >  >    Communities attribute encoded as one or more twelve-octet values,
 >  >    each consisting of a four-octet ASN and two four-octet operator-
 >  >    defined values, each of which can be used to denote properties or
 >  >    actions significant to that ASN.
 >  >                           ^^^^^^^^
 >  > """
 > 
 > I'm personally fine with the text, but I think that the concern expressed is about having his
 > community space squatted by somebody else. i.e. making it clear in the document that
 > the community space starting with NNNN: "belongs" or is "assigned" by AS NNNN.
 > Looking at the definition of "significant" I don't feel that this fully address the point. e.g. a
 > well-known community may be significant to AS NNNN, yet this space is not assigned by
 > AS NNNN.
 > 
 > King regards,
 > -- Bruno
 > 
 >  > Kind regards,
 >  >
 >  > Job
 >  >
 >  > On Thu, Oct 20, 2016 at 11:59:26AM +0000, bruno.decraene@orange.com wrote:
 >  > > May be one suggestion, trying to address Tom's comment, and inspired by RFC 4360:
 >  > > https://tools.ietf.org/html/rfc4360#section-3.1
 >  > >
 >  > > OLD:
 >  > >    Local Data Part 1:  A four-octet operator-defined value.
 >  > >    Local Data Part 2:  A four-octet operator-defined value
 >  > >
 >  > > NEW:
 >  > >    Local Data Part 1:  A four-octet value. The format and meaning is defined by the
 >  > Autonomous System set in the Global Administrator field.
 >  > >    Local Data Part 2:  A four-octet value. The format and meaning is defined by the
 >  > Autonomous System set in the Global Administrator field.
 >  > >
 >  > > Or some other wording, but I think the point is that "operator-defined" means the
 >  > operator of the AS set in the Global Administrator field.
 >  > >
 >  > > --Bruno
 >  > >
 >  > >  > -----Original Message-----
 >  > >  > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of t.petch
 >  > >  > Sent: Thursday, October 20, 2016 10:38 AM
 >  > >  > To: Jared Mauch
 >  > >  > Cc: IETF IDR WG; Sue Hares
 >  > >  > Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to
 >  > >  > 10/31/2016)
 >  > >  >
 >  > >  > Jared
 >  > >  >
 >  > >  > As Brian has pointed out, it was the use of 'usually' that I was
 >  > >  > concerned with, as watering down the recommended use of an ASN by
 >  > >  > RFC1997.  Excise 'usually' and that part of my concern goes away.
 >  > >  >
 >  > >  > Tom Petch
 >  > >  >
 >  > >  >
 >  > >  > ----- Original Message -----
 >  > >  > From: "Jared Mauch" <jared@puck.Nether.net>;
 >  > >  > Sent: Wednesday, October 19, 2016 7:54 PM
 >  > >  >
 >  > >  >
 >  > >  > > On Wed, Oct 19, 2016 at 11:47:05AM +0100, t.petch wrote:
 >  > >  > > > I remain unhappy with this I-D.
 >  > >  > > >
 >  > >  > > > I find it ironic that the messages for this Last Call should be
 >  > >  > > > interspersed with those relating to what goes wrong when someone
 >  > >  > > > somewhere else in the world uses a field in an unexpected way.  This
 >  > >  > > > reinforces my belief that this I-D should be more forceful in
 >  > >  > calling
 >  > >  > > > out the dangers (eg MUST instead of SHOULD).
 >  > >  > > >
 >  > >  > > > I think that this I-D is factually incorrect, or at least open to
 >  > >  > > > misinterpretation,  when it says
 >  > >  > > > '[RFC1997] BGP Communities attributes are four-octet values split
 >  > >  > into
 >  > >  > > >    two two-octet words.  The most significant word is usually
 >  > >  > > >    interpreted as an Autonomous System Number (ASN) '
 >  > >  > >
 >  > >  > > rfc1998: section 4 gives you the slice + dice bits:
 >  > >  > >
 >  > >  > > -- snip -- rfc 1998 --
 >  > >  > >    To make use of the BGP community attribute, several community
 >  > >  > values
 >  > >  > >    (MCI's AS number: 3561 = 0x0DE9) have been defined that can be used
 >  > >  > >    by customers to tag routes so that the appropriate "LOCAL_PREF"
 >  > >  > >    values are configured. Table 2 lists the appropriate community
 >  > >  > >    attribute values (and the mappings of community to LOCAL_PREF):
 >  > >  > > -- snip -- rfc 1998 --
 >  > >  > >
 >  > >  > > This is the segmenting, and most customers have
 >  > >  > > "ip bgp community new-format" configured.
 >  > >  > >
 >  > >  > > If your issue is about printf %ull vs %d:%d:%d we operators
 >  > >  > > can solve this by ensuring our vendors do the right thing, which
 >  > >  > > we have already done 20 years ago via rfc1998.
 >  > >  > >
 >  > >  > > This nit is imo not worth picking.
 >  > >  > >
 >  > >  > > - Jared
 >  > >  > >
 >  > >  > > --
 >  > >  > > Jared Mauch  | pgp key available via finger from jared@puck.nether.net
 >  > >  > > clue++;      | http://puck.nether.net/~jared/  My statements are only
 >  > >  > mine.
 >  > >  >
 >  > >  > _______________________________________________
 >  > >  > Idr mailing list
 >  > >  > Idr@ietf.org
 >  > >  > https://www.ietf.org/mailman/listinfo/idr
 >  > >
 >  > >
 >  >
 > _________________________________________________________________________
 >  > ________________________________________________
 >  > >
 >  > > 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.
 >  > >
 >  > > _______________________________________________
 >  > > Idr mailing list
 >  > > Idr@ietf.org
 >  > > https://www.ietf.org/mailman/listinfo/idr
 > 
 > _________________________________________________________________________
 > ________________________________________________
 > 
 > 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.
 > 
 > _______________________________________________
 > Idr mailing list
 > Idr@ietf.org
 > https://www.ietf.org/mailman/listinfo/idr

_________________________________________________________________________________________________________________________

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.