Sent from my iPhone
> On Jan 9, 2018, at 07:50, Job Snijders <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/grow > _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
