[Idr] draft-ketant-idr-bgp-ls-bgp-only-fabric
Robert Raszuk <robert@raszuk.net> Sun, 10 March 2019 16:09 UTC
Return-Path: <robert@raszuk.net>
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 89268126D00 for <idr@ietfa.amsl.com>; Sun, 10 Mar 2019 09:09:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 Se5fSKR55GuU for <idr@ietfa.amsl.com>; Sun, 10 Mar 2019 09:09:55 -0700 (PDT)
Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 66F761240D3 for <idr@ietf.org>; Sun, 10 Mar 2019 09:09:55 -0700 (PDT)
Received: by mail-qk1-x72c.google.com with SMTP id h28so1348892qkk.7 for <idr@ietf.org>; Sun, 10 Mar 2019 09:09:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=avxzzV/JhH0x+FEzCVgo2gkG+m+LWbGWyuen1q0FExM=; b=Gf44Q1Lugf/i48hU4TcrkP35xmZKqcdPkFNFKhcE/QDABROdo+FWfc4Ayt4LGITCjz 5xdcLG+X5enBCVtg/WAWDSW0P+/s0qUPvDKExQTE3y4xV+l/BTxfVcQX2KNiFXo8G0Vk SkaygC8sXZMpA1WghwgfnmxK74A3qw2apmEGA+Rh1oZDbZWpmJi8jEQ+E37CX9BJsvxJ iDu/T9sCfxO4vLnoJIeX29n6Y72iha9ODbFvnd1PtPy/i2SjJwDmhQiRDJegaRqa4aNG MQ/VDtSXxkaG7mVcWztHm3fb7yQA3xVPzHXOYQyHNMd4QF/7MeFV3MWlyoCSCXyWkrgf 4hxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=avxzzV/JhH0x+FEzCVgo2gkG+m+LWbGWyuen1q0FExM=; b=J1bgbptEE9X2dQXkcpQ3gcWpBgBQs/vmdMh5u4MT5sil1Q+8g3FqbOwqjcaQ68sY38 BSsB4InKetVcIiKv0A30z+13HHp8CFQEjoLf0qIZb5VOtwmoMSwk8MZL7lWcTyDF19H3 l3mYKSECXUOGfM3Kw0RNLhhZ0Ho3wLdEub3Q4Af1toFN4WvowqB2VZECO7nn+pFOyHdx LMM/0VWTvJA/pZXr5hqW3/FVvtdRYUCvOU8S/DFEHnHDlRsC4x4tZ2cYqJYOeNBXIibp 8bUkeT/KgRbFUWiCJPIhXKfdh3RXVGsRGtxfVNx8sQheWsmZeDiFeR9xAFTJuKo/A4tN 0whg==
X-Gm-Message-State: APjAAAWbcDtmEgZV5+BzGL8aCrfLb2xXn2vWrNe2V/hjjsXcieL44JNw 2Fk8nve10bQX3czNlBmSRMg79PVNGEyM4hPbfUGJ7A==
X-Google-Smtp-Source: APXvYqwX7+GYAXlDfEgLrjfUBkjX9o0qqwuADcawATnYtpzWPEA7KLT1FkSAF3l00UuyZmRd6Ubyv5gl8weqXeCSGds=
X-Received: by 2002:a37:d8c:: with SMTP id 134mr15599702qkn.336.1552234194516; Sun, 10 Mar 2019 09:09:54 -0700 (PDT)
MIME-Version: 1.0
From: Robert Raszuk <robert@raszuk.net>
Date: Sun, 10 Mar 2019 17:09:44 +0100
Message-ID: <CAOj+MMFp9=56e8v3V-nhDJyvTVrwY1YwDa5LQCyfgVnJMjgz9Q@mail.gmail.com>
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
Cc: "idr@ietf. org" <idr@ietf.org>, lsr@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c5d29d0583bfaf34"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/PSHHLBi-yO53h_-UfdnAnqgHb98>
Subject: [Idr] draft-ketant-idr-bgp-ls-bgp-only-fabric
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 10 Mar 2019 16:09:57 -0000
Hi Ketan, I have read your proposal of defining topology flooding in BGP with interest. It seems like a pretty brilliant twist to take pieces defined in other documents with their original intention for sending IGP information (LSDB or TED) over BGP extension and now use all of those without IGP at all :). But I have just one question here perhaps to the WG or ADs. Almost all normative references used in this draft clearly state that they were defined for carrying information present in ISIS & OSPF protocols as rather a courtesy of transporting them over TCP with BGP envelope between network and controller. Can we now just "reuse" verbatim all of those defined codepoints as well as redefine use of BGP-LS SAFI as a new link state p2p network topology transport just like that ? At min I would like to see some analysis included in this draft of running native link state protocol possibly with dynamic flooding optimization vs running BGP as the only routing protocol with using BGP as topology discovery transport before we proceed further on this document. Kind regards, Robert.
- [Idr] draft-ketant-idr-bgp-ls-bgp-only-fabric Robert Raszuk
- Re: [Idr] draft-ketant-idr-bgp-ls-bgp-only-fabric Ketan Talaulikar (ketant)