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 _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
