Subject: [homenet] ANIMA scope + homenet interaction + charter v15

From: Benoit Claise <[email-masked]>
Date: Tue, 28 Oct 2014 21:13:48 +0100

Dear all,

[sorry for double-posting, but we need the specific feedback from the 
HOMENET community]

1. scope
I finished reading the ANIMA mailing list and, based on the feedback, 
Joel, Ted, and I would like to clarify the ANIMA scope for "the set of 
specific reusable infrastructure components that support autonomic 
interactions between devices" (quoting the charter)

The charter currently mentions:
     The ANIMA working group will initially focus on enterprise, ISP 
networks and IoT.

Multiple tracks were discussed on the mailing list.
     * keep enterprise, ISP networks and IoT
     * focus on enterprise and ISP networks
     * everything, but the initial focus is enterprise and carrier?
     * professionally-managed networks

It seems to us that "professionally-managed networks" is what ANIMA is 
after. And it's potentially a distraction to try to segment the scope 
based on enterprise, ISP, homenet, or IoT. What is IoT after all?

OLD:     The ANIMA working group will initially focus on enterprise, ISP 
networks and IoT.
NEW:    The ANIMA working group focuses on professionally-managed networks.

Does it sound about right?

2. Overlap with HOMENET
This distinction in point 1 might help regarding the potential overlap 
of the solution for distributed IPv6 prefix management.
Btw, the new charter has been adapted:
OLD:  A solution for distributed IPv6 prefix management within a network.
NEW: the solution for distributed IPv6 prefix management within a 
large-scale network

Also, The HOMENET collaboration has been stressed in the charter.

3. Others
I believe I took care of the others changes proposed on the mailing. If 
this is not the case, let me know.
At this point in time, please provide concrete change to the charter 
text if some issues persist.
Charter v15 has just been posted, and you can review the detailed 
changes at 
https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-14.txt&difftype=--html&submit=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-15.txt

4. Security Advisor.
I have requested one for ANIMA to the security ADs.

Regards, Benoit

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 Oct 2014 10:25:27 +1300

> Does it sound about right?

Personal opinion: Yes. We should of course seek to make everything we
do as general as possible, so that there are no artificial limits
to its use if successful.

    Brian

> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>

---

From: Rene Struik <[email-masked]>
Date: Tue, 28 Oct 2014 17:37:19 -0400

Hi Benoit:

-1 on you suggestion #1.

I do not think suggesting "constrained networks and devices" to be 
suddenly out of scope helps: it is one of the main areas where 
semi-automatic management is imperative. If one has a bootstrapping 
solution and configuration negotiation/synchronization protocol that is 
not useful in constrained settings, what is the point? In my mind, it 
seems much more prudent to design schemes with constrained networks and 
devices and failure recovery models that apply there (configuration 
mismatch due to sleepy devices, malfunctioning data store, etc.), where 
these would then obviously also fit the less constrained, 
"professionally managed" networks. Design for the"nimble", so that both 
"nimble" and "fatter" networks can use this.

This also has the advantage that one is forced to think in terms of many 
potential actors, rather than a few ones, which helps in viewing 
solutions in terms of heterogeneous rather than homogeneous deployment 
models.

I have done all my reviews of nmrg drafts 
(http://www.ietf.org/mail-archive/web/anima/current/msg00327.html) with 
constrained networks and devices in mind. It would be a shame if one 
would now narrow down the focus and rule this (future almost ubiquitous) 
deployment category out of scope.

Or, is this a political ploy, so as to avoid a turf war with homenet people?

If that is the case, it would be much more prudent to have another BoF 
to iron out some of these issues. {This may be prudent for reasons I 
already indicated in the same #00327 message as well - I will  not 
repeat those arguments here.}

Best regards, Rene

On 10/28/2014 4:13 PM, Benoit Claise wrote:
> OLD:     The ANIMA working group will initially focus on enterprise, 
> ISP networks and IoT.
> I believe I took care of the others changes proposed on the mailing. 
> If this is not the case, let me know.

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 Oct 2014 11:48:08 +1300

On 29/10/2014 10:37, Rene Struik wrote:
> semi-automatic management is imperative. 

Rene has a point. My +1 was with the idea of limiting the initially
worked-out use cases, and avoiding any direct interference with
progress in homenet. But understanding the requirements for
constrained networks is desirable. What I don't know is whether
those requirements can in fact be met by the same infrastructure
components that we need for "professionally managed" networks.
There may simply not be enough overlap between "nimble and
heterogeneous" and "managed and homogeneous."

   Brian

If one has a bootstrapping

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 29 Oct 2014 02:57:17 +0000

Hi, Benoit and all,

Reply in lines.

>Does it sound about right?

Yes, it is right. After we develop a generic protocol/mechanism, it is possible that other people may reuse them in other scenarios. It is out of our current focus, for sure.

>NEW: the solution for distributed IPv6 prefix management within a

That's exactly stated in the individual draft that submitted to anima.

>Also, The HOMENET collaboration has been stressed in the charter.

It would be helpful.

>https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fd
>oc%2Fcharter-ietf-anima%2Fwithmilestones-00-14.txt&difftype=--html&sub
>mit=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-a
>nima%2Fwithmilestones-00-15.txt
>
>
>4. Security Advisor.

It would be great. Many thanks.

Best regards,

Sheng

---

From: Laurent Ciavaglia <[email-masked]>
Date: Wed, 29 Oct 2014 10:55:27 +0100

Dear all,

I agree with Rene and Brian on the need to consider constrained networks.
However, I don't think that "professionally-managed networks" 
automatically exclude such environments.

As Barbara S. mentioned in 
http://www.ietf.org/mail-archive/web/homenet/current/msg04008.html, 
there can be multiple scenarios with different roles, and different 
devices being managed.

My opinion is that covering the scenario of professionally-managed 
consrained (and less constrained) networks is a challenging one, from 
which we could derive "good" common, re-usable protocols/components.

Best regards, Laurent.

On 28/10/2014 23:48, Brian E Carpenter wrote:
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Advanced Internet Research

Bell Labs | Alcatel Lucent

phone: +33 160 402 636

email: [email-masked] 
<mailto:[email-masked]>

linkedin: laurentciavaglia <http://fr.linkedin.com/in/laurentciavaglia/>

address: Route de Villejust | 91620 Nozay | France

---

From: Michael Richardson <[email-masked]>
Date: Wed, 29 Oct 2014 11:15:49 -0400

Laurent Ciavaglia <[email-masked]> wrote:
    > However, I don't think that "professionally-managed networks" automatically
    > exclude such environments.

I would further say that the security work in 6tisch, which is aimed at
industrial networks is made possible because we are assuming a
professionally-managed LLN.

The mechanisms being discussed won't scale down to the home.

The important constraint of the constrained devices is not ram, cpu or stable
storage for ANIMA, but the lack of a VGA and USB connectors for the
monitor/mouse.  Routers usually share the same constraint.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Benoit Claise <[email-masked]>
Date: Wed, 29 Oct 2014 16:46:49 +0100

Hi Linda,
> Beniot,
>
> Is "professionally-managed networks" same as "network service provider network"?
It was intended to say: as opposed to just plug-and-play.
This could be a managed service offered by a ISP, gas meters service in 
a city, etc.

Regards, B.
>
> Linda
>
> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Benoit Claise
> Sent: Tuesday, October 28, 2014 3:14 PM
> To: [email-masked]; [email-masked]
> Subject: [Anima] ANIMA scope + homenet interaction + charter v15
>
> Dear all,
>
> [sorry for double-posting, but we need the specific feedback from the HOMENET community]
>
> 1. scope
> I finished reading the ANIMA mailing list and, based on the feedback, Joel, Ted, and I would like to clarify the ANIMA scope for "the set of specific reusable infrastructure components that support autonomic interactions between devices" (quoting the charter)
>
>       The ANIMA working group will initially focus on enterprise, ISP networks and IoT.
>
> It seems to us that "professionally-managed networks" is what ANIMA is after. And it's potentially a distraction to try to segment the scope based on enterprise, ISP, homenet, or IoT. What is IoT after all?
>
> This distinction in point 1 might help regarding the potential overlap of the solution for distributed IPv6 prefix management.
> NEW: the solution for distributed IPv6 prefix management within a large-scale network
>
> I believe I took care of the others changes proposed on the mailing. If this is not the case, let me know.
> At this point in time, please provide concrete change to the charter text if some issues persist.
> Charter v15 has just been posted, and you can review the detailed changes at https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-14.txt&difftype=--html&submit=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-15.txt
>
>
> 4. Security Advisor.
> .

---

From: Benoit Claise <[email-masked]>
Date: Wed, 29 Oct 2014 17:16:36 +0100

> there can be multiple scenarios with different roles, and different 
Exactly.

Regards, Benoit

---

From: Michael Richardson <[email-masked]>
Date: Wed, 29 Oct 2014 14:04:36 -0400

> 1. scope
    > I finished reading the ANIMA mailing list and, based on the feedback, Joel,
    > Ted, and I would like to clarify the ANIMA scope for "the set of specific
    > reusable infrastructure components that support autonomic interactions
    > between devices" (quoting the charter)

    > after. And it's potentially a distraction to try to segment the scope based
    > on enterprise, ISP, homenet, or IoT. What is IoT after all?

(I came to this thread backwards, sorry)
I agree with this change. +1000.
This gets EXACTLY gets to the point.

---

From: Rene Struik <[email-masked]>
Date: Wed, 29 Oct 2014 23:50:44 -0400

Hi Brian:

It is very puzzling to me to see essential deployments that would be a 
test case on viability of the concept of semi-automatic management (in 
casu: constrained networks and devices) being removed from the charter. 
I have not seen any technical justification for ruling this out of order 
(nor do I know who decides on this - consensus?).

If one emphasizes so much the "professionally managed" aspect, this 
seems to suggest that whatever "solution" Anima (or, perhaps, simply the 
co-authors of the three anima drafts mentioned in the draft charter?) 
have in mind may not meet or closely approximate the whole idea of 
"autonous" operation (at least, as I understand this after reading all 
drafts referred to in the draft charter and producing 15 pages of 
comments on this).

I, for one, think we can minimize these differences and define an 
architecture and a set of protocols that mostly only differ in policy 
and configuration settings for "professionally managed" and "highly 
constrained devices and networks". I think I have made this point in my 
extensive comments.

I am happy to make this concrete once the group meets during IETF-91, 
but certainly already declaring things out of order without accompanying 
technical discussion and analysis, effectively stymies this.

During IETF-91, I think we need to spend much more time on discussing 
draft-irtf-nmrg-an-gap-analysis and 
draft-irtf-nmrg-autonomic-network-definitions-04, since improving those 
seem to attack the festering chartering problems at the heart. I would 
happily volunteer elaborating on this during the two Anima meeting slots.

Best regards, Rene

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 30 Oct 2014 11:08:01 +0200

On 28.10.2014, at 22.13, Benoit Claise <[email-masked]> wrote:
> 1. scope
> OLD:     The ANIMA working group will initially focus on enterprise, ISP networks and IoT.

+1. This is what I was trying to get earlier (but apparently just dropping IoT did not describe it fully due to potentially managed IoT networks too; I am too stuck in my home IoT rut I guess).

> NEW: the solution for distributed IPv6 prefix management within a large-scale network

I would personally rather drop prefix management. At least, the current proposed solution is DHCPv6 PD plus lot of marketing plus one extra thing (role) minus tons of existing functionality. I would rather stick the role into PD, than reinvent the protocol.

If there is not something more novel there (that is, not hierarchical PD in disguise), I do not see the point.

> Charter v15 has just been posted, and you can review the detailed changes at https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-14.t…

I think it is mostly fine, although the use of term ‘autonomous’ for essentially (on high level) managed devices that perform some low-level autonomic functions sounds still strange to me. I guess I could live with it though.

Cheers,

-Markus

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Oct 2014 08:00:01 -0400

> I would personally rather drop prefix management. At least, the current proposed solution is DHCPv6 PD plus lot of marketing plus one extra thing (role) minus tons of existing functionality. I woul…

Hierarchical PD doesn't work or even make sense.   Flow-through PD does, but hasn't been described in an RFC: there is no mechanism for autonomously configuring the relay structure or installing routes.   So I think it's appropriate to do this work in ANIMA (I know there is no enthusiasm for it in homenet).   Or, if that turns out to be an inadequate solution, to do something else.

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 30 Oct 2014 14:08:17 +0200

> Hierarchical PD doesn't work or even make sense.   Flow-through PD does, but hasn't been described in an RFC: there is no mechanism for autonomously configuring the relay structure or installing ro…

I hope someone tells that to Cablelabs, I thought eRouter spec had hierarchical PD (=hipnet).

ANIMA’s current solution[1] does not seem to deal with autonomously configuring the delegation hierarchy, or routes in general at all currently.

What does flow-through PD mean? Do you have any reference on that?

Cheers,

-Markus

[1] http://tools.ietf.org/html/draft-jiang-anima-prefix-management-00

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Oct 2014 09:04:53 -0400

> What does flow-through PD mean? Do you have any reference on that?

It means that the edge router has the delegation, and then sub-delegates individual /64s from the pool of /64s it was delegated by the ISP, rather than splitting its delegation and delegating chunks of that delegation to downstream routers which will then delegate in turn.   In order for this to work, downstream routers have to relay PD requests to the edge router, and install routes to the delegated prefixes.   Something analogous could work on an autonomous network; I don't know that it's the right way to solve the problem, but it's certainly one way to solve the problem.   Homenet went with HNCP because it's more sensitive to arbitrary topology changes.

The hierarchical model doesn't work because it doesn't anticipate new routers being added to the network, and doesn't account for unbalanced topologies.   I thought the hipnet proposal wound up going with the flow-through model, not the hierarchical model, but I may be mistaken.

---

From: Ole Troan <[email-masked]>
Date: Thu, 30 Oct 2014 14:15:17 +0100

> The hierarchical model doesn't work because it doesn't anticipate new routers being added to the network, and doesn't account for unbalanced topologies.   I thought the hipnet proposal wound up goi…

I think the homenet wg did a good of analysing the 3 variants proposed.
the "flow-through" model as far as I can recall suffers from DHCP's general problem of dealing with multiple sources of information (think multihoming with separate CE routers), in addition you either need to build what's essentially a spanning tree of DHCP relays or you need some mechanism to discover the set of DHCP server(s). certainly do-able, but not quite out of the box.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Oct 2014 09:26:33 -0400

> the "flow-through" model as far as I can recall suffers from DHCP's general problem of dealing with multiple sources of information (think multihoming with separate CE routers), in addition you eit…

Actually it doesn't suffer from this problem.   You just wind up getting a prefix delegation per edge router, and when you get a delegation, you add that edge router to the list of routers to which you will relay downstream prefix delegation requests.   You do not need spanning tree because if you reach the same router through two different paths, you will just get the same delegation twice per DUID/IAID.

The reason homenet didn't go with this solution is essentially that HNCP has a better feature set and is easier to make work in a homenet environment.

(To be clear, I am just explaining the prefix delegation model.   If Anima doesn't want to do it that way, that's fine with me, just as it's fine with me that homenet went with HNCP.)

---

From: Ralph Droms <[email-masked]>
Date: Thu, 30 Oct 2014 09:43:50 -0400

> Actually it doesn't suffer from this problem.   You just wind up getting a prefix delegation per edge router, and when you get a delegation, you add that edge router to the list of routers to which…

There may be a couple of areas where some small amount of protocol specification work would be required for the flow-through model:

* the requesting router would have to know to accept delegated prefixes from multiple delegating routers rather than just choosing one delegating router
* either each server would have to have its own set of relay agents, or a single set of relay agents would have to be provisioned dynamically with the list of delegating routers

- Ralph

---

From: Ole Troan <[email-masked]>
Date: Thu, 30 Oct 2014 14:46:35 +0100

Ted,

> (To be clear, I am just explaining the prefix delegation model.   If Anima doesn't want to do it that way, that's fine with me, just as it's fine with me that homenet went with HNCP.)

it isn't as obvious as you make it out to be. there is no point in us arguing over that here (we have had this exact argument previously), write a draft if you think the flow-through model is viable in a network with multiple edges and arbitrary topology.

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Oct 2014 08:31:33 +1300

> If there is not something more novel there (that is, not hierarchical PD in disguise), I do not see the point.

It is specifically not bound to be hierarchical. The idea is that peer devices
can provide resource (IPv6 prefixes) to each other when one of them runs low,
and that is a specific use case for carriers. Perhaps it's badly explained.
It was chosen explicitly as a very simple but real use case. (There is a
more complex case which is sharing IPv4 resources between AFTRs but we
took that out to keep things simple.)

I don't understand what you mean about marketing.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Oct 2014 08:43:18 +1300

Rene,

> (nor do I know who decides on this - consensus?).

Well, it's technically the IESG that charters WGs but they do always
look for rough consensus. However, I don't believe the new wording excludes
IOT, it simply doesn't mention it.

> constrained devices and networks". I think I have made this point in my

I would be happy with that result. I am interpreting "professionally
managed" very liberally, but it does seem to me that things like
building services networks are both highly constrained and professionally
managed.

> draft-irtf-nmrg-autonomic-network-definitions-04, 

Unfortunately the NMRG, which "owns" those documents, has chosen
not to meet at the IETF site. Your comments were closely studied
during the most recent revision of both drafts. The result is of course
a compromise between the authors' views and yours.

   Brian

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 31 Oct 2014 05:53:16 +0000

>I would personally rather drop prefix management. At least, the current
>proposed solution is DHCPv6 PD plus lot of marketing plus one extra thing
>(role) minus tons of existing functionality. I would rather stick the role into PD,
>than reinvent the protocol.

DHCPv6 PD has only solve the prefix request and assign process based on the preconditions:

a) the requesting router knows the prefix length it should request;
b) the requesting router knows what device to send the request;
c) The requested device have enough resource for the request.

However, human configuration or human intervention are needed to meet these preconditions. The current proposed solution focuses on to autonomic processes to solve these preconditions.

Best regards,

Sheng

>> Charter v15 has just been posted, and you can review the detailed changes
>at
>I think it is mostly fine, although the use of term ‘autonomous’ for
>essentially (on high level) managed devices that perform some low-level
>autonomic functions sounds still strange to me. I guess I could live with it
>though.
>
>Cheers,
>
>-Markus
>
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 31 Oct 2014 06:31:48 -0400

> a) the requesting router knows the prefix length it should request;

It should always request a single /64.

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 31 Oct 2014 12:54:15 +0000

>From: Anima [mailto:[email-masked]] On Behalf Of Ted Lemon
>Sent: Friday, October 31, 2014 6:32 PM
>To: Sheng Jiang
>Cc: Benoit Claise; [email-masked]; Markus Stenberg; [email-masked]
>Subject: Re: [Anima] [homenet] ANIMA scope + homenet interaction +
>charter v15
>

Are you talking about assigning prefix for homenet? I thought we were talking about auto prefix management in a large network, which is ANIMA use case.

Sheng

---

From: Ted Lemon <[email-masked]>
Date: Fri, 31 Oct 2014 10:34:01 -0400

> Are you talking about assigning prefix for homenet? I thought we were talking about auto prefix management in a large network, which is ANIMA use case.

In either case, it's important to make the distinction between prefix assignment and prefix delegation.   In an autonomous network, I don't think it's practical to do hierarchical prefix delegation.   That has the unfortunate consequence that there can't be any routing aggregation.   The delegating router can of course _try_ to keep the topology clean, but routing has to work even if it fails.

That being the case, every delegation _request_ should be for a /64, because every delegation request should be a request for a /64 to configure on an interface of a router.   Whether or not aggregation occurs is up to whichever device is the delegating router.   Having a distributed delegation framework is probably a good idea, but a hierarchical distribution won't work, so the idea that a router could request prefixes to be delegated and then re-delegate some of those prefixes is, IMHO, not going to work.

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 31 Oct 2014 14:55:20 +0000

Hi, Ted,

I now understand your point. Your arguments do make sense. The current general mechanism are too general to work for the use case of hierarchical prefix delegation. But if we add hierarchical topology and no bypass requests as constraint conditions, we may be able to make hierarchical prefix delegation work.

Best regards,

Sheng
________________________________________
From: Ted Lemon [[email-masked]]
Sent: 31 October 2014 22:34
To: Sheng Jiang
Cc: Benoit Claise; [email-masked]; Markus Stenberg; [email-masked]
Subject: Re: [Anima] [homenet] ANIMA scope + homenet interaction + charter v15

---

From: Ted Lemon <[email-masked]>
Date: Fri, 31 Oct 2014 11:47:47 -0400

On Oct 31, 2014, at 10:55 AM, Sheng Jiang <[email-masked]> wrote:
> The current general mechanism are too general to work for the use case of hierarchical prefix delegation. But if we add hierarchical topology and no bypass requests as constraint conditions, we may be able to make hierarchical prefix delegation work.

No, that is not the point I am making.   The point I am making is that hierarchical delegation simply won't work, no matter what mechanism you put in place to do it, because the network has to be able to grow incrementally.   With that as a base assumption, you cannot predict where the network will grow, so you don't know how to construct the hierarchy.   Once the hierarchy is constructed, you would have to renumber on a regular basis to make hierarchical delegation work.   I think it is preferable to simply allow for a complete routing table, and then try as best as possible to make routing hierarchical, without demanding perfection.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 31 Oct 2014 18:12:45 +0100

Le 31/10/2014 16:47, Ted Lemon a écrit :
>> The current general mechanism are too general to work for the use
>> case of hierarchical prefix delegation. But if we add hierarchical
>> topology and no bypass requests as constraint conditions, we may be
>> able to make hierarchical prefix delegation work.
>
> No, that is not the point I am making.   The point I am making is
> that hierarchical delegation simply won't work, no matter what
> mechanism you put in place to do it, because the network has to be
> able to grow incrementally.   With that as a base assumption, you
> cannot predict where the network will grow, so you don't know how to
> construct the hierarchy.   Once the hierarchy is constructed, you
> would have to renumber on a regular basis to make hierarchical
> delegation work.

At which point one wonders whether Router Renumbering RFC2894 may need 
some updates.

Alex

    I think it is preferable to simply allow for a
> complete routing table, and then try as best as possible to make
> routing hierarchical, without demanding perfection.
>
> _______________________________________________ homenet mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/homenet
>
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 31 Oct 2014 15:10:30 -0400

On Oct 31, 2014, at 1:14 PM, Alexandre Petrescu <[email-masked]> wrote:
> At which point one wonders whether Router Renumbering RFC2894 may need some updates.

I don't think that's the right approach.   Renumbering makes sense when it's needed, but renumbering whenever you need to balance the routing hierarchy?   That's a lot of pain for a very minimal return.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 01 Nov 2014 08:25:58 +1300

> No, that is not the point I am making.   The point I am making is that hierarchical delegation simply won't work, no matter what mechanism you put in place to do it, because the network has to be a…

Well yes. That's exactly why in autonomic management of prefixes,
we need peer to peer negotiation, as in "I need 3 /64s that I
don't have, do you have any spare ones for me?" Maybe it's
badly explained but that is the whole point of our use case.

   Brian

---

From: Ted Lemon <[email-masked]>
Date: Fri, 31 Oct 2014 16:04:42 -0400

> badly explained but that is the whole point of our use case.

Sure, you can approach it as a sort of flood fill algorithm that tries to optimize for route aggregation, but copes if that optimization doesn't pan out.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 31 Oct 2014 19:28:46 -0400

> On Oct 31, 2014, at 4:04 PM, Ted Lemon <[email-masked]> wrote:
> 
Do we have use cases in which the number of links is so large that unaggregated routing tables will be a problem?

- Ralph

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 01 Nov 2014 13:19:08 +1300

> Do we have use cases in which the number of links is so large that unaggregated routing tables will be a problem?

Not that I'm aware of. In the case of a carrier, the prefix will be aggregated
anyway when it is announced to peer carriers, and possibly aggregated
regionally anyway if it's a very large carrier. Of course, there will be
a scaling limit and that should be a consideration in the design.

    Brian