Re: [Snac] Review of draft-hui-stub-router-ra-flag-02

[Ted Lemon <[e-mail]>]

I think stub networks can be stub networks. We are not using the term
differently than the usual meaning.

Op do 21 mrt 2024 om 06:09 schreef Esko Dijk <[e-mail]>

> I also like “SNAC router”.  Using the acronym it could be a “stub network
> auto-configuring router” or “SNAC router” in short.
>
> For “SNAC network” we’d have the term “network” in there twice.   Which
> should be okay, even though it’s not perfect.
>
>
>
> One could also call this network “a SNAC” which has some crispy feel to
> it. This can be a “stub network, auto-configured” or SNAC for short.  Also
> not perfect since the auto-configuration pertains maybe only to the SNAC
> router and not necessarily to the entire stub network and its nodes.
>
>
>
> Esko
>
>
>
> *From:* Ted Lemon <[e-mail]>
> *Sent:* Wednesday, March 20, 2024 07:56
> *To:* Ole Troan <[e-mail]>
> *Cc:* Esko Dijk <[e-mail]>; [e-mail]; Jonathan
> Hui <[e-mail]>
> *Subject:* Re: [Snac] Review of draft-hui-stub-router-ra-flag-02
>
>
>
> Hah! Yeah, maybe that's the right answer. :)
>
>
>
> On Wed, Mar 20, 2024 at 4:23 PM Ole Troan <[e-mail]> wrote:
>
> Just: "SNAC router” and “SNAC link” or “SNAC network” is what to attach to
> downstream.
> Which includes “auto” and “stub” in the acronym. And makes it clear that
> this is not a generic stub router, that would typically run a routing
> protocol.
>
> One of the hardest things in computing is naming...
>
> O.
>
> > On 20 Mar 2024, at 06:40, Ted Lemon <[e-mail]> wrote:
> >
> > FYI we've updated the document (see summary under a separate subject),
> and I think it sort of avoids the second issue you raised. As to the first
> issue, we do need to figure out whether or not we can continue to use the
> term "stub router" to refer exclusively to the type of router described in
> snac-simple, or whether we need a new name.
> >
> > Here's what it said in the missing slide:
> >
> > Esko pointed out that “stub router” already means something
> > I think distinguishing our special meaning of “stub” is hard
> > How about one of:
> > * sub router
> > * dependent router
> > * subsidiary router
> > * ???
> >
> > On Wed, Mar 20, 2024 at 2:14 AM Esko Dijk <[e-mail]>
> wrote:
> > > You raise a good point about the term "stub router," unfortunately.
> I've proposed some alternatives in today's presentation in SNAC/DNSSD.
> >  It looks like the names did not end up in the slides – I would be
> interested to see the list of names.
> > One variant is “sub router” as you mentioned. Or, add a letter and we
> get “stubb router”, or “stup router” :)
> >  > To my knowledge there are no 6lowpan border routers that do actual
> routing—they all use Proxy ND. Do you know of any?
> >  There is an open-source 6LBR with RPL routing, where different modes
> can be selected, including a “Router mode” – this mode doesn’t use ND
> proxy. See https://github.com/cetic/6lbr/wiki/6LBR-Modes
> > As for actual products, commonly deployed 6LBRs are Wi-SUN standard
> border routers (for smart energy/smart city markets) and Thread Border
> Routers.  For Wi-SUN 6LBRs that include a cellular backhaul and integrate a
> DHCPv6 server typically, I’m not sure if having ND Proxy would be useful
> actually – there’s no AIL in that case, only a cellular uplink to the
> cloud/internet. But I haven’t used any such product so you could be right
> here.
> >  Esko
> >   From: Ted Lemon <[e-mail]>
> > Sent: Tuesday, March 19, 2024 01:37
> > To: Esko Dijk <[e-mail]>
> > Cc: [e-mail]; Jonathan Hui <[e-mail]>
> > Subject: Re: [Snac] Review of draft-hui-stub-router-ra-flag-02
> >   You raise a good point about the term "stub router," unfortunately.
> I've proposed some alternatives in today's presentation in SNAC/DNSSD.
> >   And you are right, I meant "proxy ND," not "proxy ARP." To my
> knowledge there are no 6lowpan border routers that do actual routing—they
> all use Proxy ND. Do you know of any?
> >   On Mon, Mar 18, 2024 at 9:00 PM Esko Dijk <[e-mail]>
> wrote:
> > Agree it would be nice if we can just use “stub router” as a term for
> the unmanaged plug-and-play router that we’re defining in SNAC-simple.
> > But, I do see potential confusion there because “stub router” is an
> existing term: just do an internet search on the term or ask the AIs.  In
> particular there are flavors like “OSPF stub router” and “EIGRP stub
> router” commonly used. And there’s the existing use of “stub network” (e.g.
> see Wikipedia article).
> >  Then we might need to say “SNAC stub router”, or “auto-stub router” or
> so, to be distinguishing enough.
> > In any case, whatever term it will be, defining that properly as
> unmanaged/autoconfigured will solve most of the issues raised.
> >  > I think a 6lowpan BR is not a stub router and doesn't send RAs--it
> uses proxy ARP.
> > Actually the 6LBR can be made in multiple ways, while the basic IETF
> definition was in RFC 6775, it was already in literature since 2009 I
> believe in the book “6Lowpan - The Wireless Embedded Internet”. When the
> term was coined it was quite generic (see the definition in the RFC 6775
> terminology list): a router interfacing between a 6LoWPAN network and some
> other network (which may be Ethernet, Wi-Fi, 6LoWPAN, or other). The 6LBR
> provides the IPv6 prefix for the 6LoWPAN network and routes packets to/from
> that network.  In this interpretation, a Thread Border Router is by
> definition a 6LBR because Thread uses 6LoWPAN.
> >  So there are particular flavors of 6LBR possible, such as a 6LBR for
> 6TiSCH networks, which is applicable to a very specific interoperable set
> of devices that use 802.15.4 TSCH and follow the IETF RFCs for these
> devices. However, there are many more 6LoWPAN based standards in existence
> and all of these could use the term “6LBR” for their border router if they
> want. There’s also extensions like the “6BBR” ND proxying operation defined
> in RFC 8929, which is maybe what you meant with proxy ARP? The 6BBR would
> not send RAs indeed but acts like a “set of hosts”.
> >  But since 6LBR is not a very common term today, we can just not mention
> it to avoid this confusion.
> >  For the rest, agree with your new text proposals!
> >  Regards
> > Esko
> >   From: Ted Lemon <[e-mail]>
> > Sent: Monday, March 18, 2024 05:30
> > To: Esko Dijk <[e-mail]>
> > Cc: [e-mail]; Jonathan Hui <[e-mail]>
> > Subject: Re: [Snac] Review of draft-hui-stub-router-ra-flag-02
> >   On Tue, Mar 5, 2024 at 7:16 PM Esko Dijk <[e-mail]>
> wrote:
> > Overall, there's a bit of confusion on what the flag expresses. Its name
> is "stub router flag" but the flag is only set, I believe, for
> unconfigured/unmanaged stub routers.  As soon as a stub router becomes
> managed, it is part of "infrastructure routers". Even though it is still is
> a stub router per the definition - because it provides connectivity to a
> stub network. I would be okay to keep the name as is, or to rename it to
> something like "Unmanaged Stub Router Flag", but it needs to be clarified
> when the flag is set, and when it is cleared (especially for a stub
> router!). In the list below are some suggestions that go into this
> direction.
> >   I think that a device that's managed is not a stub router, and so this
> doesn't apply. The introduction doesn't make this point clear—it suggests
> that any router connecting a stub network and an infrastructure network is
> a stub router, but that's not really the case. The idea of a stub network
> is just that there's no routing through it, and this is a normal
> operational thing that happens all the time. A home network is ordinarily a
> stub network for example, although it's not required to be.
> >   So I think the fix for this is to update the introduction to make this
> distinction clear: a stub router is an unmanaged device that automatically
> connects a stub network to an infrastructure network.
> >   So I would change this:
> >   A stub router provides IP connectivity between a stub network and an
> infrastructure network. A common stub router example is a device that
> attaches a 6LoWPAN-based network to a home network.
> > to this:
> > A stub router is an unmanaged router that automatically connects a stub
> network [draft-ietf-snac-simple] to an infrastructure network.  A common
> example of a stub router is a router that attaches a 6lowpan network to a
> home network without requiring explicit configuration by an operator.
> >   And: do we foresee a case where a managed stub router sends out PIO
> with a managed ULA prefix (so stub router flag=0); but unfortunately the
> prefix is not "suitable" so the stub router adds its own self-generated ULA
> PIO prefix in an unmanaged way - so it also wants to set stub-router-flag=1
> ?   Probably not? (sounds like the admin either made a mistake or doesn't
> want the stub-network & AIL communication to be enabled on purpose). My
> working assumption is that we don't need per-PIO-prefix granularity for
> advertising "this is a non-managed prefix", for our current use cases.
> Still, it can be considered as a solution alternative because it allows
> future use cases easier. This would use 1 flag bit in the PIO where flag
> space is more scarce. So it's not super attractive to go change this now
> but I'd like to know what others think.
> >   I think the document should make clear that in a situation where the
> infrastructure router connects a stub network to the infrastructure
> network, and where that infrastructure router is providing IPv6 addressing
> and (optionally) routing on the infrastructure network, that device is not
> a stub router and should not be setting the stub router flag in router
> advertisements.
> >   It's worth noting that there are devices in the field that do both
> functions independently, and so wind up sending some infrastructure RAs and
> some stub network RAs. This is technically allowed by RFC4861, but RFC4861
> doesn't explain how to do it, and it doesn't really work. So we should
> probably exclude this use case: a device that behaves in this way simply
> isn't likely to work, and we shouldn't encourage it.
> >
> > Abstract
> > "information sent by stub routers from information sent by
> infrastructure routers."
> > --> "information sent by unmanaged stub routers from information sent by
> infrastructure routers."
> >
> > We could add the sentence to the abstract, to make it complete and
> summarize the entire document:
> > "This flag, if set, indicates that the message is sent by an unmanaged
> stub router."
> >   There is no such thing as a managed stub router, so no need for this
> update.
> >   1. Introduction
> > --> Section should reference the [I-D.ietf-snac-simple] document
> earlier; and point the reader there for details on the whole described
> functionality of ULA prefix and tracking infrastructure-provided IPv6
> service.
> >   Agree, see above.
> >   "A common stub router example is a device that attaches a
> 6LoWPAN-based network to a home network."
> > --> Can mention here the name of such a device: a 6LoWPAN Border Router
> (6LBR).
> >   I think a 6lowpan BR is not a stub router and doesn't send RAs--it
> uses proxy ARP. I think it would be cool if that document were updated to
> advise implementing a stub router instead, but that's out of scope.
> >   "In the second case, the two stub routers could wind up in a cycle of
> publishing and deprecating their prefixes as they see prefixes from the
> other stub router show up.
> > The stub router document [I-D.ietf-snac-simple] explains how two stub
> routers decide which one has precedence in the event of a conflict."
> >
> > --> This part is somewhat confusing. Maybe emphasize that we need to
> distinguish between unconfigured stub routers and all "other" routers here,
> pointing to snac-simple, instead of focusing on the problem / conflict here.
> >    The first sentence could be replaced by:
> >    "The stub router needs a method to distinguish between these two
> sources."
> >   One way to fix this would be to say:
> >   "In the second case, stub routers need to be able to tell whether an
> RA is from another stub router or an infrastructure router. Without the
> stub router RA flag,  two stub routers would not be able to make this
> distinction. In situations where both stub routers publish their initial
> RAs relatively simultaneously, this could then result in an endless cycle
> of deprecations."
> >   "However, the infrastructure prefix always has precedence over a
> prefix provided by any stub router."
> > --> "However, a suitable infrastructure-provided prefix always has
> precedence over a self-generated prefix provided by any stub router."
> > (Note here that stub routers could be either unconfigured, or configured
> (managed). The lower precedence is only for the unconfigured ones.)
> >   Not needed, no such thing as a managed stub router.
> >   2. Terminology
> > --> Include here by reference all the terms of [I-D.ietf-snac-simple]
> >   Sure.
> >   4. Router Advertisement Transmission
> > --> see my comments on top - to add here the explicit requirement that a
> stub router that is configured/managed (i.e. part of infrastructure
> routers) MUST NOT set the stub router flag ?
> >   Again, no such thing.
> >   "How and when a stub router sets the M and O flags in outgoing RAs is
> specified in [I-D.ietf-snac-simple]."
> > --> "How a stub router sets the other flags in outgoing RAs, and when
> these RAs are sent, is specified in [I-D.ietf-snac-simple]. "
> > (Seems best to generically refer to all other flags. This then requires
> pulling out the "when" part.)
> >   I tihink this text could be clearer:
> >   Additionally, the RA header includes M and O flags that indicate
> whether DHCPv6 is available on the link. Section 6.3.4 of [RFC4861]
> specifies that hosts consider the most recently received information as
> authoritative. In order to avoid overriding whatever the infrastructure
> router is advertising, [draft-ietf-snac-simple] requires stub routers to
> mirror the M and O values in RAs received from infrastructure routers. The
> Stub Router flag provides a way for stub routers to correctly make this
> distinction.
> > "A stub router"
> > --> should we constrain this specifically to "A stub router implementing
> [I-D.ietf-snac-simple]" ?
> >   There are no other stub routers yet. Bear in mind that the
> "infrastructure-supported stub router" draft that we're planning to do
> after snac-simple is still a case where stub routers are unmanaged; the
> difference is that stub routers in the second draft will be able to
> discover and use services on infrastructure.
> >
> > 5. IANA Considerations
> > --> Table 1 add caption
> >
> > 6. Security Considerations
> > --> best to expand "NDP" here - I don't see that acronym used in 4861,
> nor in the draft elsewhere.
> >
> > We could add that there are no known security issues of setting the new
> flag, or spoofing it.
> >   Yup. Thanks for the review! Looks like we need another spin of the
> document before we present it to 6man.
> > --
> > Snac mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/snac
>
>