IETF Logo Mail Archive

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> Sat, 22 October 2016 10:39 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 BED36129553 for <idr@ietfa.amsl.com>; Sat, 22 Oct 2016 03:39:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.879
X-Spam-Level:
X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 w33zazvwPclU for <idr@ietfa.amsl.com>; Sat, 22 Oct 2016 03:39:48 -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 89B2112954D for <idr@ietf.org>; Sat, 22 Oct 2016 03:39:46 -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)) for idr@ietf.org; Sat, 22 Oct 2016 12:39:41 +0200
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> <ae5da282-201c-f745-9f26-67ce73826bd5@i3d.net> <CA+b+ERkV2PBtzzx=uoygDzvTyJzunROCNX=0Y4phvGdn=oK5Xw@mail.gmail.com> <20161021154958.GR27221@gir.theapt.org> <CA+b+ERmrzCtFLP98D0YzRc-BJNbBWp3Ce6yKZr2cg1_QS0Oz5w@mail.gmail.com> <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> <CAH1iCirkxRXqe0-7=NEjRuO46Kv+GfMASuDJxCXngMRU2c7kAw@mail.gmail.com>
Cc: IETF IDR WG <idr@ietf.org>
From: "i3D.net - Martijn Schmidt" <martijnschmidt@i3d.net>
Organization: i3D.net
Message-ID: <25cfd19e-cf33-7380-89c0-d11bc6128139@i3d.net>
Date: Sat, 22 Oct 2016 12:39:42 +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: <CAH1iCirkxRXqe0-7=NEjRuO46Kv+GfMASuDJxCXngMRU2c7kAw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------266118145461F2B844BD6BA2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/eT8O-yDq5bffvQvqlIB6lGjZm6o>
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: Sat, 22 Oct 2016 10:39:50 -0000

Hi Brian,

Doesn't the existing wording "The Global Administrator field is intended
to allow different Autonomous Systems to define Large BGP Communities
without collision." already achieve what you want, if you feel that
RFC2119 language is not necessary?

Best regards,
Martijn

On 10/22/2016 12:15 AM, Brian Dickson wrote:
>
>
> On Fri, Oct 21, 2016 at 9:21 AM, i3D.net - Martijn Schmidt
> <martijnschmidt@i3d.net <mailto:martijnschmidt@i3d.net>> wrote:
>
>
>     Summarizing, any restrictions which can not be enforced don't
>     belong in the IDR document because they're irrelevant to
>     implementors. Arguing about it doesn't change the fact that such
>     recommendations belong in a BCP/GROW document. It is that simple.
>
>
> I'd like to pick a nit with the argument here, as a counter-point to
> what I think needs to be in the document.
>
> There are plenty of IDR-specified things that are not enforced or
> enforceable, which are nonetheless necessary to define or specify.
>
> Those include things such as:
>
>   * next-hop
>   * router-id
>   * cluster-id
>   * AS-path component(s) [injecting ASNs via prepend mechanisms]
>   * MED
>
> Including Global Administrator (with a definition of it as _being_ an
> ASN), is all that is required -- if necessary, rewording it to not use
> RFC 2119 language. 
>
> Like all of those other things, they can be set by operators, and are
> not able to be enforced without severely restricting operators'
> activities.
>
> Implementors who apply restrictions on those, may encounter resistance
> from their customers, their sales folks and potential customers, and
> their customers' peers.
>
> Brian

-- 
Met vriendelijke groet / Kindest regards,
Martijn Schmidt


i3D.net performance hosting 	
*Martijn Schmidt | Network Architect*
Email: martijnschmidt@i3d.net <mailto://martijnschmidt@i3d.net> | Tel:
+31 10 8900070

*i3D.net B.V. | Global Backbone AS49544*
Van Nelleweg 1, 3044 BC Rotterdam, The Netherlands
VAT: NL 8202.63.886.B01

Website
<http://www.i3d.net/?utm_source=emailsignature&utm_medium=email&utm_campaign=home>
| Case Studies
<http://www.i3d.net/partners/?utm_source=emailsignature&utm_medium=email&utm_campaign=case-studies>
| LinkedIn <https://www.linkedin.com/company/i3d-net>

v2.23.0 | Report a Bug | By Email