Subject: RE: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix"

From: "Michel Py" <[email-masked]>
Date: Thu, 13 Feb 2003 22:24:58 -0800

Erik / ipv6 folk,

> Erik Nordmark wrote:
> RFC 2374 contained an IPv6 allocation structure that
> included TLA (Top Level Aggregator) and NLA (Next
> Level Aggregator) which is formally made historic by
> this document.
> The TLA/NLA scheme has been replaced by an coordinated
> allocation policy defined by the Regional Internet
> Registries [REF]. Part of the motivations for obsoleting
> the TLA/NLA structure	were technical, for instance there
> was concerns that it was not the technically best
> approach at this point in time on IPv6 deployment.
> Another part of the motivation was that the issues of
> how the IPv6 address space is managed is much more
> related to policy and	to the the stewardship of the IP
> address space and routing table size that the RIRs have
> been managing for IPv4. It is likely that the RIRs
> policy will evolve as IPv6 deployment proceeds.
> The IETF has provided technical input to the RIRs (for
> example [RFC 3177]) that has been taken into account
> when defining the policy.

I was re-reading your text, and I have additional comments.

[disclaimer: I have stated before that it was fine by me, and this still
holds. If consensus is reached on the text you proposed the doc should
be shipped without further delays.]

That being said, I have contradictory / ambiguous feelings about the
omission of "SLA". Here's the contradiction:

- On one side, since you explicitly kill TLA and NLA but not SLA, it is
permitted to think that SLA is not completely dead, which suits me fine
since my position is that although moving it to policy was a good idea,
killing the notion of site boundary was not.

- On the other side, if SLA is not dead it's not alive either, which
makes it a zombie I guess. This is not good, and one of these nights,
when the moon is full, it will rise from the grave like in Michael
Jackson's "thriller" and come haunt us.

Therefore, we have three options for SLA:
1. Don't change the text and keep it a zombie.
2. Kill it (which I don't like).
3. Spare it; the idea being that what we want to do is move it to policy
but don't kill the notion that a site boundary exists. This is what RIRs
call a "soft" or "semi-hard" boundary.

Comments welcome.

Michel.

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Feb 2003 10:53:24 +0100

On balance, I prefer ducking the issue in the draft we are
discussing. If I get a /48 I have 16 bits for subnet addressing
and I'm happy, so why worry about the acronym SLA? The RIRs
have accepted the point (but I still want to see an informational
reference to 3177 to ensure the paper trail is complete).

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Feb 2003 10:53:24 +0100

Brian

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 18 Feb 2003 14:25:56 +0100 (CET)

> call a "soft" or "semi-hard" boundary.

I think the "SLA" field in 2374 has been replaced by the "subnet ID" field
in addr-arch-v3. It probably makes sense to make this clear by
adding a note e.g.
	The SLA (subnet local aggregator) field in RFC 2374 remains in
	function but with a different name in [ADDR-ARCH]; its new
	name is "subnet ID".

  Erik