[Snac] My thoughts

[Jari Arkko <[e-mail]>]

I’ve sent these comments earlier to Ted et al but at the time the list did not yet exist. The comments were inspired by reading through the various BOF proposals that were made for the upcoming IETF. 

(I had originally sent my comments couple of weeks earlier. It is possible that the current descriptions and drafts have evolved since then, which is of course good. But if the comments don’t seem to match what you’re currently discussing, that could be one reason.)

—

I find your topic an important one and hope we can make something out of it! 

The comments below are my personal reactions on some of the specific things written in the proposal and drafts, and they are provided in the hopes that feedback helps you improve them further. I’m mostly making a note where I see something that should be spelled out further, something I don’t understand, don’t fully agree, or wonder about possible further simplifications.

> Name: Stub Network Auto Configuration (SNAC) for IPv6
> Description
> We propose a working-group-forming BoF to work on the problem of connecting stub networks to existing infrastructure in the absence of an expert operator.
> 
> 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.

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.

> 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.

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?

> 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?

> 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.

> 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.

> - New functionality we might define for improving connectivity/discoverability that would require support by some devices on the infrastructure network, e.g. - Support for automatically adding stub network DNS-SD service to an existing DNS-SD service provided by the infrastructure network

Ok, that makes sense I think.

> - 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.

> 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.

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