Subject: [Idr] Review Request for draft BGP Overload

From: amit bhagat <[email-masked]>
Date: Tue, 5 Jul 2016 12:25:25 -0700

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

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 5 Jul 2016 21:39:09 +0200

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 <[email-masked]> wrote:

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
>

---

From: amit bhagat <[email-masked]>
Date: Tue, 5 Jul 2016 15:12:48 -0700

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 <[email-masked]> 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.
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 6 Jul 2016 00:36:44 +0200

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 <[email-masked]> wrote:

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

---

From: amit bhagat <[email-masked]>
Date: Tue, 5 Jul 2016 16:08:05 -0700

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 <[email-masked]> wrote:

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

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 6 Jul 2016 09:34:54 +0200

Hi Amit,

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

---

From: amit bhagat <[email-masked]>
Date: Wed, 6 Jul 2016 10:34:17 -0700

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 <[email-masked]> wrote:

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

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 6 Jul 2016 19:41:21 +0200

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.

---

From: amit bhagat <[email-masked]>
Date: Thu, 7 Jul 2016 10:33:27 -0700

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 <[email-masked]> 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
>> There is no risk of leaking as the Capability will be exchanged with
>> peers upon session establishment.
>>
>>> ​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