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

[Ted Lemon <[e-mail]>]

If we want to document the correct behavior of the M&O bits, that would
definitely be a 6man thing, not a SNAC thing. I don't oppose that—I'm just
reporting that that has been tried before and we did not succeed due to a
lack of any clear consensus.

SNAC definitely can't solve this problem.

The problem with tracking M&O bits is that they don't have lifetimes. SNAC
devices never want to turn them on, but if we are required to track them,
it's actually technically difficult to understand how we would track them.

For professionally managed networks, SNAC isn't really necessary or
appropriate. You could build a solution grounded in SNAC that could live in
this environment, but it would have to be manageable, just like any other
router.

We do actually have an appendix that talks about this issue. It's currently
not in a published version of the draft, but you can find it here:

https://github.com/ietf-wg-snac/draft-ietf-snac-simple/pull/53/files

Can you take a look at that and see what you think?

On Wed, Apr 17, 2024 at 5:42 PM Erik Auerswald <[e-mail]>
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 <
> [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
>