Re: [Idr] Transport Instance BGP

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
>>>
>> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike *Silver Spring, MD
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>