Re: Automatically connecting stub networks...

[David Farmer <[e-mail]>]

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]> 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>.
>
> The IETF Secretariat
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 
===============================================
David Farmer               Email:[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
===============================================