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 :).