Hi Job, to be clear, my suggestion covers MC-LAGs and more importantly LAGs. 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 On 15.01.18, 19:34, "Job Snijders" <[email protected]> wrote: On Mon, Jan 15, 2018 at 06:11:26PM +0000, Thomas King wrote: > any update on this? Hi Thomas, I hope you realize that pulling the culling document out of the RFC editor queue, and going again through GROW, IETF and IESG review, is a very significant amount of work you'd be dumping in our laps. I'm not sure I'd agree to that. :-) In my January 9th message https://mailarchive.ietf.org/arch/msg/grow/1H30kxE7e1QN_5bRi3EfOoX9d-U I mentioned that perhaps a next revision of the BCP can include text specific to Multi-Chassis LAGs. You are free to propose text for the next revision, you have not done so yet. I recommend that any proposed text is based on actual operational experience with the combination of 'culling' and 'MC LAG'. I indicated that your organisation appears to be in the early stages of applying the 'culling' mechanism. I recommend you to carefully take notes on the interaction between LAG and culling, and whatever arises as the best practise, can maybe be documented in the next revision of the BCP. Kind regards, Job _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
