Re: [Snac] M/O Bit reflection behavior of draft-hui-stub-router-ra-flag-02

+1.

A SNAC router has the potential to end up as a rogue router on the link.
That may be by design, but expected and assumed behaviour must still be described.

O.

> On 17 Apr 2024, at 23:42, Erik Auerswald <auerswal@unix-ag.uni-kl.de> wrote:
> 
> Hi Ted,
> 
> all I do is provide another point of view, based on experience, and make
> suggestions how to possibly improve this point of the SNAC description.
> I don't demand anything.
> 
> But how hard is it to describe that SNAC imagines a host to follow the
> infrastructure router's RA with M&O bits with DHCPv6 for default route
> communications, and the SNAC router's RA for stub network communications?
> Since anything goes, this goes.  This does not prescribe host behavior,
> changes nothing, just states an assumption.  There must be some idea of
> how hosts might behave since you state that they work correctly, even
> if this is not standardized.  The wording could be quite vague, saying
> that host behavior is not standardized, but, e.g., the above would work,
> and hosts are assumed to work in some SNAC-compatible way.
> 
> To put this differently, you want a SNAC router to also do its thing
> on a (perhaps partially) managed network, not only on an unmanaged one.
> A short description of how this is supposed to work seems not that big
> a burden.
> 
> The person troubleshooting could then read how the SNAC stuff is intended
> to work, and compare that to actual behavior.  IMHO this would be much
> better than nothing.
> 
> The SNAC WG tried to find a comprehensive solution by reflecting M&O
> bits from infrastructure routers, but not SNAC routers, but this did not
> pan out.  That is OK for me.  But I do not like the idea of ignoring this
> detail with a silent assumption of "correct" host behavior, without any
> description of what "correct" even is.
> 
> So perhaps if the SNAC WG describes how they assume hosts would work in
> a SNAC environment, this would be shot down by the IETF as out of scope?
> I would describe that as "process failure".  Still, you could just say so,
> and a poor soul digging into how SNAC was supposed to work might be able
> to find this.  This would not provide a solution, but perhaps closure.
> 
> Just not mentioning possible rough edges might seem like an easier way
> to an RFC.  Most reviewers are more likely to notice things written down
> than things not even mentioned.  Again, I'd call this "process failure".
> 
> I only care about the result.  I still do not demand anything.
> 
> ¯\_(ツ)_/¯
> 
> Br,
> Erik
> 
> 
> On Wed, Apr 17, 2024 at 03:46:32PM -0400, Ted Lemon wrote:
>> We've tried to update the documentation on the M&O bits before in the IETF.
>> It's failed because we can't get consensus.
>> 
>> Anyway, you're making a bunch of assertions here about what we have to do,
>> but not backing them with anything but your gut feeling based on
>> 20-year-old experiences. I don't think this is helpful. I'm not trying to
>> minimize the importance of getting this right, and I appreciate your wish
>> to make sure that we do. But it's not clear to me that you are actually
>> talking about a real problem we need to solve. There was a lot of expertise
>> on this in the room when we discussed it, and the general consensus is that
>> the stuff you're describing is old news, and we don't need to worry about
>> it anymore.
>> 
>> It is true that the behavior of hosts is not consistent, because there is
>> no standard that tells them how to behave. But it is not true that there is
>> a problem, as far as we are able to tell. If you have data that suggests
>> otherwise, please share it. But please do not demand that we do very
>> difficult work to solve a problem that you haven't documented.
>> 
>> Also, on a more practical note, making changes to host behavior and the
>> treatment of M&O bits is very much not in charter for SNAC... :)
>> 
>> On Wed, Apr 17, 2024 at 3:18 PM Erik Auerswald <auerswal@unix-ag.uni-kl.de>
>> wrote:
>> 
>>> Hi Ted,
>>> 
>>> On Wed, Apr 17, 2024 at 11:25:42AM -0400, Ted Lemon wrote:
>>>> 
>>>> The behavior of the M and O bits isn’t defined anywhere.  Modern
>>>> hosts have had to adapt to this.  During the discussions we had in
>>>> Brisbane the consensus was that they do now handle inconsistent M&O
>>>> bits correctly.
>>> 
>>> If the handling is not defined, no handling is incorrect.  But SNAC could
>>> describe how exactly hosts need to handle it to be compatible with SNAC.
>>> This would at least allow to troubleshoot the breakage.
>>> 
>>> Alternatively, SNAC could refrain from sending RAs onto a managed link
>>> to prevent incompatibilities leading to problems.
>>> 
>>> Alternatively, SNAC could make an honest effort to adapt to managed links,
>>> even if this does not work in all possible cases, and document the known
>>> problems in a section on operational considerations.
>>> 
>>> Br,
>>> Erik
> 
> -- 
> Snac mailing list
> Snac@ietf.org
> https://www.ietf.org/mailman/listinfo/snac