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

[Ted Lemon <[e-mail]>]

There isn't any text in the analysis about M&O at the moment—I was
referring to that because it's the general discussion that I think Erik was
asking for.

I agree that wire-or is the only thing that makes sense. I guess we could
try to document that.

The reason we need a lifetime in order to reflect the bits (rather than
just sending them as zero) is that otherwise we have no way to decide to
stop reflecting them, ever. So one router once setting the bits
accidentally will result in all the stub routers on the link perpetuating
that setting until they're all power-cycled at the same time. Yuck.

Are the M&O bits documented? I guess technically yes, but the behavior that
they trigger is not documented, and the documentation is not consistent.
The M&O bits as documented kinda sorta barely work, as long as you don't do
anything too interesting. But e.g. as soon as you have two consumer-grade
home routers terminating to the same link, the documentation fails. As soon
as you have an operator that has more than one router sending RAs on the
link, the documentation fails. This is what I mean by "not documented," but
the clarification is valid—poorly documented would be more accurate.

On Wed, Apr 17, 2024 at 9:21 PM Michael Richardson <[e-mail]>
wrote:

>
> Ted Lemon <[e-mail]> wrote:
>     > 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.
>
> argh. I just don't think it matters, just send them as 0 as SNAC routers
> are
> unaware if there is a DHCP server out there.
> (Wire-or is the only intelligent behaviour for hosts)
> I'm just not willing to die on this hill, so I've been butting out.
>
>     > 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?
>
> That PR is for copy.
> It's also go this section on
>      _Analysis of deployment scenarios in which a stub router could cause
>      problems_
>
> which I guess was started to explain what happens if M&O are wrong, but I
> don't see any text in that section on M&O, so I suggest splitting the PR
> and
> merging that section now.
>
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
>