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

John Scudder <> Sat, 22 October 2016 14:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6EDE8129665 for <>; Sat, 22 Oct 2016 07:11:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Bn2Bx_8-A5bd for <>; Sat, 22 Oct 2016 07:11:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C341C12943D for <>; Sat, 22 Oct 2016 07:11:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ets54fzt3OUDq6j5B24RlqxnzViy0I/oBk/lCPD8Lr8=; b=Y52LrZvPRxEaePqL4NuC/jlwLC5Hsoho5AL8/5spuoTwBN9byiOsQJQgfaMvvN1RflWUablIf+uT7/fh36FzR0r6qRqEIlLKPp9JQlNsr1DDvOsywVj4MaSO7/sg5gHBqVSy4Yc9ObJddSkjYxkBkXE+u7yhU3UvvBwLj/djhrM=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Sat, 22 Oct 2016 14:11:19 +0000
Received: from ([]) by ([]) with mapi id 15.01.0679.006; Sat, 22 Oct 2016 14:11:19 +0000
From: John Scudder <>
To: Robert Raszuk <>
Thread-Topic: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)
Thread-Index: AQHSLF+rFZx4XPdf1UmaMSzslCIymKC0fnqAgAAFGBc=
Date: Sat, 22 Oct 2016 14:11:19 +0000
Message-ID: <>
References: <01f301d228b4$e3319ef0$a994dcd0$> <> <> <20161018191521.GT95811@Vurt.local> <> <20161020215938.GE1074@Vurt.local> <> <> <> <20161022122735.GC79185@Space.Net>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-ms-office365-filtering-correlation-id: 298c4d20-4e4f-4c54-6092-08d3fa854b8f
x-microsoft-exchange-diagnostics: 1; CY1PR05MB2507; 7:65z01UaI0hLgUCNjzm5S1DJtm5iGQfHrQxP1yV8gMu4jk9houlB6zyc6rS4zzj1dR3DYOla8cnNh02tBLDpXxOK02zbrv4xPRtE8fwFLxL3Ng5BwHIQYYaojBTS4DhpNP3fIbLFGgC3GsqrMaMUFWZt+yvPT1NQ0JVzqCn75JOcs1jfcB4eqXgtq0UioBTZaEE9PApNdy7MJ1BqAfBT4+gc6eZexk1xV9Y+jV/JCJG2yO0N9CMrCijWfITRshEEr+mN4ew2gzvGXSbEs0iBmu33QV3g+P/L/0cfP0PsNKlrLkQzVMFiJbFtxiDby79/+4iSKFFwO/l4BBJ81pocE/3ohf9U0iKan2Fgvyqq3wBw=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR05MB2507;
x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(100405760836317);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:CY1PR05MB2507; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2507;
x-forefront-prvs: 01039C93E4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(199003)(5423002)(377454003)(189002)(106356001)(92566002)(33656002)(19580395003)(99286002)(8936002)(10400500002)(19580405001)(230783001)(15975445007)(122556002)(7736002)(5660300001)(2900100001)(7906003)(106116001)(110136003)(11100500001)(97736004)(7846002)(4326007)(5002640100001)(2906002)(77096005)(66066001)(105586002)(54356999)(6116002)(3280700002)(3660700001)(93886004)(586003)(83716003)(76176999)(3846002)(6916009)(86362001)(36756003)(2950100002)(82746002)(102836003)(189998001)(81156014)(81166006)(68736007)(8676002)(16236675004)(87936001)(50986999)(19617315012)(101416001)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2507;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D6D63A9E3AF240F7B3FB923BEC0EBB8Fjunipernet_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2016 14:11:19.2972 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2507
Archived-At: <>
Cc: EXT - heas <>, IETF IDR WG <>, Susan Hares <>
Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 22 Oct 2016 14:11:23 -0000


"Yes RFC1997 works like that but here we have opportunity to improve it."

When the working group accepted the draft as a work item, I think it was pretty clear from the extensive conversation at that time, that the intent was to replicate RFC 1997, not to improve it. In fact, improving it was an explicit nongoal if I remember right. One might argue that was a bad goal have, and I think you did make that argument at the time, but the working group consensus was otherwise.

Of course, consensus can shift over time, and WGLC is a good time to test whether such a shift has occurred, so I don't think it's inappropriate for you to have raised the question again. However, at this point it appears to me that consensus has not changed.

If you feel further conversation would be productive, I don't mean to foreclose on that, but I thought it might be helpful to provide an update about where it appears to me the consensus is trending at present.


On Oct 22, 2016, at 9:53 AM, Robert Raszuk <<>> wrote:

You are mixing SRC_ASN with TARGET_ASN in the same field.

Yes RFC1997 works like that but here we have opportunity to improve it.


On Oct 22, 2016 2:27 PM, "Gert Doering" <<>> wrote:

On Fri, Oct 21, 2016 at 05:42:37PM +0200, Robert Raszuk wrote:
> > 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"
> Why not ?
> If you do not make those 4 octets configurable by spec and always fill it
> with AS number defined in your BGP instance you will have assurance it
> is ASN of the entity that defines the rest 8 octets of the LC as otherwise
> you will likely not establish any EBGP sessions to your peers.

But that is only half the intended usage of communities - one is
"I tag it with <myas>:<some meaning>" to signal something to my own
routers or my customers.

The other one is "I tag it with <jobs as>:<some meaning>", and there is
no way for my router to validate that "<jobs as>" is indeed the one
who defined "<some meaning>".

So, how exactly is the vendor to check variant B?

(And if you do not understand what people use communities for, today,
maybe you should not be argueing these points, sorry)

> So there is very easy way to enforce it today in any BGP implementation.


Gert Doering
        -- NetMaster
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279
Idr mailing list<>