Subject: [Anima] Warren Kumari's No Objection on draft-ietf-anima-prefix-management-06: (with COMMENT)

From: Warren Kumari <[email-masked]>
Date: Wed, 13 Dec 2017 12:48:24 -0800

Warren Kumari has entered the following ballot position for
draft-ietf-anima-prefix-management-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-prefix-management/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you.

I did have some comments / questions.
I'd also like to draw both the authors, and AD's attention to Fred Bakers
excellent thoughts in his OpsDir review -
https://datatracker.ietf.org/doc/review-ietf-anima-prefix-management-06-opsdir-lc-baker-2017-10-23/

Firstly, a global concern:
This technique (and I suspect many automated prefix allocations where a device
uses space, and then requests more) is likely (I think) to result in
fragmentation of the address space - this will lead to more routing entries in
the IGP, which may be an issue for smaller routers or "L3 switches". I think
that it would be useful to note this.

I also wanted to make sure that the author of this document were aware of the
CASM BoF from IETF98 - I've just checked, and see that at least Qiong Sun was
associated with the work (draft-xie-ps-centralized-address-management).

I had a question -- I don't really understand what: [Page 9] "A gateway router
in a hierarchical network topology normally provides prefixes for routers
within its subnet, ..." is trying to say. I've seen many "hierarchical network
topologies" and don't believe this to be true, nor do I really understand what
"its subnet" means. In some cases a router will announce an aggregate for
customers behind it, but I don't really view that as a general case. I'm
guessing I'm just not understanding - can you please educate me?

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Dec 2017 13:48:34 +1300

On 14/12/2017 09:48, Warren Kumari wrote:
...

That devil is in the details, but you're correct, that is a risk. How big a risk
depends on the algorithms and policies used. If we get to update the draft,
this would be a good point to add.
 
> associated with the work (draft-xie-ps-centralized-address-management).

Yes, in fact it would mesh quite nicely with CASM. That's the main reason
I pushed to have the C in CASM mean "coordinated" instead of "centralized".
 
> guessing I'm just not understanding - can you please educate me?

Hmm. In a manually designed network (especially with v6) I'd expect
the initial design would be done in something close to a binary tree,
but in the real world things tend to drift from that starting point
over the lifetime of the network. But I think the phrasing is probably
trying to say too much in too few words. All it's really trying to say
is that the ability to negotiate with an arbitrary peer is more powerful
than only being able to ask your upstream for more prefixes.

Again, happy to clarify the wording if we update the draft again.

   Brian

---

From: Warren Kumari <[email-masked]>
Date: Wed, 13 Dec 2017 20:58:43 -0500

Ok, I'm happy.

If you do update, I think that the last point is the most confusing,
and needs the most work, but I'm as I said, I'm a happy camper.
W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: "Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Thu, 14 Dec 2017 14:15:12 +0000

Hello,

> This technique (and I suspect many automated prefix allocations where 
> a device uses space, and then requests more) is likely (I think) to 
> result in fragmentation of the address space - this will lead to more 
> routing entries in the IGP, which may be an issue for smaller routers 
> or "L3 switches". I think that it would be useful to note this.

That devil is in the details, but you're correct, that is a risk. How big a risk depends on the algorithms and policies used. If we get to update the draft, this would be a good point to add.

>>Laurent: not providing a definitive answer / solution, but if we see more deployment of autonomic functions (such as automatic/autonomic prefix management), we can imagine to also have functions taking care of the fragmentation and re-aggregation in an automatic/autonomic way. Thus, the risk _could_ _eventually_ be minimized.

>>Laurent: if the issue for small(er) routers / L3 switches is on performance, then there is usually Moore's law that can help address it in a few years span (even with degraded Moore's law). If the issue is complexity, then this is an additional case to have more autonomic (read: intelligent) functions running simultaneously in the network / in the devices.

Best regards, Laurent.

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Thursday, December 14, 2017 1:49 AM
To: Warren Kumari <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Toerless Eckert <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Anima] Warren Kumari's No Objection on draft-ietf-anima-prefix-management-06: (with COMMENT)

> I'd also like to draw both the authors, and AD's attention to Fred 
> Bakers excellent thoughts in his OpsDir review - 
> This technique (and I suspect many automated prefix allocations where 
> a device uses space, and then requests more) is likely (I think) to 
> result in fragmentation of the address space - this will lead to more 
> routing entries in the IGP, which may be an issue for smaller routers 
> or "L3 switches". I think that it would be useful to note this.

That devil is in the details, but you're correct, that is a risk. How big a risk depends on the algorithms and policies used. If we get to update the draft, this would be a good point to add.
 
> 
> I also wanted to make sure that the author of this document were aware 
> of the CASM BoF from IETF98 - I've just checked, and see that at least 
> Qiong Sun was associated with the work (draft-xie-ps-centralized-address-management).

Yes, in fact it would mesh quite nicely with CASM. That's the main reason I pushed to have the C in CASM mean "coordinated" instead of "centralized".
 
> I had a question -- I don't really understand what: [Page 9] "A 
> gateway router in a hierarchical network topology normally provides 
> prefixes for routers within its subnet, ..." is trying to say. I've 
> seen many "hierarchical network topologies" and don't believe this to 
> be true, nor do I really understand what "its subnet" means. In some 
> cases a router will announce an aggregate for customers behind it, but 
> I don't really view that as a general case. I'm guessing I'm just not understanding - can you please educate me?

Hmm. In a manually designed network (especially with v6) I'd expect the initial design would be done in something close to a binary tree, but in the real world things tend to drift from that starting point over the lifetime of the network. But I think the phrasing is probably trying to say too much in too few words. All it's really trying to say is that the ability to negotiate with an arbitrary peer is more powerful than only being able to ask your upstream for more prefixes.

   Brian

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