Subject: [Anima] I-D Action: draft-ietf-anima-prefix-management-00.txt

From: [email-masked]
Date: Mon, 11 Jan 2016 11:56:22 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Autonomic Networking Integrated Model and Approach Working Group of the IETF.

        Title           : Autonomic IPv6 Edge Prefix Management in Large-scale Networks
        Authors         : Sheng Jiang
                          Zongpeng Du
                          Brian Carpenter
                          Qiong Sun
	Filename        : draft-ietf-anima-prefix-management-00.txt
	Pages           : 14
	Date            : 2016-01-11

Abstract:
   This document describes an autonomic solution for IPv6 prefix
   management at the edge of large-scale ISP networks.  An important
   purpose of the document is to use it for validation of the design of
   various components of the autonomic networking infrastructure.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-prefix-management/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-anima-prefix-management-00

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Jan 2016 10:46:21 +1300

Hi,

There are extensive changes in this compared to the pre-WG draft,
so please review it and send your comments to the list.

Regards
   Brian

P.S. We hope to release a major update to the GRASP specification
in the coming days.

On 12/01/2016 08:56, [email-masked] wrote:
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 12 Jan 2016 12:46:02 -0500

My thanks to the authors for all the work on this.  It is now very clear 
what it is attempting to do, and why.

This appears to surface an issue with what it means to support an 
objective.  The PrefixManager objective seems to include two kinds of 
parties.  One kind just wishes to receive Anima Prefix Delegation (for 
example, and edge device participates in the objective, but generally 
will not hand part of its allocated prefix to another edge device.  The 
other kind both requests prefixes (unless it happens to be the source of 
all knoweldge) and delegates them using Anima.

This distinction is supported in the sense that redirection permits it 
happen.  But determining how a device would decide to redirect vs 
answer, and how the policy system would cause things to behave right, 
seems very difficult to extract from the system.

This is similar to the notion relative to DHCPv6 PD, where one may 
support PD for purposes of requesting prefixes, for purposes of granting 
prefixes, or both.  But all we have is a single bit.

Yours,
Joel

On 1/11/16 4:46 PM, Brian E Carpenter wrote:
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Jan 2016 14:48:32 +1300

On 13/01/2016 06:46, Joel M. Halpern wrote:
> My thanks to the authors for all the work on this.  It is now very clear what it is attempting to do, and why.
> 
> This appears to surface an issue with what it means to support an objective.  The PrefixManager objective seems to include two
> kinds of parties.  One kind just wishes to receive Anima Prefix Delegation (for example, and edge device participates in the
> objective, but generally will not hand part of its allocated prefix to another edge device.  The other kind both requests
> prefixes (unless it happens to be the source of all knoweldge) and delegates them using Anima.

Right. The protocol is certainly agnostic on that issue; it's more a question
of the role and capabilities of a given ASA. That's an issue we have ducked
so far.

> This distinction is supported in the sense that redirection permits it happen.  But determining how a device would decide to
> redirect vs answer, and how the policy system would cause things to behave right, seems very difficult to extract from the system.

Yes. I do note that an ASA that does not listen for incoming requests will
never respond to them, however!

   Brian

> 
> This is similar to the notion relative to DHCPv6 PD, where one may support PD for purposes of requesting prefixes, for purposes
> of granting prefixes, or both.  But all we have is a single bit.
> 
> Yours,
> Joel
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Jan 2016 11:11:09 -0500

Joel M. Halpern <[email-masked]> wrote:
> happen.  But determining how a device would decide to redirect vs answer, and
> how the policy system would cause things to behave right, seems very
> difficult to extract from the system.

I think you are asking about scenario where device A asks device B for some
space, but... while device B has some space, and it could allocate it,
topologically it might make more sense for device B to redirect device A to
device C, which has a larger pool.

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 18 Jan 2016 12:03:24 -0500

There are a number of cases where device B should not give an address 
block to device A.  Some seem to work more easily than others, but 
without configuration it is hard to see from the document how they are 
supposed to work.

The simplest case is where B has gotten address space for allocation to 
customers.  If it reallocates part of that to another device, 
topological abstraction becomes harder, and it is likely to simply need 
to make another request sooner.

Conceptually, this could even be generalized to B supports the 
objective, but has no logic for handing out addresses.  It simply is not 
built to do that.  We could require that all objective supporters always 
support both the request role and the allocator role, but that seems to 
make implementations more complex.

Another case is the one you suggest where topologically, it would be 
better for A to get its address block from a different participant.

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Jan 2016 07:55:55 +1300

Joel,

Yes, there are numerous scenarios and cases. From a standards point of view,
I think we have to ask several questions:

1. Can we define the Objective and the related Intent with semantics that are
sufficient to cover all the scenarios?

2. Can we we make writing an ASA sufficiently straightforward that vendors,
or even sophisticated operators, can write their own ASA for a particular
scenario?

[To be concrete, for example, an ASA that asks for prefixes, but does
not hand out prefixes, will simply never listen for incoming negotiation
requests; it will only send them. An ASA that does hand out prefixes will
also listen for requests and will apply the relevant Intent when negotiating
them.]

3. What does this tell us about authorization and roles for ASAs (a topic that
we have set aside so far)?

4. Does any of this lead to new or different requirements for GRASP itself?

Regards
   Brian

On 19/01/2016 06:03, Joel M. Halpern wrote:
> There are a number of cases where device B should not give an address block to device A.  Some seem to work more easily than
> others, but without configuration it is hard to see from the document how they are supposed to work.
> 
> The simplest case is where B has gotten address space for allocation to customers.  If it reallocates part of that to another
> device, topological abstraction becomes harder, and it is likely to simply need to make another request sooner.
> 
> Conceptually, this could even be generalized to B supports the objective, but has no logic for handing out addresses.  It simply
> is not built to do that.  We could require that all objective supporters always support both the request role and the allocator
> role, but that seems to make implementations more complex.
> 
> Another case is the one you suggest where topologically, it would be better for A to get its address block from a different
> participant.
> 
> Yours,
> Joel
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 18 Jan 2016 14:05:00 -0500

I agree with your points Brian.
As written, the current text implies that all participants in this 
Objective are preapred to delegate address, but they can sometimes refer 
a requestor to someone else anyway.  It allows the needed behavior, it 
is just unclear about how one would cause it to happen.

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Jan 2016 08:15:20 +1300

On 19/01/2016 08:05, Joel M. Halpern wrote:
> As written, the current text implies that all participants in this Objective are preapred to delegate address, but they can
> sometimes refer a requestor to someone else anyway.  It allows the needed behavior, it is just unclear about how one would cause
> it to happen.

Yes, we should modify the text to make it clear that not all ASAs will behave
the same way in this regard.

   Brian