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

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

Hi Brian

Tnx for your reply. Just a few remarks inline. 

> -----Original Message-----
> From: Brian E Carpenter [mailto:brc@zurich.ibm.com] 
> Sent: Wednesday, April 04, 2007 1:48 PM
> To: Bonneß, Olaf
> Cc: v6ops@ops.ietf.org
> Subject: Re: I-D ACTION:draft-ietf-v6ops-addcon-03.txt
> 
> On 2007-04-03 18:32, Bonness, Olaf wrote:
> > 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.)
> 
> OK, somehow the diff I ran didn't make me look at that.
> I agree it's better. I think it might be worth adding that since
> IPv6 space is not as precious as IPv4 space, the tradeoff may
> be different than it was for IPv4.

0 problemo.
I'll add than your remark that small ISPs could chose flat addressing architectures without internal levels of address aggregation to our next version of the addcon ID.

> 
> > 
> > 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 still think you need to be more clear what "injected" means 
> and what flexibility
> is needed. "Injected" to me means injected automatically by a 
> routing protocol,
> unless you say that it means a change in the customer's SLA, which I
> understand from your explanation. And I think "flexibility" 
> means updating
> some configuration files, not responding automatically to a routing
> update?
> 
> 
>        Brian
> 
> ...

O.k. I see your problem. I'll try to find a better formulation, since "inject" and "flexibility" are indeed a bit misleading:

	5.2.1.3
	...
	The IPv6 addressing schema of the SP must be chosen in a way that it 
      can handle new requirements that are triggered from customer side.
	This can be for instance the growing needs of the customers regarding 
	IPv6 addresses as well as customer driven modifications within the 
	access network topology (e.g. when the customer moves from one point 
	of network attachment (POP) to another). 
	(See also section 5.2.3.4 "Changing Point of Network Attachement")

Does this the trick? Perhaps it would be very helpful if you could propose a more "English" version of this idea since I'm not a native speaker :).
 
Tnx and regards
	Olaf