AW: I-D ACTION:draft-ietf-v6ops-addcon-01.txt

["Bonness, Olaf" <Olaf.Bonness@t-systems.com>]

Hi Brian,

thanks for your comments. My answers are in-line.

------------- Snip --------------------------------------------------
>
> >    value of 0.96 for IPv4.  Note that for IPv6 HD is calculated for
> >    sites (i.e. on a basis of /48), instead of based on 
> addresses like
> >    with IPv4.
> 
> Perhaps it would be wiser to make the parenthesis
>       (e.g. on a basis of /48)

Yes, thats better. Agreed.

> 
> Thanks for adding the ISP case. Some comments...
> 
> > 5.2.1.2.  IPv6 addressing schema requirements from the ISP 
> perspective
> >           of the Service Provider
> > 
> >    From ISP perspective the following basic requirements could be
> >    identified:
> >    o  The IPv6 address allocation schema must be able to realize a
> >       maximal aggregation of all IPv6 address delegations 
> to customers
> >       into the /20 of the Service Provider.  Only this /20 will be
> >       routed and injected from the Service Provider into the global
> >       routing table (DFZ).  This strong aggregation keeps 
> the routing
> >       tables of the DFZ small and eases filtering and access control
> >       very much.  (Note: A strong aggregation e.g. on POP 
> or LER basis
> >       limits as well the numbers of customer routes that are visible
> >       within the ISP network.)
> 
> I'm quite concerned by this. Basically, why? Are we really expecting
> ISPs to have so many customer sites that they can't simply flat-route
> internally? Yes, that may be slightly less attractive for an MPLS
> based ISP rather than for one using IP routing, but it has horrible
> consequences because of the way it constrains address assignment.
 
The described example illustrates an addressing plan of an ISP who offers its service to several millions of customers. Thats why it is very needed to have some kind of aggregation level for the IPv6 aggregates of the customers - because of the number of routing table entries as well as (for an MPLS-based ISP) because of MPLS-Label space conservation.
Very small ISPs may perhaps implement a flat routing, but it is IMHO nevertheless recommended to think about an aggregation level since 150.000 routes are 150.000 routes and need a certain amount of (expensive) routing power to be handled.

Yes we've observed as well that every level of hierarchy will bring down the efficiency of the addressing schema. Thats why it is necessary for the ISP to find the right trade-off between address space conservation and routing table size. I.e. again 'No "One size fits all"'.
(IMHO in most cases one aggregation level should be enough.)

> > 5.2.1.3.  IPv6 addressing schema requirements from the 
> Network Access
> >           provider perspective of the Service Provider
> > 
> >    As already done for the LIR and the ISP roles of the SP 
> it is also
> >    necessary to identify requirements that come from its 
> Network Access
> >    Provider role.  Some of the basic requirements are:
> >    o  The IPv6 addressing schema of the SP must be flexible 
> enough to
> >       adapt changes that are injected from the customer side.  This
> >       covers changes that are based on the raising IPv6 
> address needs of
> >       the customer as well as changes that come from topological
> >       modifications (e.g. when the customer moves from one point of
> >       network attachment (POP) to another).
> 
> I don't understand "changes that are injected from the customer side."
> Does this mean injected by a routing protocol? What sort of 
> flexibility
> do you mean? And when a customer changes POP, well, see my previous
> comment. That should just be a routing change.

By "changes from customer side" we meant all impacts to the addressing and routing topology of the ISP that are triggered by the customer wishes. This covers for instance:
- Larger address aggregate needs (covered by the "growing zones" reserved for the customer aggregates)
- Changing the point of attachement of the customer to the provider network (that leads to more specific routes, if some kind of address aggregation schema has been implemented). 
Whereas the first point is a clear topic for the address allocation schema - the second one has most likely to be handled by the routing infrastructure. But by choosing a "clever" address aggregation schema - the number of additional routes can be limited in one or the other case.

> > 5.2.2.1.1.  'Big' customers
> 
> Really big customers with many sites and an internal network will
> be connected at multiple POPs. You don't discuss this case.
> Again, it breaks the idea that customer address space can be 
> aggregated
> by POP topology.
> 
>      Brian

Right. Routes of big customers will be propagated anyway inside the ISP network so that these customers can be attached to several POPs without problems. Thats why a special pool for such "extra-ordinary" customers has been foreseen. Again - its an example.

For the next version of this draft we plan a section about the basic "design rules" for an ISP IPv6 network that is followed by the ISP example in order to illustrate how these "thumb rules" have been exemplarilly implemented.

So far my 2 cents. Thanks for your feedback.
	Olaf