Re: [Idr] Transport Instance BGP

Jeff Tantsura <> Sat, 01 August 2020 03:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DCACC3A10CE for <>; Fri, 31 Jul 2020 20:06:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=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 QBxhEl_1j7Lv for <>; Fri, 31 Jul 2020 20:06:46 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C9BBE3A10C9 for <>; Fri, 31 Jul 2020 20:06:45 -0700 (PDT)
Received: by with SMTP id p8so880532pgn.13 for <>; Fri, 31 Jul 2020 20:06:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=bgskYYWGkVIeQJ+dvYUWv2my6x0tGAuMM7iprmj4I3M=; b=XzaIxuIRDhu7vmj0tQEtxr0bxHAJcosQ4cDbJ3wAxlPifUlJNIjEhkuqDXkM0IfHW4 GRwMZs/7S84Oj4HGJPrqVZQMI2anQO2Wn6Tu35EGh+QgJMxccCjU9PHEfRAADTRGiqsY uk2W3bMKggMxSvsg8NU8KI6T2qigT+6i6/2fQANcGn6xGZmeyw6Wn2wSO+7hhjvqwmqg 4iSAce3xPn1nFz0O0cTvsmSFY98az14WG/4udTnK2nZCAf95j+UD1IauoXXgF4iQibfl 1BrmYNdcWXgaHtYMMNHtXOCxXGVdI/yGQf0nw9LrtrwNUAzzJRlZR09zXqx5AMwoMRe6 aj7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=bgskYYWGkVIeQJ+dvYUWv2my6x0tGAuMM7iprmj4I3M=; b=FvSlGgzJssKJtOdjhLqFna52GkNBI31wLo2tafSlQGMEpb6QnQZT+GAvYVZQ/mvH/3 HRmN7dFfWVonD9GYHVfM9NrQBE3g6NYjv7h1BjjngGLJCqiQTBzfM7TTd3NyEIzh420m zc/nORu/Jkgi58Q6yiY40jq92+HwjRsMwpWM8D/vWCTqSMq1CBJBCgpgUjlICT7u4L02 yI9Ng/t4gRFiNJwEIVBwbtvLPM2T9QTSMy7ZI0IrysB9tIw6u0mjUZHhV7K1JyOkNkBY jJU5FSJMebePhpQf7Kv0GjpGD36a+WRqaNf8QiZSLMRtUEnsyYZTcD0MmNERj9cwwcZT //kQ==
X-Gm-Message-State: AOAM530xmq+2UgyOkaSxVVorcY7mwqYiMeXldbuz1FKI19HvlEexsikK kvcDvf8t8+d5/UdE86sGPmY=
X-Google-Smtp-Source: ABdhPJwK0jcH8U51Q+Xs/Ly9FbvWdYv45Ig8HJdoZ/s5CC+zwVHTOo+mYa8+myqnJEA+LZj2hoRbDQ==
X-Received: by 2002:a63:5d0c:: with SMTP id r12mr6166742pgb.198.1596251205287; Fri, 31 Jul 2020 20:06:45 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id ml8sm10357204pjb.47.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 31 Jul 2020 20:06:44 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-CA34A5E1-3EA1-4336-A2CB-E28FD4BF00F2
Content-Transfer-Encoding: 7bit
From: Jeff Tantsura <>
Mime-Version: 1.0 (1.0)
Date: Fri, 31 Jul 2020 20:06:43 -0700
Message-Id: <>
References: <>
Cc: Gyan Mishra <>, Greg Skinner <>, "" <>
In-Reply-To: <>
To: Robert Raszuk <>
X-Mailer: iPhone Mail (17F80)
Archived-At: <>
Subject: Re: [Idr] Transport Instance BGP
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 01 Aug 2020 03:06:49 -0000

I clearly remember Kireeti talking about it, perhaps at MPLS congress, around 2013. I can’t find any  traces of it though ;-)


> On Jul 31, 2020, at 15:06, Robert Raszuk <> wrote:
> Hi Jeff,
> Can you provide any references to other proposals aiming at this space within BGP ? 
> Thank you,
> R.
>> On Sat, Aug 1, 2020 at 12:03 AM Jeff Tantsura <> wrote:
>> There had been a variety of proposals (to my memory) to decouple BGP(kitchen sink) from BGP(reachability).
>> I’d be all in to rejuvenate this effort, and use Robert’ document as the starting point. 
>> Cheers,
>> Jeff
>>> On Jul 31, 2020, 2:26 PM -0700, Gyan Mishra <>om>, wrote:
>>> Sounds like plan.
>>> I like the win-win for BGP.👍
>>> Those two camps Service Provider and  Enterprise are closely aligning and converging as a major the variable is size, and if the private closed domain is a worldwide massive network, they are very close to being completely aligned as is the case with Verizon and maybe other Tier 1 and Tier 2 providers.  Of course the closed domain bar can swing from tiny to massive which is your point. Agreed.
>>> I agree on the former however the IETF has individual representation from all camps thus the world we live in and cannot satisfy everyone but the bar can swing from small to large.  Finding the happy medium is a challenge but that is part of our job in achieving WG consensus and IETF adoption on any protocol specification.
>>> That being said from an IETF and protocol development perspective you have to think of the trickle down of the protocol specifications as it applies to all vendors and all routers switches appliances you name it that runs any protocol or specification developed - ospf Isis BGP MPLS SR etc.
>>> Since that protocol specification developed by the IETF can sit on a tiny CPE box running BGP MPLS SR or even BIER or commodify incumbent hardware vendor Service Provider massive OTN box with high 400G density, or NFV server - router VNFs, or 1RU pizza box white box running disaggregated software from incumbent commodity vendor, the IETF standard is a standard for all implementation of the protocol specification independent of hardware mode or brand big or small it applies to every vendor development and implementing software.
>>> Kind Regards 
>>> Gyan
>>>> On Fri, Jul 31, 2020 at 6:48 AM Robert Raszuk <> wrote:
>>>> Very true ... we could always rename it to "Internet routing related" 
>>>> In fact this should be win-win for both ... more stable Internet on one hand and lower bar for new twicks and mangling with BESS like or NETCONF like insertions to essentially a p2mp path vector protocol. 
>>>> In fact we see it more and more these days (example SRv6-NP long discussions) where Internet engineering and stability and close domain network design and engineering do not align. They are very different and trying to either stretch one or trim the other what we see in number of IETF WGs is just not the right thing to do. 
>>>> One would think that IETF as the name says is about the former ... but if we see RFCs and drafts maybe just a small percentage of them indicates so.  Almost like the "I" there stands for IP and not Internet .... 
>>>>> On Fri, Jul 31, 2020 at 6:17 AM Randy Bush <> wrote:
>>>>> > Please review this draft and let Robert and myself know if its something
>>>>> > worth reviving.
>>>>> >
>>>>> >
>>>>> imiho, there are a lot of things currently called "routing related" i
>>>>> would throw on the other side of that wall.
>>>>> randy
>>> --
>>> Gyan Mishra
>>> Network Solutions Architect 
>>> M 301 502-1347
>>> 13101 Columbia Pike 
>>> Silver Spring, MD
>>> _______________________________________________
>>> Idr mailing list