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

Mikael Abrahamsson <swmike@swm.pp.se> Thu, 20 October 2016 06:03 UTC

Return-Path: <swmike@swm.pp.se>
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 ABA1F12952E for <idr@ietfa.amsl.com>; Wed, 19 Oct 2016 23:03:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.432
X-Spam-Level:
X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 Yp_0MCAT6RhB for <idr@ietfa.amsl.com>; Wed, 19 Oct 2016 23:03:29 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E8B4129441 for <idr@ietf.org>; Wed, 19 Oct 2016 23:03:29 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id E05A9A2; Thu, 20 Oct 2016 08:03:25 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1476943405; bh=Fe2cbxaaISxKeNcAnQr4EDtIAIZUYrYjEMjcu3+uxTk=; h=Date:From:To:Subject:In-Reply-To:References:From; b=JjKI2dgBppjdKVfC0l16bT8LPFJVG6sH+8gYGcXn29kM/kzqzGBOfc3dNSl0tvY6b SGE7sfDyH1eY100NtkvQhUN7lQ7mYOp2C6RrYSPM8VLUmBOpENc5GNwAJADPc7OjeA dcw//ZQTSPThtRcgPO7xUv1uZQKOxyBIhP8YJJJE=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D5FDBA1 for <idr@ietf.org>; Thu, 20 Oct 2016 08:03:25 +0200 (CEST)
Date: Thu, 20 Oct 2016 08:03:25 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: IETF IDR WG <idr@ietf.org>
In-Reply-To: <CAH1iCipd+wyFVwvunjVFxF1t52j3_sKm5efGXzNH8xwHLndaHQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1610200756430.12036@uplift.swm.pp.se>
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> <CAH1iCirF_1ODLtLzeVhKmQPDeeGcczcQCSPXDcro=OQv2ipR3A@mail.gmail.com> <5807F3AF.9080200@foobar.org> <CA+b+ERn_7Bs8CeAgKrxSPiMPOCsE4pH9hoD+76tEDrWM-KYVRw@mail.gmail.com> <CAH1iCirF2C-83z3hYC4bBqMYW7zHs1eeofySVipyODo=8FNQxg@mail.gmail.com> <CA+b+ER=oyCTF24f1pAQQjA0ogMCtqw0rKWzT7+jcNpL4WjPjHQ@mail.gmail.com> <CAH1iCipd+wyFVwvunjVFxF1t52j3_sKm5efGXzNH8xwHLndaHQ@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/hpwbJu2ufG8wUKe-zBah2si5D08>
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 06:03:31 -0000

On Wed, 19 Oct 2016, Brian Dickson wrote:

> Yes, the implementation should still "allow any value".

When I have created BGP route policies, I've several times asked myself 
the question "what will the vendor implementation do itself, and what do I 
need to do in my policy".

So for instance, do I need to implement the well-knowns myself, or is that 
something that I need to do in my policy? If I for operational reasons 
want the router to not do something (for instance I do want NO-EXPORT to 
traverse AS boundary), how do I do that?

I think here in the IETF we should always consider to have separate 
documents for what goes on the wire (compatibility reasons), and what the 
implementation should do with this information by default in case the user 
also can set policy.

The contents of the -large- fields and whether the implementation should 
check if this is true is a typical thing that the "wire" document should 
not over-specify. That should instead be an operational document, and that 
should involve GROW as well.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se