Re: [Idr] Fwd: New Version Notification for draft-raszuk-wide-bgp-communities-05.txt

Robert Raszuk <> Mon, 09 March 2015 21:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2E7031A90BE for <>; Mon, 9 Mar 2015 14:42:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Crf9Gdx2r1tm for <>; Mon, 9 Mar 2015 14:42:31 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4B6391A901F for <>; Mon, 9 Mar 2015 14:42:13 -0700 (PDT)
Received: by igjz20 with SMTP id z20so25390213igj.4 for <>; Mon, 09 Mar 2015 14:42:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=n0DLaYO4+BH3MdbS18qq38AkH+uQAHEA+XaxCv/roGw=; b=Cvip7JkKp+UVbJPJFoovUDUSo4I5VO2hdxlRpbih4YybuhC+3OYKVQXtV/OFOh4Gdy 5uD1xFgkGVggnsrIdzHTRZ7QLZ7n0VhzFgMSdLAOqr+PCiS8hu+8rINTu27GMF4PCB15 mUG5cYVOuD7ETVt4abVGvLlctyCcjpSIlsixcnwclBam4U2n81EDmPhZjEY1TuZ+S0xY LrUFIEqTN1k9yurmmAOBTlzUC4iUPPRZUzWn+MCOBn9ysITnHAG0LDMMGCUBN8ElMVDD 6mPAaLefpQHf7OFzJ497luP2+SQaTb5fHErAf7rwFo3ZCve1r9Vou75RrRIZMG7LNaD9 jPUA==
MIME-Version: 1.0
X-Received: by with SMTP id qh3mr74091886igb.9.1425937332819; Mon, 09 Mar 2015 14:42:12 -0700 (PDT)
Received: by with HTTP; Mon, 9 Mar 2015 14:42:12 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Mon, 09 Mar 2015 22:42:12 +0100
X-Google-Sender-Auth: PH37CP0c9h9ppchzaRUr_IdwaOI
Message-ID: <>
From: Robert Raszuk <>
To: Nick Hilliard <>
Content-Type: multipart/alternative; boundary="001a11c3bcbc31de1a0510e1e859"
Archived-At: <>
Cc: idr wg <>
Subject: Re: [Idr] Fwd: New Version Notification for draft-raszuk-wide-bgp-communities-05.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Mar 2015 21:42:33 -0000

Hi Nick,

wide-bgp-communities is a great idea in theory, but it's far too
> complicated in practice.  This means that it will be difficult to code, to
> debug and to get good quality vendor interoperability. It also presents the
> operator with a bewildering range of options, many of which are unlikely to
> ever be used.

​Well we have tried to make it to include build in algebra for the last few
years .. finally we reverted to original basic encoding idea.

I think at this stage the encoding proposed is pretty easy to code.

However the policy of any implementation needs to be able to handle local
actions as well as registered and private types/definitions.

If this it too complicated in practice I do not know. Many people says BGP
is complicated, but for me it is as simple or as complex as one makes it to

But we are open for comments and contributions from everyone here.

> The complication in the specification also creates a secondary problem for
> router vendors in updating their policy languages so that they can
> interpret wide bgp communities.

​Indeed .. just like I mentioned above. The use flexibility is in the
policy language and parser. Good news is that current version seems to get
thumbs up from many vendors. ​

> Overall, this is not compatible with the engineering principal of "keep
> things as simple as possible - but no simpler".

​Not sure I get that one. Are you saying if we follow what you suggest
below it will meet such criteria or regardless it will stay incompatible ?

I do encourage to read the companion draft showing registered types for the
use cases. I am not sure how much simplere those could be ...​

> 1. Would it be possible to ditch:
> >      Type  5: IEEE Floating Point Number list
> >      Type  6: Neighbor Class list
> >      Type  7: User-defined Class list

​Well if you ask me I am all for it. No issue.

​That is also the reason why we demux at the types below the attribute. If
tomorrow someone comes and says I must have floating atoms there is no need
to define new Wide BGP Community attribute with those.

> 2. Simplify, or at least explain why this needs needs to be so complicated:
> > 4. Container Type 1: Wide Community

​Just explained above. ​

> 3. provide some guidance about deletion or modification of parts of the
> community attribute entries, particularly in the context of:
> >    The Wide BGP Community Attribute is an optional, transitive BGP
> >    attribute, and may be present only once in the BGP UPDATE message.

​Not sure what you mean by "parts". The deletion at least the way I see it
should be per type (registered or private) or per attribute. ​

> 4. discussion of how implementing this is going to shake out structural
> problems in vendors' routing policy grammars, with associated security
> implications if the grammars are incapable of handling the complication
> that this draft introduces.

​Indeed this is vendor dependent.

But should we stop propose anything in BGP if anyone would have a problem
implementing it ? I was under impression that two implementations are
enough for IDR to progress the doc to last call. ​

> 5. I love the idea of UTF8 communities.  On smaller network, these could be
> a real win.


6. I'm guessing that the structure of container type 1 is designed to

> accommodate the <prepend X times Y ASN at location Z> construction that's
> widely used on the internet.  This requires a pretty serious grammar to
> allow for proper parameter checking.
​I think you did not read the companion draft :) Please do.

Yes this is one very fundamental use cases here.

Many thx for your comments,

> Nick