Re: [Idr] Review Request for draft BGP Overload

[amit bhagat <[e-mail]>]

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