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

Sent from my iPhone

> On Jan 9, 2018, at 07:50, Job Snijders <job@instituut.net> wrote:
> 
>> On Tue, Jan 09, 2018 at 03:34:46PM +0000, Will Hargrave wrote:
>> On 9 Jan 2018, at 11:35, Job Snijders wrote:
>>>> Our suggestion for handling LAGs looks like this: Typically, a
>>>> minimum number of port members can be defined for a LAG being up.
>>>> The LAG is not touched by BGP Session Culling during a maintenance
>>>> unless this number is undercut. If the number if undercut the LAG
>>>> is handled by BGP Session Culling as defined in the Internet
>>>> Draft.

This sounds like an implementation specific detail to me. I can think of several variants on  selecting which bgp sessions to cull based on criterion that might be exchange specific. Such as when inter-switch/site bandwidth drops below a certain threshold cull peers accordingly. 

I’m not sure that I would recommend any of these however the specifics of a service offering are up to an operator.

>>>> 
>>>> If no value for the minimum number of active port members is
>>>> defined for a LAG, the value 1 should be used as this is the
>>>> behaviour of LAGs today already.
>>> 
>>> Is this in context of multi-chassis LAG?
>> 
>> I think if we include anything about LAGs we should make it very clear
>> that you must apply the culling ACL to *either* all ports of a LAG
>> *or* none.  Applying it to half of an MCLAG could be disastrous.
> 
> Will, my reading of Thomas' message is slightly different, I don't think
> he is proposing to apply culling ACLs on half the ports of a LAG, he
> proposes that culling ACLs are only applied (to all ports) when more
> than X members of a LAG will be impacted by the maintenance (where X is
> an ixp-participant configurable number).

The same approach applies across multiple line cards in a large switch, or indeed might involve the loss of ports to which the client is not directly connected.

> 
>> I didn’t realise there were IXPs using MC-LAG. Discovering this maybe
>> surprise some members.
> 
> Thomas, in terms of IETF logistics, the RFC-To-Be draft-ietf-grow-bgp-session-culling
> document has already been submitted to the RFC Editor and is in the
> queue, information on LAGs cannot be added at this point to the
> publication.
> 
> However, since this is a BCP, the next iteration could include
> additional information as our understanding of the culling practise
> improves, and the BCP number wouldn't change of course.
> 
>> From what I read in your message your organisation is still in the early
> phases of applying the 'culling' mechanism. I recommend you to (over
> time) carefully take notes of the interaction between LAG and culling,
> and whatever arises as the best current practise is documented in the
> next revision of the BCP.
> 
> Kind regards,
> 
> Job
> 
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
> 