Re: [Idr] Transport Instance BGP

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

Regards,
Jeff

> On Jul 31, 2020, at 15:06, Robert Raszuk <robert@raszuk.net> 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 <jefftant.ietf@gmail.com> 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 <hayabusagsm@gmail.com>, 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 <robert@raszuk.net> 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 <randy@psg.com> wrote:
>>>>> > Please review this draft and let Robert and myself know if its something
>>>>> > worth reviving.
>>>>> >
>>>>> > https://tools.ietf.org/html/draft-raszuk-ti-bgp-01
>>>>> 
>>>>> 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
>>> Idr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/idr