[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



below...

On 2007-04-05 10:09, Bonness, Olaf wrote:
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 :).

That's fine. I'm sure the RFC Editor will fix any little syntax
details. Thanks!

    Brian