Re: Automatically connecting stub networks...

[Alexandre Petrescu <[e-mail]>]

I think I agree.  And the word 'nesting' was not appropriate either.

Indeed it's probably more like a stub being promoted to become part of core.

But the requirement should the there to allow the network to scale up to 
bigger.

Alex

Le 10/07/2020 à 11:35, David Farmer a écrit :
> Wait a minute, if you connect a stub to another stub, the previous stub 
> isn’t a stub any longer. Maybe you want to talk about how to promote a 
> stub automatically by automatically connecting a new stub to it, but the 
> previous stub is proving transit for the new stub and is now a backbone 
> or core network, but most certainly not a stub network, at least by any 
> definition I understand.
> 
> On Fri, Jul 10, 2020 at 04:13 Alexandre Petrescu 
> <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     and there should be a requirement also on 'nesting' - a stub that
>     attaches to a stub that attaches to a stub...
> 
>     Alex
> 
>     Le 10/07/2020 à 11:12, Alexandre Petrescu a écrit :
>>     as titled I think the draft makes sense.
>>
>>     In the requirements section, the requirements which talk about
>>     Prefix Delegation, I think it makes sense to think about a new
>>     requirement: that of automatically forming sub-prefixes.
>>
>>     This is a potentially very simple operation, so simple that it
>>     might get unnoticed when implemented.  Yet some implementations do
>>     differ in the way they form sub-prefixes.
>>
>>     I mean, in this text:
>>>     2.3.4.  Requirements
>>>
>>>        o  Infrastructure network must support prefix allocation using
>>>     DHCPv6
>>>           prefix delegation.
>>>
>>>        o  Infrastructure network must install routes to prefixes
>>>     provided
>>>           using DHCPv6 prefix delegation.
>>>
>>>        o  In the case of multiple stub routers, stub routers must
>>>     cooperate
>>>           both in acquiring and renewing prefixes acquired using prefix
>>>           delegation.  Stub routers must communicate complete routing
>>>           information to the DHCPv6 prefix delegation server so that
>>>     it can
>>>           install routes.
>>
>>     Suggested additional requirement: A stub router should be able to
>>     automatically form at least one /65 out of the /64 received from
>>     the DHCPv6 Prefix Delegation Server.
>>
>>     Something like that.
>>
>>     There are several potential rules that can be written down in a
>>     programmatic manner.  These rules might express how many
>>     sub-prefixes to form, of which length.
>>
>>     This formation of sub-prefixes out of a received prefix should not
>>     be hardcoded.  The immediate rule that comes to mind is to form
>>     /65s out of a /64.   But it is not the only rule, and as such it
>>     should not be hardcoded.
>>
>>     (but that's disgressing into the solution space)
>>
>>     Alex
>>
>>
>>     Alex
>>
>>
>>     Le 10/07/2020 à 08:25, Ted Lemon a écrit :
>>>     I mentioned prior to IETF 107 that I wanted to start a
>>>     conversation about this problem, but didn’t have time to write a
>>>     draft.  I’ve written one, which I think describes my view of the
>>>     problem pretty well; I’d like to know if what I’ve written here
>>>     makes sense to others.  This is semi-related to the Homenet
>>>     problem, but doesn’t try to do as much, which makes the problem a
>>>     bit more tractable, and addresses at least one fairly important
>>>     use case.
>>>
>>>     A new version of I-D, draft-lemon-stub-networks-ps-00.txt
>>>     has been successfully submitted by Ted Lemon and posted to the
>>>     IETF repository.
>>>
>>>     Name:draft-lemon-stub-networks-ps
>>>     Revision:00
>>>     Title:Self-configuring Stub Networks: Problem Statement
>>>     Document date:2020-07-08
>>>     Group:Individual Submission
>>>     Pages:15
>>>     URL:
>>>     https://www.ietf.org/internet-drafts/draft-lemon-stub-networks-ps-00.txt
>>>
>>>     Status:
>>>     https://datatracker.ietf.org/doc/draft-lemon-stub-networks-ps/
>>>     Htmlized:
>>>     https://tools.ietf.org/html/draft-lemon-stub-networks-ps-00
>>>     Htmlized:
>>>     https://datatracker.ietf.org/doc/html/draft-lemon-stub-networks-ps
>>>
>>>
>>>     Abstract:
>>>        IETF currently provides protocols for automatically connecting
>>>     single
>>>        hosts to existing network infrastructure.  This document
>>>     describes a
>>>        related problem: the problem of connecting a stub network (a
>>>        collection of hosts behind a router) automatically to existing
>>>        network infrastructure in the same manner.
>>>
>>>
>>>
>>>
>>>     Please note that it may take a couple of minutes from the time of
>>>     submission
>>>     until the htmlized version and diff are available at
>>>     tools.ietf.org <http://tools.ietf.org> <http://tools.ietf.org>
>>>     <http://tools.ietf.org>.
>>>
>>>     The IETF Secretariat
>>>
>>>     --------------------------------------------------------------------
>>>     IETF IPv6 working group mailing list
>>>     [e-mail] <mailto:[e-mail]>
>>>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>     --------------------------------------------------------------------
>>>
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail] <mailto:[e-mail]>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     --------------------------------------------------------------------
> 
> -- 
> ===============================================
> David Farmer Email:[e-mail] <mailto:[e-mail]>
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: [phone]
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================