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

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Fri, 21 October 2016 05:23 UTC

Return-Path: <jheitz@cisco.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 D2C781294EA for <idr@ietfa.amsl.com>; Thu, 20 Oct 2016 22:23:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.952
X-Spam-Level:
X-Spam-Status: No, score=-14.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 arAiN0gQsl8r for <idr@ietfa.amsl.com>; Thu, 20 Oct 2016 22:23:43 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D448129483 for <idr@ietf.org>; Thu, 20 Oct 2016 22:23:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1633; q=dns/txt; s=iport; t=1477027423; x=1478237023; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/qdYp567B0YjtW0Ac5TEz2d7cR3XivWVjNa1tgOoUvY=; b=GQ5lxPstUz6f5mcM4q0NqX3Hpe2Dw8BQoctof/V5cShKe+2II8mx3W0b VN6hoEfClAXE+nQ4a5+m2/NHqAeta8psF93NDDRAJ9Y9/nQVgE3UEcr0E /GWhjRWoKFfJ4gZTztx71MM8/60jAHIOiGdC1bXqTLSDrf84X9rKRV/YM Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B8AQAepglY/4kNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgz4BAQEBAR1XfY00lnyUPoIHHAuCRIM2AoF2PxQBAgEBAQEBAQFiKIR?= =?us-ascii?q?iAQEBAwEBAQE3NAsFCwIBCA4KHhAnCyUCBA4FFIg2CA7DLgEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARcFhj2BfQiCUIQZEQEcgzCCLwWIR5FLAZAMj32NAYN/AR42WYN?= =?us-ascii?q?GgTpyhiiCIAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.31,374,1473120000"; d="scan'208";a="338358808"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Oct 2016 05:23:40 +0000
Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u9L5NeEn019234 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 21 Oct 2016 05:23:40 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 21 Oct 2016 00:23:39 -0500
Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Fri, 21 Oct 2016 00:23:40 -0500
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Thread-Topic: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)
Thread-Index: AdIotF10Qx6LizvwQ9uItB9ryESdDgANiv0AACybzYAAADoegAAC4vMAABNp+sQAGz+KgAAB1DGAAAWtwoAAAEbugP//uo5zgABbxgCAAGZngIABM2it
Date: Fri, 21 Oct 2016 05:23:40 +0000
Message-ID: <3CFE82FB-8A77-46E4-8459-C428E9B93BD6@cisco.com>
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>, <alpine.DEB.2.02.1610200756430.12036@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.2.02.1610200756430.12036@uplift.swm.pp.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
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/AJHkqvgRXJnpSQQt_tAvJv0Fghs>
Cc: IETF IDR WG <idr@ietf.org>
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 05:23:45 -0000

This is a matter for your vendor documentation.
In the case of IOS-XR, the router software acts upon the well-known communities. For example, no-export is acted upon before the neighbor outbound policy is run.

Thanks,
Jakob.


> On Oct 19, 2016, at 11:03 PM, Mikael Abrahamsson <swmike@swm.pp.se>; wrote:
> 
>> 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
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr