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

[Erik Auerswald <[e-mail]>]

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 <[e-mail]>
> 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