Re: [Idr] Review Request for draft BGP Overload

[Robert Raszuk <[e-mail]>]

Hi Amit,

Thank you for follow-up.

One thing which perhaps needs to be addressed is how this (and few other
recent proposals) is relates to Internet BGP vs L3 Clos DC fabric BGP. If
your problem description is limited just to the latter due to inherent ECMP
such message needs to only go one hop - so even a simple ORF extension will
do just fine.

Few years back BGP was stretched in one direction to accommodate carrying
VPN information in WANs. Now I see it being more and more stretched in the
opposite direction to accommodate various use case for DC underlay routing.

And I think we all can realize what happens when you take even best
material and stretch it with sufficient force in opposite directions :).

As far as this draft to me what would be the best envelope for the
information is really a new BGP message type .. BGP Operational Message.
The work on that started few years back but were a bit put on hold.

Defining new SAFI and making spagetti of SAFI-X to SAFI-Y operational
inter-dependency kills the ability to separate SAFI dependent code from AF
generic processing.

Now if your use case is just about Clos topology in a given DC why not to
use MED or LocalPref depending if your fabric is eBGP or iBGP based ? Is
really re-advertisement of underlay routes such an issue ?

Best regards,
R.






On Wed, Jul 6, 2016 at 12:12 AM, amit bhagat <[e-mail]> wrote:

> Hi Robert,
>
> Many thanks for your comments.
>
> Initially, I thought about using a community but that would mean putting
> all NLRIs in the Update message. This could also mean a different Update
> per-neighbor/per-peergroup.
>
> re: G-shut community - Reading through G-shut draft, it seems to be
> targeting a single use case - maintenance. Additionally, it requires manual
> configuration of route-policies. The way I envision this is a simple Update
> that is applicable to all peers; no need to worry about manipulating any
> BGP attributes.
>
> re: new SAFI - The reason for requesting a new SAFI is so that a new NLRI
> encoding can be defined to keep it simple. The existing SAFI would require
> adding NLRIs to the Update message.
>
> re: BGP session distinction - Is there a need to identify IBGP or EBGP
> session? Perhaps I am missing something.
>
> re: Global mode - the use case would be if a BGP speaker has multiple
> links to different peers and running different AFI/SAFI pairs per links, it
> might be just easy to drain a particular type of traffic rather than ALL
> traffic.
>
> Additionally, one of the other use cases I am thinking of is when a BGP
> speaker drops its Established neighbor-count below a threshold, it can
> advertise itself as "Overloaded". This can help avoid congestion. Agreed,
> this can also be the cause of network outage, but within a CLOS fabric, it
> should not be a problem due to multiple paths.
>
> Again, thanks for reviewing.
>
> Amit.
>
> On Tue, Jul 5, 2016 at 12:39 PM, Robert Raszuk <[e-mail]> wrote:
>
>> Hi Amit,
>>
>> In an essence it seems that your proposal is just a subset of "Graceful
>> BGP session shutdown"
>> https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-06.
>>
>> Can you clarify how your encoding is any better then proposed by
>> Pierre's, et al. G-Shut community?
>>
>> Why do you need a new SAFI for it ? Would it be easier to use community
>> or attribute and send it over existing SAFIs ?
>>
>> How in your encoding one can distinguish IBGP sessions from EBGP sessions
>> (case of core or edge line card replacement) ?
>>
>> What is the use case to not use "global" mode .. ie. when do you envision
>> need to signal overload for only subset of AFI/SAFIs carried by given BGP
>> speaker ?
>>
>> Many Thx,
>> Robert.
>>
>>
>> On Tue, Jul 5, 2016 at 9:25 PM, amit bhagat <[e-mail]> wrote:
>>
>>> Hey All,
>>>
>>> We are looking for your comments on the new draft
>>> https://datatracker.ietf.org/doc/draft-bhagat-bgp-overload/
>>>
>>> We would really appreciate any comments and questions about the document.
>>>
>>> Best Regards,
>>>
>>> Amit Bhagat
>>>
>>>
>>>
>>> _______________________________________________
>>> Idr mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/idr
>>>
>>>
>>
>