Re: [Idr] Review Request for draft BGP Overload

[Robert Raszuk <[e-mail]>]

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