Hi Woj, On 10-08-25 11:56 AM, Wojciech Dec wrote:
I respectfully disagree. Here's why. The RS-mark mechanism describes how RSs are marked and how the responding solicited-RAs are sent. It has got nothing to do with other neighbor discovery messages. e.g. Unsolicited multicast RAs, Redirects, DAD NS/NAs, Address resolution NS/NAs etc. which are sent as defined in RFC4861/62. The draft simply does not mention anything about these other messages. If you can clarify why you think this is relevant to this draft, I will certainly add it here.Your argument seems to be saying that the draft is not to discuss/mention the overall context/intended usage of the mechanism and that steam rolling a simple RS-marking mechanism is what should be followed. I'm arguing, as are others, that the overall context and an understanding of the scenario where the RS-mark mechanism is to be used is required, as there appear to be issues there that are of relevance to the IPv6 community. Given that you are one of the authors/proponents of this draft/mechanism in both the IETF and in the BBF simultaneously, it's only fair to ask you the question to explain the context & assumptions, given that they are no-where to be seen publicly.
I think this is the basis of our disagreement. There are no assumptions that this document is making. There are usage scenarios not involving the mechanism proposed in this document that are relevant to this issue you are bringing up.
Let's say the mechanism proposed in this draft did not exist in either the IETF or BBF. Does the problem of the lost RSs exist? I contend that it does. What do you say? Unless we have a common view on this, I do not think we can agree on a resolution.
Thanks Suresh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
