Re: [Snac] My thoughts

[Ted Lemon <[e-mail]>]

On Thu, Jun 2, 2022 at 9:58 AM Jari Arkko <[e-mail]> wrote:

> > For many years the IETF has been working on the problem of constrained
> nodes and constrained networks. One challenge with constrained networks
> specifically is that they can't safely be bridged together with media that
> is less constrained because the constrained network, which typically will
> have a much lower data rate, will not be able to receive all the traffic
> that would be forwarded to it from the high-speed infrastructure network.
> To address this, constrained networks are generally treated as separate
> links from infrastructure networks.
>
> I sympathize with the goals. I’m not convinced that the text above is a
> clear description yet though, but I’ll keep reading this and the documents.
> The issue with ”separate links” language is that as you know having a
> forwarding step doesn’t imply traffic doesn’t get forwarded :-) Also, it
> feels that the entire problem deserves a broader treatment, obviously
> people have been hitting this problem in the last twenty years and it has a
> number of aspects and potential (part) solutions. In-network firewalls,
> NATs in v4 world, private networks (e.g., your own APN for mobile
> networks), etc.
>

The understanding I'm getting from this is that we might be concerned that
a device on an infrastructure network with high capacity might accidentally
begin to send a high-bandwidth stream of data at a device on a stub
network, and this stream of data might (a) fill buffers, preventing
intended traffic from being forwarded in a timely fashion and/or (b)
deplete batteries in the case of e.g. an 802.15.4 mesh like Thread where
some mesh forwarders might be battery-operated.  I think this is an
important issue to discuss, and definitely on-topic.


> Looking at the -ps and the solution drafts, I think the description above
> and the documents are maybe not entirely in sync. The drafts are more about
> the ways of connecting stub networks and having that happen automatically
> in various circumstances; not so much about the data rate differences, etc.
>

The rate difference probably doesn't matter in terms of use cases, since
any legitimate use case for an unconstrained<->constrained network
connection is going to take into account the available resources of the
constrained network. The existing drafts are aimed more at use cases than
at risks, and I think from that perspective the documents are up to date,
but you are certainly correct that we need to talk about and mitigate risks
as well.


> > In a managed network, constrained networks can be provisioned into the
> routing infrastructure.
>
> There’s probably quite a bit that goes into what kind of ’provisioning’ is
> involved here. I assume that it is actually beyond routing. Filtering,
> firewalling, etc.
>

Right.


> I don’t think the drafts say much about aspects beyond service discovery
> and routing/addressing. I’m wondering how much we are then providing
> solutions for the actual constrained networks and how much this is simply
> general stub network attachment, in an automatic fashion?
>

How would you distinguish filtering and firewalling?

As far as what we're providing here, I think that there are problems and
solutions that are "stub network problems and solutions," which should be
applicable whether or not the stub network is constrained. And then there
are additional constraints that apply when the stub network is in fact
constrained. The latter is an interesting problem, but I think it's a
superset of the stub network problem, and so solving the stub network
problem is a useful step forward. Solving the constrained network problem
is useful as well, but I don't think we need to fully explore that solution
space before publishing a document that describes how to make a stub
network work. E.g., we have running code on 802.15.4 mesh that implements a
stub network, but have left the discussion of mitigation of bandwidth
mismatches and the like to the standards body that's defined the mesh
protocol (Thread). That doesn't mean that it wouldn't be helpful to write
documents in IETF to talk about this problem—I'm just saying that we're
still doing useful work before we get to that point.


> > However, the vast majority of IPv6 links on the Internet are not
> managed, and so this approach leaves out most networks, specifically home
> and small office networks.
>
> The beginning of the description talks about constrained networks. I have
> a somewhat hard time convincing myself that soho is a constrained network.
> It is important to pick your problem; are we addressing the limited
> bandwidth and other capabilities of truly constrained networks, or are we
> improving the ease of provisioning for more general class of networks, such
> as home networks? Or both?
>

By constrained networks I mean networks with constrained bandwidth,
possibly constrained power and possibly constrained CPU. So not a home
network or SOHO network. But e.g. an 802.15.4 network running 6lowpan that
is connected through a stub router to a SOHO or home network would be a
constrained stub network.


> > This problem is described in detail in draft-lemon-stub-networks-ps, and
> a solution based on IPv6 routing and unicast DNS-SD is described in
> draft-lemon-stub-networks.
> >
> > The goal of this BoF is to figure out where in the IETF to do this work.
> There doesn't seem to be a good match: v6ops isn't entirely right because
> it's an ops working group; 6man doesn't really make sense either. Intarea
> is too general, and unlikely to attract focus. Homenet is being closed, and
> isn't solving quite the same problem anyway. So one obvious option would be
> to form a working group that can focus on this specific problem and serve
> as a place where the work can be finished.
>
> At least for me this jumped somewhat too quickly to the administrative
> question of where the work should happen. I’d suggest the goals to be to
> determine what specific part of the problem is most interesting to address,
> how it is different from other existing solutions or efforts, whether
> devising a solution for that problem is feasible, and finding a place to do
> that work in the IETF.
>

Sure, this is fair. The only reason the venue discussion came up this early
is that one approach to this would be to just say "this is in scope for
working group X, we don't need a new working group." But since we need to
do a BoF to arrive at a clear description of "this," we have a bit of a
recursive interdependency. :)

>
> > We would expect the scope of work to include: - How to connect a stub
> network to an infrastructure network that implements no new functionality
> we might define
>
> Ok, that’s useful, but is this about describing existing network and
> standards functionality, or about operational aspects without new
> technology? Or both? Being specific would be helpful.
>

I've added a small list of specifications that I think are relevant for the
base use case. The problem statement and solution document provide a more
complete list.


> > - Support for automatically adding the stub network to the routing
> topology of the infrastructure network
>
> Ok. This sounds very much like homenet back when we were doing it… I
> realize that this is spelled out in more detail in the -ps, but I think you
> need to say it upfront in the BOF description as well, or eventual charter
> proposal.
>

This actually wasn't what I had in mind. I clarified that I'm talking more
about the DHCPv6 PD use case, where we'd hope that the DHCPv6 server would
add the relevant routes to whatever routing infrastructure the network
already provides, as is done with CE routers when ISPs allocate prefixes to
them.


> > Self-configuring Stub Networks: Problem Statement
> > draft-lemon-stub-networks-ps-02
>
> Quick review of the stub-networks-ps:
>
> Overall good discussion in this document, but probably some work left to
> work on preciseness of definitions and think about what requirements are
> real requirements.


> S1: I think the concept of a ”no transit” stub network is of course
> sensible. And I found the globally reachable and locally reachable notions
> useful, too. And talking about addressability and discoverability at the
> same time makes sense for me as well.
>
> Of course one still has to spend some time specify how the existing
> concept of a stub network needs some specific new work, and what gaps there
> are. I found the explanation of why homenet solutions don’t work
> reasonable. However, I think it would be beneficial to be more precise
> about what specifically is complex/unnecessary in the homenet protocols.
> And requirements. In particular, the later sections talk about some
> requirements as given (e.g., S2.1.4) but it is unclear to me if all those
> requirements are actually needed or if they would incur yet another dose of
> complexity that would prevent deployment.
>

The problem is actually not that homenet is complex, although it is, but
rather that there is no use case that would motivate creating a commercial
homenet router, and hobbyist home routers don't really solve a very general
problem.

Anyway, I'll leave these comments to the next revision of these drafts—they
are much appreciated!

I think the example use cases could be improved upon. Transitory I guess is
> mostly about opportunistic connectivity that changes, not so much about
> whether you have one or multiple routers? Incompatible media is an issue
> (e.g., bandwidth capability differences), but the text talks about
> something else, routers having to collaborate in a group or be provisioned.
>
> S2: Overall good explanation
>
> S2.1.4: Personally, I’m not convinced that the requirement for sharing
> proxy nd function among a set of routers really is a requirement? By your
> own earlier text, at least some examples of stub networks only employ one
> router, hence, if that goes, there’s no connectivity. Are we doing too many
> requirements (again)? Also, the text does not give me a full understanding
> of how big of a burden the use of a registration step
> (draft-ietf-6lo-backbone-router) would be for the hosts in the stub
> network. That would be interesting to know!
>
> S2: Overall, RFC 4191 + optional PD where needed/available seems like a
> minimal approach.
>
> S4: Clearly, this needs more work. But I’m concerned that if you try to
> cover all situations you’ll end up with a complex state-sharing solution
> (as we have in the past).
>
> S6: I did not understand the global reachability privacy implications. For
> sure, if you are addressable you are reachable. But is something plugging
> locally available names to globally reachable DNS? But I’m not really
> familiar enough with the DNS service discovery mechanisms...
>
> > Connecting Stub Networks to Existing Infrastructure
> > draft-lemon-stub-networks-03
>
> Quick review of the stub-networks:
>
> Overall an interesting and reasonable approach. I have some questions
> about whether everything described here is needed, or if the approach could
> be even simpler. Providing addresses for the AIL itself when it doesn’t
> have any, IPv4 support, etc.
>
> S2: Why is discoverability not included in this discussion? Yet for
> instance S3.5 talks about providing discoverability.
>
> S3.1.1: Good
>
> S3.1.2: I’m for some reason not convinced that a stub router needs to
> provide addresses on the AIL. Why would that be the case? A lot of
> complexity ensues, e.g., S3.1.3 and S3.1.4 deal with that. If there was no
> addresses on the AIL, why is that an interesting case and why do we have to
> deal with it? Nothing else would work connected to that link either.
>
> S3.2.2: Is ULA allocation *always* needed? What if there’s a proxy ND?
> What if there’s PD available?
>
> S6.1: Good.
>
> Jari
> --
> Snac mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/snac
>