initial issues

[smd@ebone.net (Sean Doran)]

A summary so far, with a bias in favour of my own opinions... :-)

* A charter & milestones thingie needs to be done to meet IESG
  bureaucratic schedule.

* There was a brief behind-the-scenes discussion, about the definition
  of multihoming, which seemed to result in "being logically connected 
  to more than one TLA or NLA simultaneously".

* This  started off a thread in private about what
the address assignment policy for v6 should be.  Randy noted also that
the IESG has asked for a revision to §2.5.6 of 
draft-ietf-ipngwg-addr-arch-v3-04.txt to make it classless rather
than clasful.  In other words, the multihoming environment for v6
is going to be identical to v4, viz. CIDR.   TLA/NLA will no longer exist.

Wording change for multihoming: "introducing prefixes visible within
at least two ASes" is a simplistic definition.   One might want to
look at various narrowings of the definition of AS in that over time,
but solviing that problem is a current issue.

On allocation policy, my suggestion is that we copy exactly what
v4's BCP is with respect to address assignments.  That is, the
existing registries slow-start eligible providers into a /20,
letting them grow into the adjacent /19, and so on based on
demonstrated utilization of the address space.   I also suggested
that since we have no swamp or TWD in v6 to start with [although
ngtrans may weaken this assumption], we can relax by approximately
two bits the slow-start initial allocation.  That is, we can hand
out /22s to all who qualify on the grounds that we will be able
to manage ~10**6 prefixes reasonably well with current IDR technology.

We currently handle ~10**5 in a shaky fashion, and alot of those
prefixes are a combination of Toxic Waste Dump, swamp, and aggregation
entropy.  According to Vijay Gill, the last is the biggest current 
contributor, rather than multihoming.

Increases in prefixes because of address space depletion will be
rare in v6: few will slow-start beyond the initial /22.  There
will be some growth in the number of slow-starting entities over
time, accounting for some growth; also, although we have no TWD
or swamp, aggregation entropy seems inevitable in the absence of
prefix-length filters being successfully maintained in strategic
parts of the v6-Internet.

There was also some conversation about "current IDR technology",
namely BGP, and how it scales as the number of prefixes, policy-
decisions-per-prefix and sessions per router, increase over time.
That is, not very well: it does not seem affordable to go much
beyond a million prefixes, whether those million prefixes are
v4, v6, a combination of the two, or some other multiprotocol-BGP-using
ships-in-the-night internetworking protocol.

That is to say, v6-CIDR does not introduce any new IDR technology scaling
issues beyond an increase in the total number of prefixes.   This does
not speak at all to managing/operation of ships-in-the-night routing, etc., 
which is a completely different matter.   Also, this is focused exclusively
on the IDR aspect of v6-CIDR, which is orthogonal to the actual forwarding 
of v6 packets.

So, carrying on from here, I suggest that the wg can spend some
time initially getting v6-CIDR right, by fine-tuning the BCP and
other v4-CIDR material.  This would be productive, particularly if
the address people can get sensible guidelines for the allocation
of v6 addresses.

Some codification of BCP that has never been written down for
the v4 Internet, with respect to multihoming, would probably
be a good second step.

Given that v6 has hooks for magical (re-)numbering, it would be
interesting to explore how they should work inside a set of v6
routers and hosts which are suddenly multihomed to a new entity,
or de-homed from one of 'n' entities.  In some cases, the v6 host
need do nothing, just like a v4 host today.   However, a set of
v6 objects (routers/hosts) which have been granted PA space, from
someone else's /22, who then seek to acquire a /22 of their own,
should renumber into the new PI space they have been granted,
rather than introduce a "hole".   v6-renumbering work should
be pressed to focus on this particular problem, since the lack
of v4 ease of renumbering is responsible for a substantial amount
of aggregation entropy as singly-homed entities first become
multihomed.

Is this wg a good place to work on non-CIDR multihoming?
That is, will we look at GSE and address-per-provider multihoming
models as well as the v6-CIDR one?   Those may be good steps
as well, however I think that reality would require making
v6-CIDR Just Work first and foremost, since the IDR technology
is already there for that & doesn't have to be invented from scratch.

	Sean.