Re: [Idr] Review Request for draft BGP Overload

[amit bhagat <[e-mail]>]

Hi Robert,

I agree that recently BGP is being stretched towards DC-fabric side to
encompass various use cases.

However, the way I see this draft, it can be useful for both, Internet and
DC-fabrics. The main reason is to keep traffic drain procedure BGP topology
agnostic, exactly same as ISIS Overload-bit. Agree, BGP has a bigger blast
radius in Internet compared to ISIS but appropriate implementation of the
feature can provide good benefits.

Thanks.
Amit

On Tue, Jul 5, 2016 at 3:36 PM, Robert Raszuk <[e-mail]> wrote:

> 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
>>>>
>>>>
>>>
>>
>