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

Julian Seifert <js@dacor.de> Fri, 21 October 2016 22:35 UTC

Return-Path: <js@dacor.de>
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 17CEB1296AB for <idr@ietfa.amsl.com>; Fri, 21 Oct 2016 15:35:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.332
X-Spam-Level:
X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-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 kWM2w3vAWG0A for <idr@ietfa.amsl.com>; Fri, 21 Oct 2016 15:35:55 -0700 (PDT)
Received: from relay.dacor.de (relay.dacor.de [217.24.56.24]) by ietfa.amsl.com (Postfix) with ESMTP id 0E40912968C for <idr@ietf.org>; Fri, 21 Oct 2016 15:35:55 -0700 (PDT)
Received: from exchange.dacor.de (astaro1.dacor.de [217.24.48.66]) by relay.dacor.de (Postfix) with ESMTPS id E5B91E3019; Sat, 22 Oct 2016 00:35:53 +0200 (CEST)
Received: from ex02.suecdacor.local (192.168.1.16) by ex02.suecdacor.local (192.168.1.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 22 Oct 2016 00:35:53 +0200
Received: from ex02.suecdacor.local ([::1]) by ex02.suecdacor.local ([::1]) with mapi id 15.00.1210.000; Sat, 22 Oct 2016 00:35:52 +0200
From: Julian Seifert <js@dacor.de>
To: Robert Raszuk <robert@raszuk.net>, IETF IDR WG <idr@ietf.org>
Thread-Topic: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)
Thread-Index: AdIotF10Qx6LizvwQ9uItB9ryESdDv//9v8AgAFk3oCAAAHRgIAAFxgAgAM7eACAAAPtgIABHqgAgAAGaoCAAI7duw==
Date: Fri, 21 Oct 2016 22:35:52 +0000
Message-ID: <1477089344939.73454@dacor.de>
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>
In-Reply-To: <CA+b+ERkV2PBtzzx=uoygDzvTyJzunROCNX=0Y4phvGdn=oK5Xw@mail.gmail.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [88.133.178.43]
Content-Type: multipart/alternative; boundary="_000_147708934493973454dacorde_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/sX_WB7BcKDsy5OUjGIJm7G5xZok>
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 22:35:57 -0000

Hi Robert,


I think there is no need to complicate this, in my opinion, simple issue.

We need <THING> to encode information in an easy way that we can append to a route.

The LC allows us to encode information using 12 Octets which allows us a lot of encoding.

It's separated into 3 fields which should(!) be used in a certain way but must be allowed to

be configured to any* value. Why? Because that's what communities are being used for already

and we simply need a bigger space for that.

(*any except those that might be defined as reserved)


There might be migration or other scenarios where enforcing the values of some of the fields might make things more complicated than they need to be. For example when one merged and changed AS-number but doesn't want to change the communities he send or

still wants to be able to receive the "old" as-value communities.



We currently do not check/enforce values of rfc1997 communities. That is only being done

by operator defined policies on the routers and this should stay this way.

We want to continue to do that and simply need larger communities so we can continue doing

what we do with 4-Byte AS-Numbers. So there should be 3 fields of 4 Octets that can be set to any value

and can be used on routers in policy definitions - quite simple.


There is nothing won by enforcing anything it's only making the issue more complex than it needs to be.


Let me ask, what do we gain by enforcing the restrictions on the values?

I think the idea of the draft was to have a tool like we have with rfc1997 but

with larger/more fields to accommodate for 32byte as-numbers.


kind regards,


 Julian