Re: Comments on presentation of draft-lemon-stub-networks-ps-00

[Ted Lemon <[e-mail]>]

On Jul 28, 2020, at 8:58 AM, Alexandre Petrescu <[e-mail]> wrote:
> - targetting an IPv4 setting: it would be difficult to work on that.  I mean, one could formulate a problem that says 'IPv4' among other things, but then when solution time arrives... write an I-D with a solution in IPv4 space at IETF?
> 
> Maybe formulate it as an 'IP' problem could be considered.

It’s a matter of practicality, whether it’s documented in the IETF or not. We know how to do NAT64, so one way to solve the “cloud-over-IPv4-infrastructure” problem is with NAT64. I don’t think this is unreasonable to document, and I’m certainly not suggesting that it be the primary answer. But practically speaking, if it’s not documented, it will just be done differently in each implementation.

> - more clearly defining a stub network might be necessary.  The slide showed a 'stub router' and a 'stub host' but I am not sure a stub network is made of a stub router and a stub host.  At the same time, it might be that a stub network connecting to another stub network renders this latter just a network (not a stub network).

I would definitely appreciate comments on the document. :)

> This could make think that a stub network might be made of only one subnet(?)

Yes, that’s explicit in the document—sorry for not explaining it.

> - in the slide overviewing the solution space, an additional thing could be mentioned: that of using SLAAC with a non-64 prefix length.

How would this help?  Do you mean something like the 6lo backbone router proposal?  How does subdividing the prefix help with that?