Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)

Ignas Bagdonas <> Thu, 26 May 2016 14:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ABF6012D0E8 for <>; Thu, 26 May 2016 07:21:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 XzhkFhUV1jeY for <>; Thu, 26 May 2016 07:21:14 -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 27E4E12D6E6 for <>; Thu, 26 May 2016 07:21:09 -0700 (PDT)
Received: by with SMTP id n129so229646875wmn.1 for <>; Thu, 26 May 2016 07:21:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=mPAY1sI1mQJA2xrxJ+eN1qrdZqOjke+z6o4RMBXIjVg=; b=lPqndw8Q2iS4QP67Sr2WGpBx1hlmaBswNibqBupMndvfPfv00t0Z6hnaJBd6bggG74 3TUIyrGFuW//mXaAUetzGgQLFOzw0sqq+8n+ETfJ0auGg2NFS5OaVDju2cwGCB1wqnrI 3UbUjjdwYXJCqZUSd7pX9U/IoeQOmqDOAFnr4Pk8HCJvDNw73G6v+TllxunQqVN5yRzT 1wL555SUmYDh9BumMNUESfbXEYthz+gFMOx63es3XG9f/t8DE50JMfyLkEJAcbt/xhac E+TXQAa+UhjBJZ51QvI/IllVS0lMIPavhW3F0Guqg3GpSuoqNEx4sVNBEh3g3FO48vC9 Z7kw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=mPAY1sI1mQJA2xrxJ+eN1qrdZqOjke+z6o4RMBXIjVg=; b=Bl1N1X9Yr0g+aL5c1UVDrF/aZNyPiDquyjT5o0DViLalzSbWQBP0uVCA9axbb/9VuW aMLXKZNJKW28uKqWdcJgrh7kKiEbQdCn1Z5DrKJBP7TdTH1DX9FmENGtSZhbz1JZfGzS +rfP9GaIblQQS+sOZMt317IVno/L2GVGWfujWpa55YYEFnIwhPRTVLv85yYzy0oeXOHc t4wDz9Uiw93Gh26HGTyWUAi+t7/CrvUtJ5rIpKkgFqoqIchxDEpzx5o6+2VKz/vzJjmH 2xXk431G/7CRkl8BjEoesQxLSI3BU8cY2xZt4GNwsg4M7EhPP3gOXO+wk3P1lpOjD1yP hZEQ==
X-Gm-Message-State: ALyK8tLYX8lnmenBA54iqvYjrmK4OZJ+feS6UJ6hsNmx9b0GrwwI7rC0QSzbxWV7RAGVKQ==
X-Received: by with SMTP id rk16mr9491447wjb.63.1464272467617; Thu, 26 May 2016 07:21:07 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id w10sm14621800wjk.18.2016. for <> (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 May 2016 07:21:06 -0700 (PDT)
References: <037f01d1b5fc$bfb596f0$3f20c4d0$>
From: Ignas Bagdonas <>
Message-ID: <>
Date: Thu, 26 May 2016 15:21:04 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <037f01d1b5fc$bfb596f0$3f20c4d0$>
Content-Type: multipart/alternative; boundary="------------030509080202090404080005"
Archived-At: <>
Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)
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: Thu, 26 May 2016 14:21:17 -0000

I have read the draft and support the publication.

Some assorted comments:

- s/RFC4221/RFC4271, and remove reference of RFC4221.

- Section 4, third paragraph talks about the propagation path. How would 
such a path be known in advance of the propagation? This seems contrary 
to a normal multipoint flooding mode of BGP operation.

- Error handling in the environment with old style and extended messages 
capable peers. There could be several scenarios advertising received 
extended messages to an old style peer:
-- Single NLRI itself is longer than 4096 (opaque key-value AFI as an 
example). It is not possible to send it to an old style peer at all, 
should be dropped and logged.
-- Single path attribute is longer than 4096. Removing such attribute 
would leave no place where to put partial indication. Would see dropping 
and logging to stay consistent with the NLRI case being a practical 
-- The sum of path attributes is above 4096, while each path attribute 
is shorter than 4096. This seems to be the least deterministic case, 
likely it will be optional attributes that exceed the length, with local 
node having no knowledge based on what criteria to remove which 
attribute from propagation. Also this is not specific to extended 
messages. Behaviour today seems to be left to implementation detail. 
Should be logged and possibly dropped, leaving to the implementation 


On 24/05/2016 21:42, Susan Hares wrote:
> This begins a 2 week WG LC on draft-ietf-idr-bgp-extended-messages 
> (5/24 to 6/7). The draft can be found at:
> In your comments please provide the following information:
> 1)Support/”no-support” of this draft being ready for publication,
> 2)You know of an implementation for this draft, please report the 
> implementation to the IDR Wiki
> 3)Do you have any concerns about extending the BGP messages.
> Sue Hares and John Scudder
> _______________________________________________
> Idr mailing list