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

Robert Raszuk <> Fri, 21 October 2016 18:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 73D821296F7 for <>; Fri, 21 Oct 2016 11:55:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qiOqXkFy8SXH for <>; Fri, 21 Oct 2016 11:55:19 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2C8971294C6 for <>; Fri, 21 Oct 2016 11:55:19 -0700 (PDT)
Received: by with SMTP id f193so1328345wmg.0 for <>; Fri, 21 Oct 2016 11:55:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=dZFgyg+DsbJO9nVZaV1zIdTQYkoRdGWrKoJ3/gAwBtA=; b=a7JfeGEdZVZuN/KtXo0Y/cARy2Dcv46Q6vFoIw5G4ZeiVcx1s5rfjSy0hvcPuvQXR3 PEUJX+7vullujaqtnImZgKrgDSRVMJp9x56HswegXApmtO7agRusqYIXuAryXb+lkBJI 6r5LwYySMjjYzBro3elD3abr+D2D9Qxc7eCtjz+qOeALjGOc5IoiBieuHgX1kT4X04QH sd3CF5G4DJDx5ZwYdipLMdFc1lwi4UgZB8oStj2sCY5irmDXvQjCtXRKLHtGv2xTKp6s V4+3hVjvuBLayiCNqmijKrLz6Lt4JA9AzgMG+K86vam0M+2oov05LvhVXB2dIF98M4IA ai/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=dZFgyg+DsbJO9nVZaV1zIdTQYkoRdGWrKoJ3/gAwBtA=; b=ESrm3kkKiSyy2H/xvhJ/m34d9D21W+UlGss94/JqkwuNALW95SjTNt4coCQU/tVCcN cnpwzBdpFKk7Q1iWCYH0Gb5b6Tq6gfhhgZKLSNkHAUt9Sua5DNk3mAgkejmnlxNpFAEw SiPE8RERxDIzpxYRXnHH1sBDI9HPuyy/0LvbHaMcVVZNs5+SjTwG3jtF5W5x5rdDClMa 4If1ltqZ86JU85u+HKpm/dDkIqQLq8Ier2gUsxpoo7ivVa1ihuS8mvtGsXJUh1nZDhdh EaWZU+BmfN+NCq3e0fXUvFHH2YjaKDxyvmM7rFBDvySWTBL7F1QHgdLABpJQn7ckGqJa rKXg==
X-Gm-Message-State: ABUngvdfHuGn8uuR9yKqK/JsTicbuMRnt+GK7BFlFeh0xpFVRwWddz6pMAvVss5ZUkCq69cqFUM9NgWG98EN1g==
X-Received: by with SMTP id df8mr1859176wjb.227.1477076117627; Fri, 21 Oct 2016 11:55:17 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 21 Oct 2016 11:55:15 -0700 (PDT)
In-Reply-To: <>
References: <20161018191521.GT95811@Vurt.local> <> <20161020215938.GE1074@Vurt.local> <> <> <> <> <> <> <> <20161021164241.GC32387@Vurt.local> <> <>
From: Robert Raszuk <>
Date: Fri, 21 Oct 2016 20:55:15 +0200
X-Google-Sender-Auth: BnfdU7UjvkgBNGcJxYL_EFnPgX0
Message-ID: <>
To: " - Martijn Schmidt" <>
Content-Type: multipart/alternative; boundary="047d7bb03aae4c27fa053f649534"
Archived-At: <>
Cc: idr wg <>
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: Fri, 21 Oct 2016 18:55:23 -0000


First I think you need to know that all original authors of LC agreed that
the proposal does not solve the community values overload issue. If you and
others were sold on something different then perhaps there is some
disconnect. That is also why some time back I proposed for LCs to have
4x4octets such that today's necessity to overload 1997 can be relaxed.

For stub networks if they get only default route there is no issue as they
will not be getting any LCs.

For ASes which use private_ASes as I already mentioned it is trivial to
treat it in the same way as it is treated in the AS_PATH today. Basically
you would replace your customer private AS with your public AS both in the
AS_PATH and in the first 4 octets of LC.

To conclude ...

There is simply two ways

-A- your 3x4 octets are completely unstructured and you use them as it
seems fit


-B- It is structured and draft/rfc specifies what goes into first 4 octets
(say SRC_ASN) and what goes into second 4 octets (say TARGET-ASN) leaving


On Fri, Oct 21, 2016 at 8:01 PM, - Martijn Schmidt <> wrote:

> Hi Robert,
> Briefly continuing the earlier discussion for originating routers - stub
> networks which exclusively receive a default route from my full table
> router don't have complete AS_PATH information. That means the device won't
> be able to determine whether or not the configured GA field corresponds to
> an ASN in the DFZ.
> If we decide (on a protocol level) to filter the LC information on the
> receiving LC-speaking BGP router instead of the originating router you'd
> limit the transitivity and therefore the usefulness of the Large Community
> feature. Let's say that AS65500 wants to send a community via AS49544 to
> AS2914. Upon receipt of the BGP_UPDATE, the AS49544 router will check the
> Large Community attribute and notice that 2914:x:y is attached while AS2914
> is not in the AS_PATH. It would then have to strip the Large Community and
> AS2914 would never receive the Large Community attribute.
> Simply stating that "implementations MUST allow the operator to specify
> any value for the Global Administrator field" is the correct way forward,
> the suggested SHOULD wording either can't be enforced by vendor-side checks
> (and therefore belongs in a BCP/GROW document), or is - in the way you've
> suggested it - in direct conflict with the intended use of the Global
> Administrator field.
> Best regards,
> Martijn
> On 10/21/2016 06:49 PM, Robert Raszuk wrote:
> Hey Job,
> That's what I thought ... but if so I do not get why there are so many
> discussions of any MUSTs/SHOULDs/MAYs operators are expected to follow on
> in the fields LCs provides.
> If they are opaque that means there is zero structure in place and
> everyone is free to put whatever he/she likes in it .. even hex encoded
> Morse (
> We either allow all opaque and free style or we structure fields such that
> for example they may be used in simple parametrized BGP in/out policy
> example I provided.
> And the excuses type "oh we can not structure it as there is no way to
> insert valid ASN" are wrong as there is a way as proven :)
> Cheers,
> R.
> On Fri, Oct 21, 2016 at 6:42 PM, Job Snijders <> wrote:
>> On Fri, Oct 21, 2016 at 06:29:46PM +0200, Robert Raszuk wrote:
>> > The policy example was nothing to do with BGP table. If I am receiving
>> > BGP_UPDATE it comes with AS_PATH and may contain LC. So if I want very
>> > simple policy to filter trash of LCs I can set it to match first 4
>> > octets to any ASN present in the same UPDATE MSG AS_PATH attribute. If
>> > it there I do not drop LC.
>> A clever trick, but not a good fit for Large BGP Communities. Large BGP
>> Communities are opaque, by definition and design.
>> We want routing policy in which networks can send 2914:X:Y to us, and we
>> can send 2914:A:B to them - very much like RFC 1997 communities. The
>> Global Administator field does not necessarily contain the ASN of the
>> sending party.
>> Kind regards,
>> Job
>> _______________________________________________
>> Idr mailing list
> _______________________________________________
> Idr mailing listIdr@ietf.org
> _______________________________________________
> Idr mailing list