IETF Logo Mail Archive

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

Randy Bush <randy@psg.com> Thu, 26 May 2016 11:35 UTC

Return-Path: <randy@psg.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 C37B612DDDD for <idr@ietfa.amsl.com>; Thu, 26 May 2016 04:35:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.326
X-Spam-Level:
X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
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 TjQo-7MmSQ49 for <idr@ietfa.amsl.com>; Thu, 26 May 2016 04:35:12 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F50412DE0E for <idr@ietf.org>; Thu, 26 May 2016 04:34:40 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from <randy@psg.com>) id 1b5tYk-0004zF-MF; Thu, 26 May 2016 11:34:38 +0000
Date: Thu, 26 May 2016 13:34:37 +0200
Message-ID: <m2r3cpnjci.wl%randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Robert Raszuk <robert@raszuk.net>
In-Reply-To: <CA+b+ERkioULCYg_HQK9qqN+wjiapTZxK7nHWLGaq_=8wfxajsA@mail.gmail.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>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/DAJ9Xjvff4Wxaunj1vmABfF8BNM>
Cc: idr wg list <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: Thu, 26 May 2016 11:35:14 -0000

packing is not relevant.  receiver unpacks if nlri are packed, and as a
sender decides whether and how densly to pack or not.  if the outbound
link is smaller than the inbound, pack in less nlri.  if it is the
attributes that over-flow, then you have a more general problem.

if we are in the bgpsec space,

  o will a single nlri with a signed path fit in the extended message?
    yes.  even degenerate prepends don't hurt because of the pCount
    hack.

  o if there is an outbound that is not a bgpsec speaker, they will be
    sent a classic as4_path which darn well should fit in the classic
    message size.  if there is prepend insanity, that would die today.

  o if the outbound is a bgpsec speaker yet will not use an extended
    message size, there is one interesting case, the singleton stub.
    a non-transit router can sign toward its upstream(s) and not care
    about receiving bgsec as it has no other choice of where to send
    packets.

randy

v2.23.0 | Report a Bug | By Email