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

"i3D.net - Martijn Schmidt" <martijnschmidt@i3d.net> Fri, 21 October 2016 15:19 UTC

Return-Path: <martijnschmidt@i3d.net>
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 D5858129602 for <idr@ietfa.amsl.com>; Fri, 21 Oct 2016 08:19:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, WEIRD_QUOTING=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 a-x6hewlHCTK for <idr@ietfa.amsl.com>; Fri, 21 Oct 2016 08:19:45 -0700 (PDT)
Received: from mail.i3d.net (mail.i3d.nl [213.163.77.240]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F12F412955B for <idr@ietf.org>; Fri, 21 Oct 2016 08:19:44 -0700 (PDT)
X-Footer: aTNkLm5s
Received: from localhost ([127.0.0.1]) by mail.i3d.net with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)); Fri, 21 Oct 2016 17:19:39 +0200
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>, Job Snijders <job@ntt.net>, Jeffrey Haas <jhaas@pfrc.org>
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> <20161020215938.GE1074@Vurt.local> <adb00bcd7b8e45db857eae7019c646fc@XCH-ALN-014.cisco.com>
From: "i3D.net - Martijn Schmidt" <martijnschmidt@i3d.net>
Organization: i3D.net
Message-ID: <ae5da282-201c-f745-9f26-67ce73826bd5@i3d.net>
Date: Fri, 21 Oct 2016 17:19:40 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <adb00bcd7b8e45db857eae7019c646fc@XCH-ALN-014.cisco.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/0LU67u9breCCn5eb1qiRA8_ujg4>
Cc: heasley <heas@shrubbery.net>, 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: Fri, 21 Oct 2016 15:19:48 -0000

Hello Jakob,

I think we need to ask ourselves whether the new wording is really
relevant to implementors. The answer here appears to be that it's not,
because the draft states "Implementations MUST allow the operator to
specify any value for the Global Administrator field." and no amount of
SHOULD will override the MUST.

Secondly, there's literally no way for the vendor to check whether an
ASN belongs to "the entity that defines the meaning of the rest of the
Large Community" so it's completely unenforceable and therefore doesn't
belong in a protocol specification / IDR draft.

If we want to instruct operators to do something, it SHOULD be done in a
RFC1998-like BCP/GROW document and I'd be happy to contribute some
wording which seeks to make that happen when the draft is submitted to
GROW for adoption as a WG subject.

Best regards,
Martijn Schmidt

On 10/21/2016 12:13 AM, Jakob Heitz (jheitz) wrote:
> In addition, to deal with the values for the GA field, we will replace
>
>    The Global Administrator field is intended to allow different
>    Autonomous Systems to define Large BGP Communities without collision.
>
> with
>
>   A Large Community that
>   is intended to be sent to multiple ASes SHOULD contain an ASN
>   in the Global Administrator field. The ASN SHOULD be one that
>   is assigned to the entity
>   that defines the meaning of the rest of the Large Community.
>   This allows a route to carry multiple Large Communities, the meaning
>   of each being defined by different independent entities.
>
> Thanks,
> Jakob.
>
>
>> -----Original Message-----
>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Job Snijders
>> Sent: Thursday, October 20, 2016 3:00 PM
>> To: Jeffrey Haas <jhaas@pfrc.org>
>> Cc: heasley <heas@shrubbery.net>; 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)
>>
>> Hi working group,
>>
>> On Tue, Oct 18, 2016 at 04:38:00PM -0400, Jeffrey Haas wrote:
>>>> On Oct 18, 2016, at 3:15 PM, Job Snijders <job@ntt.net> wrote:
>>>>
>>>>> Part of the idea behind reserving 65535:*:* was to reserve a space that
>>>>> could later be used for well-knowns, if that was desired - but to not
>>>>> spend time now arguing about details of what well-knowns are necessary.
>>>>>
>>>>> 0:*:* and 4294967295:*:* mimics rfc1997 and the reserved ASNs.
>>>> Jeff argues that a justification should be added. Maybe someone can
>>>> pitch in one or two sentences that explain why these are reserved?
>>> That's certainly part of it.  While I think many people can see the
>>> reason why you might want to do such a reservation, to do so you
>>> should have a practical reason in the document.
>>>
>>> For the 65535:*:* case, for symmetry with RFC 1997, you'd probably
>>> want to note that if it's used for that symmetry that either the
>>> existing well known community registry is used at IANA or that a new
>>> one would need to be created.  Alternatively, you just say the work is
>>> expected and defer to a future document.
>>>
>>> Note by doing this, you're setting up some expectations about
>>> translation of communities from one space to another.  FWIW, I don't
>>> recommend this and simply suggest that you recommend *not* using these
>>> for common use in case someone decides that they want to do so.  I
>>> know your organization and others such as Deutsche Telecom have some
>>> thoughts about what translation infrastructure might look like, and
>>> such mechanisms would have impact.
>>>
>>> With regard to the 0: and max-uint32: cases, after dealing with the
>>> headaches associated with helping with documents such as the as0 and
>>> RFC 7300 and putting in some restrictions in the configuration...
>>> followed by having to take them away, I'm very reluctant to put in
>>> anything beyond "we think it's a bad idea to use these, so pretty
>>> please don't"
>> After some off-list back and forth with John Heasley, Adam Chappell,
>> Jeff Haas and the authors, we came up with the following text to address
>> the above raised concern.
>>
>> This will be part of -04.
>>
>> """"
>> 5.  Reserved Large BGP Community values
>>
>>    The following Global Administrator values are reserved: 0 (the first
>>    ASN) [RFC7607], 65535 (UINT_MAX) and 4294967295 (the last ASN)
>>    [RFC7300].  Operators SHOULD NOT use these Global Administrator
>>    values.
>>
>>    Although this document does not define any Special-Use Large BGP
>>    Communities, the Global Administrator values specified above could be
>>    used if there is a future need for them.
>> """
>>
>> A preview of the -03 / -04 diff is available here:
>>
>> https://htmlpreview.github.io/?https://github.com/large-bgp-communities/large-bgp-communities/blob/master/draft-
>> ietf-idr-large-community-04-from-3.diff.html
>>
>> Kind regards,
>>
>> Job
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr