IETF Logo Mail Archive

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

Robert Raszuk <robert@raszuk.net> Wed, 25 May 2016 15:54 UTC

Return-Path: <rraszuk@gmail.com>
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 A64A812D561 for <idr@ietfa.amsl.com>; Wed, 25 May 2016 08:54:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level:
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 jERCe4MgKj48 for <idr@ietfa.amsl.com>; Wed, 25 May 2016 08:54:48 -0700 (PDT)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2A3712B015 for <idr@ietf.org>; Wed, 25 May 2016 08:54:47 -0700 (PDT)
Received: by mail-lf0-x229.google.com with SMTP id e130so20116820lfe.3 for <idr@ietf.org>; Wed, 25 May 2016 08:54:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=9u0t5BTrruukpGc9GKTUEAAKqN+zVa6SHjsDdDS2FUc=; b=PxY5e7OZ0OSjD2e5535wwBP5ERiTBA97c7uFAiVe2JmDLk0BiwwOhlKeylLDt87MWG UrNl+zfvGfc1bIdiViNoNvywoJML9EhnqCPgHp2qv7LCmJdBntMlLtoHnuujsEUJAPyz OvhCO3a/FDH3qMs8XIBwVNVJms0Kl5HTnhEjQnMuoqTVpd4ZxAXkMmg4eNQrMzg7Lepg wSILw6/k4ejWA5AVZlBE6hrEXWLXPBtZjXQ9FCC8riyYshfmAL2HSK6qO9kuI9GO0+/p r+nJLoOt3zshJWOtqUD36BZ9tdBIj4tsZq8qzvpgCCW2XxYdcYRG3iUQxX48PlNTg5f+ 6XCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=9u0t5BTrruukpGc9GKTUEAAKqN+zVa6SHjsDdDS2FUc=; b=msGZZOlkyekJIjzSo+xX/+Kwe+wZRg2y5Pn/0N9ACSIGKwlZrMeSaT/M4/47975CDk zclpfSzixEceTzLddjIL90n/klpnk/G2ZqXjXmgEshRbbJWyaKISeFnUltYdrHNfZHAQ KK7jt4wG1EEyG3liiz4gLoIl2wYQzvg3uHgJldLlalIUyglr2Tx7DCHmx/polLVHobb5 raeTerH0BzY62qVh71Z1IEiBSiWQna+iY8BfNSjEao4i45l2p+kmElRuwVYEc0+1uacU PhKCUUDmdRsa55gcuufwwVECiXWHDSSqAvosdZupKCVvKzaV4B4bzMOBmhc/2WlJbEee kk+A==
X-Gm-Message-State: ALyK8tKAwi+St0njlPB2YAilmoAVPWM8oreZ3RB6W+0m4AngmkOD617bHO4rBE8+s288fTwtdvwe+4de9heprw==
MIME-Version: 1.0
X-Received: by 10.25.91.140 with SMTP id p134mr1043579lfb.181.1464191685686; Wed, 25 May 2016 08:54:45 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.25.134.196 with HTTP; Wed, 25 May 2016 08:54:45 -0700 (PDT)
In-Reply-To: <D36B17B7.40835%keyupate@cisco.com>
References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <13146_1464170675_574578B3_13146_4888_1_53C29892C857584299CBF5D05346208A0F8CD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> <CA+b+ERmdpCmCsP-5_NsLH6pbay4zaXMpjGJP2S3z8gfAAXZR8A@mail.gmail.com> <D36B06A7.6257D%acee@cisco.com> <CA+b+ERkioULCYg_HQK9qqN+wjiapTZxK7nHWLGaq_=8wfxajsA@mail.gmail.com> <D36B2E2D.625D3%acee@cisco.com> <D36B1406.4080E%keyupate@cisco.com> <CA+b+ERm0p7-tHJmo5CWDu2ZAOcMsngf84K6wRnn6Doa16QyRzQ@mail.gmail.com> <D36B17B7.40835%keyupate@cisco.com>
Date: Wed, 25 May 2016 17:54:45 +0200
X-Google-Sender-Auth: wxmgcMClgFObHYrbsbmX6ab0XPE
Message-ID: <CA+b+ERkzRFAS5EJ08ohbuN-KkzKDfar=tMMRqN6vkxEAa3JL-Q@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
To: "Keyur Patel (keyupate)" <keyupate@cisco.com>
Content-Type: multipart/alternative; boundary="001a11400b424efcd90533acb118"
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/PVwLyXbTuuWAN_AqCj6e3zs3LIw>
Cc: Bruno Decraene <bruno.decraene@orange.com>, Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)
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: Wed, 25 May 2016 15:54:51 -0000

​You missed the scenario I am afraid :)

R1 --- RR --- R2


R1 and RR support extended message ... R2 does not.

So R1 sends to RR NLRI with attributes exceeding 4K as he has no clue who
is behind RR and what they support.

How RR is supposed to pass this prefix with bunch of attributes larger then
4K to R2 ?

Best,
R.
​

On Wed, May 25, 2016 at 5:51 PM, Keyur Patel (keyupate) <keyupate@cisco.com>
wrote:

> Hi Robert,
>
> I thought the context of that line “not generating single NLRI if
> attributes exceed 4K” was for peers not supporting extended messages.
>
> Otherwise its a moot point. :)
> Regards,
> Keyur
>
> From: Robert Raszuk <robert@raszuk.net>
> Date: Wednesday, May 25, 2016 at 8:48 AM
> To: Keyur Patel <keyupate@cisco.com>, "Acee Lindem (acee)" <acee@cisco.com
> >
> Cc: Bruno Decraene <bruno.decraene@orange.com>, "idr@ietf.org" <
> idr@ietf.org>, Susan Hares <shares@ndzh.com>
> Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to
> 6/7)
>
>
>
>> Additionally, we could discourage the generation of a single NLRI
>> exceeding 4K.
>>
>> #Keyur: Yep. I agree. :)
>>
>
> ​The entire idea for this draft was triggered by the fear that BGPSec may
> not fit to 4K update msg.
>
> The draft explicitly states so as a motivation for this work.
>
> Section 1
>
>    "As BGP is extended to support newer AFI/SAFIs and newer capabilities
> (e.g.,
>    [I-D.ietf-sidr-bgpsec-overview]), there is a need to extend the maximum
> message
>    size beyond 4096 octets."
>
> ​Now in turn the referenced draft clearly defines that NLRI will only
> contain single prefix:
>
> Section 3.2
>
>    "When a BGP speaker originates a BGPsec update message, it creates a
>    BGPsec_Path attribute containing a single signature. The signature
>    protects the Network Layer Reachability Information (NLRI), the AS
>    number of the originating AS, and the AS number of the peer AS to
>    whom the update message is being sent. Note that the NLRI in a BGPsec
>    update message is restricted to contain only a single prefix."
>
> Question:
>
> ​So what exactly are we to discourage here because clearly not "generation
> of single NLRI exceeding 4K" ?
>
> Maybe deployment of BGPSec till all BGP routers in the world support this
> new extended message size ?
>
> Thx,
> R.
> ​
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>

v2.23.0 | Report a Bug | By Email