Re: [GROW] Handling of LAGs in Mitigating Negative Impact of Maintenance through BGP Session Culling

[Nick Hilliard <[e-mail]>]

Thomas King wrote:
> Hi Job,
> 
> to be clear, my suggestion covers MC-LAGs and more importantly LAGs.

reading between the lines, in the case of single-device LAGs, I'm
guessing that you're talking about LAGs deployed over different line
cards on larger chassis based network devices.  On devices with a
single/unified data plane, conditionally applying session culling to LAG
interfaces based on the number of active bearer ports isn't an issue
because if you perform maintenance on that sort of device, all ports are
affected device-wide so the point is moot.

So the concerns you have seem only to be an issue in situations where
there are either MC-LAGs or else single-device LAGs configured on
different line cards in the same chassis and the maintenance operation
only applies to a single line card.  In either case, the LAGs would be
configured for throughput rather than resilience.

Regarding implementation, this mostly falls into "don't shoot yourself
in the foot" category.  Any network operator who rolls either MCLAG or
LAGs on multiple line cards will be aware that this is an area where
basic due diligence needs to be applied.

There are plenty of ways of shooting yourself in the foot at an IXP.
draft-ietf-grow-bgp-session-culling doesn't attempt to enumerate all of
them.

I wouldn't see a problem mentioning LAGs in a future -bis, but as others
have noted, there doesn't seem to be a compelling reason to pull the
document out of the rfc editor queue at this point.

Nick

> Both is missing in the current document. I think the working group
> should decide if the current document is good to go or whether it is
> missing important parts and should be revised.
> 
> If we as a working group decide to move ahead and add the proposed
> changes on an update of the BCP I will definitely contribute.
> 
> Best regards,
> Thomas