Re: [Idr] Transport Instance BGP

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 <robert@raszuk.net> 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 <zhuangshunwan@huawei.com>
> 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:idr-bounces@ietf.org] *On Behalf Of *Robert Raszuk
>> *Sent:* Wednesday, July 29, 2020 5:06 PM
>> *To:* Greg Skinner <gregskinner0@icloud.com>
>> *Cc:* idr@ietf.org
>> *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 <gregskinner0@icloud.com>
>> 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
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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