Hello,
We can always think of enhancements and this is part of the natural
process of documenting best practice. At some point (some time ago) a
consensus was reached, and we moved forward to publication. Without such
a watershed no work can actually ever be completed.
We don’t have a concept of ‘minimum links’; when the member buys
the ports they expect them all to work :) Selecting such a figure
implies an understanding of their network that I don’t possess without
further technical communication. This technique is designed to help with
those communication difficulties not increase their complexity.
Will
On 16 Jan 2018, at 14:28, Thomas King wrote:
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
