Re: [Idr] Review Request for draft BGP Overload

[amit bhagat <[e-mail]>]

Hi Robert,

I uploaded v01 of the draft to address some of your concerns. Sorry, I
misunderstood what you meant by leaking. Agreed, even though
MP_(UN)REACH_NLRI are non-transitive, they will be advertised to
neighboring AS. To stop this flooding, I have added that the UPDATE message
must be sent with NO_ADVERTISE community. Not sure if this is "hacky".

It also includes the usecase I am referring to - neighbor-count threshold.

I appreciate your feedback.

Thanks.
Amit

On Wed, Jul 6, 2016 at 10:41 AM, Robert Raszuk <[e-mail]> wrote:

> Hi Amit,
>
> BGP Capability is completely orthogonal. It only indicates who support
> this new SAFI. I am talking about the case where  as this new SAFI which is
> needed only between *directly connected* peers will use generic BGP
> mechanism and will propage NLRIs across entire DC. It would be completely
> unnecessary yet your draft does not discuss this point. This is what I call
> "leaking".
>
> As far as signalling number of active peers to a peer I do not see how you
> encode this in the currently posted proposal nor it is clear what action
> such router should automatically do with that information. Honestly I would
> rather see the operator action here.
>
> Thx,
> R.
>
>
>
> On Wed, Jul 6, 2016 at 7:34 PM, amit bhagat <[e-mail]> wrote:
>
>> Hi Robert,
>>
>> There is no risk of leaking as the Capability will be exchanged with
>> peers upon session establishment.
>>
>> What this feature also gives is monitoring Established neighbor-count.
>> Consider a router connected to 10 peers and all 10 peers advertise exactly
>> same prefixes in a CLOS fabric. Now, if 5 peer sessions go down, the
>> capacity is effectively reduced to 50% while this router is still in the
>> transit. This can cause congestion. Instead, the router can declare itself
>> overloaded and the downstream routers then rely on other paths. The update
>> advertisement delay can be an implementation detail.
>>
>> Thanks.
>> Amit
>>
>> On Wed, Jul 6, 2016 at 12:34 AM, Robert Raszuk <[e-mail]> wrote:
>>
>>> Hi Amit,
>>>
>>> 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.
>>>>
>>>
>>>
>>> ​I don't think ​this is about "blast radius". ISIS or OSPF are link
>>> state protocols and each node in the given flooding scope computes its
>>> independent SPF hence flooding such information is a necessity for
>>> consistent forwarding.
>>>
>>> Contrary to the above BGP is path/distance-vector where each BGP speaker
>>> recomputes its bRIB and re-advertises it. Therefor for the use case you
>>> have in mind all what is required is to signal in some way to a bgp peer(s)
>>> that you may not want or want again to be in forwarding for a given SAFI.
>>>
>>> You defined a new SAFI as well as new NLRI format to use for point to
>>> point signalling .. I am not convinced this is the right level of
>>> signalling choice for this purpose. How do you stop propagation of such
>>> NLRIs around ? It would be pretty harmful if one router in Clos fabric will
>>> leak it and it breaks entire fabric - wouldn't you agree ? You at very min
>>> MUST enforce the NO-EXPORT/NO-ADVERTISE semantics for such SAFI which
>>> currently your draft seems to be missing.
>>>
>>> There are couple of alternatives to accomplish the same though:
>>>
>>> - using flag in dynamic capabilities
>>> - local poisoning of next hops
>>> - use of local pref/med (same as OSPF max metric:)
>>> - use of G-shut community
>>>
>>> or simply shutting the SAFIs. When you shut SAFI in one shot all paths
>>> learned are removed and best path (or multipath) recomputed. The potential
>>> "hit" would be on re-enabling it such that you need readvertise your
>>> underlay again.
>>>
>>> It is gracefull (no packet drops) as local forwarding can continue till
>>> everyone around stops sending you packets in a given table_id
>>> (corresponding to SAFI which has been shut down).
>>>
>>> Many thx,
>>> R.
>>>
>>>
>>
>