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

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.
                          ^^^^^^^^
"""

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