RE: I-D ACTION:draft-ietf-v6ops-addcon-03.txt

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

Hi Brian,

Thank you very much for your remarks. I'll target in my answer only to your remarks regarding chapter 5 issues and leave the answers for the other points to my editor colleagues. Besides that I'll attach (parts of) my email reply from 20th of July 2006 at the end of my email.

Section 5.2.1.2
Brian, if you compare the old section 5.2.1.2 from addcon_01 with the actualized section 5.2.1.2 from addcon_v03 than you can observe several changes, we've injected based on our email discussion. 
For instance we've added the note within the third bullet point of 5.2.1.2 where it is stated that each aggregation level brings down the efficiency of the addressing schema and that each ISP has to decide how many levels of aggregation it wants to implement. For a better understanding I can extend this to a statement where small ISPs may even implement a flat addressing architecture without any internal aggregation level.
(But from my point of view the vast majority of ISPs will have to have at least one level of address aggregation since it is no fun to have all the 100.000's / millions of customer routes inside your internal routing tables. So flat routing will IMHO be the exception and not the rule.)

Section 5.2.1.3
Regarding your comments to section 5.2.1.3 we've modified the wording of (the first bullet point of) this section and restructured chapter 5 of the ID by explicitely discussing "Changing Point of Network Attachement" in section 5.2.3.4. Perhaps a pointer to this section in 5.2.1.3 would be helpful and I'll insert it.

I hope that this will help to eliminate the obscurenesses you mentioned and will make the ID more readable.
Thanks again for your suggestions and best regards
	Olaf


====> Olaf Bonness wrote on 2006-07-20 <============================================
....
> 5.2.1.2.
> 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
> 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.

.....
=================================> End <============================================

-----Original Message-----
From: Brian E Carpenter [mailto:brc@zurich.ibm.com] 
Sent: Tuesday, April 03, 2007 4:10 PM
To: IPv6 Operations
Subject: Re: I-D ACTION:draft-ietf-v6ops-addcon-03.txt

Some of my earlier comments haven't resulted in any text changes.
I'm not completely at ease about these points.

On 2006-06-13 09:25, Brian E Carpenter wrote:
...
>> 2.2.  Unique Local IPv6 Addresses
> ...
>>    Because a ULA and a global site prefix are both /48 length, an
>>    administrator can choose to use the same subnetting (and host
>>    addressing) plan for both prefixes.
> 
> The RIRs are moving away from a rigid /48 policy. It would be safer
> to start this sentence with "When" instead of "Because".
> And on the same topic...
> 
>> 2.4.  Network Level Design Considerations
> 
> I suggest adding a bullet at the end of this section along these
> lines:
> 
> o It is possible that as registry policies evolve, a small site
>   may experience an increase in prefix length when renumbering,
>   e.g. from /48 to /56. For this reason, the best practice is
>   number subnets compactly rather than sparsely, and to
>   use low-order bits as much as possible when numbering subnets.
>   In other words, even if a /48 is allocated, act as though
>   only a /56 is available. Clearly, this advice does not apply
>   to large sites and enterprises that have an intrinsic need
>   for a /48 prefix.

On 2006-07-19 17:37, Brian E Carpenter wrote:
...
>> 2.4.2.  Address Space Conservation
>>
>>    Despite the large IPv6 address space which enables easier subnetting,
>>    it still is important to ensure an efficient use of this resource.
>>    Some addressing schemes, while facilitating aggregation and
>>    management, could lead to significant numbers of addresses being
>>    unused.  Address conservation requirements are less stringent in IPv6
>>    but they should still be observed.
>>
>>    The proposed HD [8] value for IPv6 is 0.94 compared to the current
>>    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)
> 
> 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.
> 
>> 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.

There was a little discussion following my comments, and I hoped for
a few clarifying sentences in the document.

     Brian