Re: [Idr] Transport Instance BGP

[Gyan Mishra <[e-mail]>]

Welcome.  Let’s see what others think and  if it’s worthwhile.

IDR folks -

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


I noticed in the draft it mentioned BGP instances for critical and not
critical.  That is a very interesting topic.  I believe the you are
referring to multiple BGP instances on a router meaning on a single router
or these days now virtual instantiation of a router

Over the years it has been painstakingly difficult having the restriction
of a single BGP AS instance on a router, and would be nice to be able to
have multiple instances.  There are are of course special overlay or fusion
router type scenarios where you are routing between VRF and Global table on
the same router.  There are other overlay scenarios where it would be nice
to be able to have multiple instances such as for critical and not critical
as described in the draft or any use case type really.  To get around this
issue you end up having to use BGP knobs as a workaround such as local-as,
as-override and allowas-in to get around this issue.

I agree with the concept as it’s similar to dynamic BGP where you have
promiscuous peering where you specify an address range for the promiscuous
peer to come up, similarly I can see having a range of TCP ports per SAFI
and then be able to distribute across processors and cores providing
parallel processing (symmetrical multi processing) versus pipelining or
single threading all SAFI, thus splitting off each SAFI onto a discrete
thread.  From a management and MTTR perspective it is much easier to do
multi session with same IP then binding each SAFI to a different IP.

Agreed as the move from commodify hardware to white box hardware and
software vendors merchant silicon over property asic  or even incumbent
vendor now providing disaggregation of hardware and software.

Also with virtualization of network functions and removal of physical
hardware in a service chain with VNF software VMs with advent of NFV for
control plane functions such as RR - perfect candidate for NFV processed in
software.  I can see NVF implementations benefiting from this solution.

All the more reason I think that this would help with redundancy and
scalability as well as optimization when stack of SAFI PE-RR is a mile long.

Trying to garner support from vendors is challenging for individual
contributors without vendor affiliation but it is definitely possible if
you can build the concept into a marketing strategy that had monetary gain
with the gap being filled.  I agree we don’t want the dump trunk approach
with BGP, as is first and foremost job is as a routing protocol and it’s
sole purpose in life is to carry AFI/SAFI NLRI.

Is tried searching for the nmb draft but could not locate.

My 2 cents in summary as to why we should bring back the draft:

1. Multiple BGP instances feature

2. Decoupling SAFI onto different sockets and different processors or cores

Kind Regards

Gyan

On Thu, Jul 30, 2020 at 4:00 AM Robert Raszuk <[e-mail]> wrote:

> Hi Gyan,
>
> Many thx for your support.
>
> As said, if there is interest I am happy to respin the draft (fixing some
> obvious deficiencies) and ask for adoption. That should be the good gauge
> if there is rough consensus on this to proceed or not.
>
> Above all when BGP is used to carry IP routing or VPNv4 or BGP-LS it seems
> obvious that there is value to let the operator control which process is
> serviced by how many CPU cores. And we could generalize this more leaving
> port 179 to IP routing AFs and allowing not one but perhaps range of ports
> to be defined for local selection on a per application basis.
>
> Especially when we see BGP virtualization and functions like reflection
> being deployed on x86 commodity compute servers there is no longer need to
> keep everything under one front process umbrella and let the implementation
> decide how many sub-processes/threads is used along with compute or
> memory allocations.
>
> My only personal fear is that success of this work may even further delay
> work and adoption on network message bus NMB type of distribution of data
> among network elements in a true pub-sub fashion. Something I do believe we
> should have a long time back. For one while I have seen interest in
> community I observed no interest from major vendors and for two why bother
> if we have BGP which can take more and more load on it ... Perhaps shutting
> down RPD draft can be a good trigger for such an effort to start.
>
> Kind regards,
> R.
>
>
>
> On Thu, Jul 30, 2020 at 7:51 AM Gyan Mishra <[e-mail]> wrote:
>
>> Robert
>>
>> After reviewing your draft I do see a merit in reviving the draft.
>>
>> I think SAFI stacking PE-RR can get out of control and all eggs in one
>> basket with a single TCP session.
>>
>> I have designed some  implementations in the past where I have  broken
>> out the SAFI manually into separate IP TCP sessions iBGP loopback per SAFI
>> to provide redundancy but also from SAFI 128 129 perspective used for IP
>> VPN per VRF TE which was cumbersome but worked for total session separation
>>  also allows to break out each VRF into its own TE instance.
>>
>> Now with the advent of SR you get the same per VRF coloring out of the
>> box pnp without having to breakout the session. 😊
>>
>> Kind Regards
>>
>> Gyan
>>
>>
>>
>> On Wed, Jul 29, 2020 at 8:23 AM Robert Raszuk <[e-mail]> wrote:
>>
>>> Multi-sessions was not (I guess) fully abandoned - but it never was
>>> designed to provide full protocol separation.
>>>
>>> For example such separation that proposals which utilize p2mp transport
>>> in a p2p fashion to distribute configuration around can be taken out of IDR
>>> and if community wishes be progressed in other WGs under different protocol
>>> name.
>>>
>>> Besides multi sessions in number of implementations as I recall was very
>>> buggy.
>>>
>>> Thx,
>>> R.
>>>
>>> On Wed, Jul 29, 2020 at 12:09 PM Zhuangshunwan <[e-mail]>
>>> wrote:
>>>
>>>> Hi Robert,
>>>>
>>>>
>>>>
>>>> When you mentioned BGP multi-session, I wondered what the drawbacks of
>>>> this solution were that it was abandoned?
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Shunwan
>>>>
>>>>
>>>>
>>>> *From:* Idr [mailto:[e-mail]] *On Behalf Of *Robert Raszuk
>>>> *Sent:* Wednesday, July 29, 2020 5:06 PM
>>>> *To:* Greg Skinner <[e-mail]>
>>>> *Cc:* [e-mail]
>>>> *Subject:* [Idr] Transport Instance BGP
>>>>
>>>>
>>>>
>>>> Hi Greg,
>>>>
>>>>
>>>>
>>>> Many thx for your comments.. I do agree with all of them and if there
>>>> is interest in IDR to proceed all of your points will be addressed.
>>>>
>>>
>>>>
>>>> Just a note on the first point you made ...
>>>>
>>>>
>>>>
>>>> The proposal was shelved due to claims being made at and around
>>>> Stockholm IETF that all we need is working BGP multi sessions to demux
>>>> specific AFI/SAFI to a different session or different process within the
>>>> box.
>>>>
>>>>
>>>>
>>>> Well 10 years after I have not seen this to happen in *any*
>>>> implementation.
>>>>
>>>>
>>>>
>>>> Moreover in the mean time I see the proposals like BGP-LS which were
>>>> promised during WG processing and LC to be deployed separately from Routing
>>>> BGP (ex: dedicated RRs) in real deployments running on the same session and
>>>> on the same platforms (RRs) where LSDB is fighting for processing resources
>>>> with IP routes.
>>>>
>>>>
>>>>
>>>> So here when we are discussing just using BGP as a transport because:
>>>>
>>>>
>>>>
>>>> a) it is there
>>>>
>>>> b) it takes everything (well used to till today :)
>>>>
>>>> c) it is loop free distribution
>>>>
>>>>
>>>>
>>>> my point of mentioning use of ti-bgp proposal (btw second choice if you
>>>> go back to the note - first being JSON format and CURL for this type of
>>>> distributions) was to at least decouple it hard from IP routing.
>>>>
>>>>
>>>>
>>>> Many thx,
>>>> Robert.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Jul 29, 2020 at 3:06 AM Greg Skinner <[e-mail]>
>>>> wrote:
>>>>
>>>> (I limited the recipients in my response in order to (hopefully) focus
>>>> on the IDR-specific topics covered in the quoted text.)
>>>>
>>>>
>>>>
>>>> Regarding draft-raszuk-ti-bgp-01, if IDR has an interest in pursuing it
>>>> again, I have some concerns:
>>>>
>>>>
>>>>
>>>>    - There were several issues raised
>>>>    <https://www.ietf.org/proceedings/75/minutes/idr.txt> during the
>>>>    IDR WG meeting during IETF 75 that should be addressed, IMO.
>>>>    - I found some other issues in the draft that weren’t brought up
>>>>    during that meeting.  For example, in Section 5.5
>>>>    <https://tools.ietf.org/html/draft-raszuk-ti-bgp-01#section-5.5>,
>>>>    it is stated that "On the network side all today's BGP messages are send
>>>>    with IP precedence value of Internetwork Control of 110000, which is used
>>>>    for high-priority routing traffic.”  Is this true, even for open-source BGP
>>>>    implementations?  I looked at the source code for three implementations
>>>>    (Bird, FRR, and OpenBGPD), and was only able to confirm this for IPv4
>>>>    OpenBGPD messages.
>>>>    - One of the normative references, RFC 5226
>>>>    <https://tools.ietf.org/html/rfc5226>, has been obsoleted by RFC
>>>>    8126 <https://tools.ietf.org/html/rfc8126>.
>>>>    - Several of the informative references have expired.
>>>>    - The draft would require numerous editorial changes due to errors
>>>>    in spelling, grammar, etc.
>>>>
>>>>
>>>>
>>>> Regards, Greg
>>>>
>>>> _______________________________________________
>>> Idr mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/idr
>>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>>
>>
>> *M 301 502-134713101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>*Silver
>> Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>
>>
>> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD