Orbit

SIG-policy

20 Jul 2012 2:08 a.m.

>Message: 7

>Date: Fri, 20 Jul 2012 10:51:31 +1200

>From: Dean Pemberton <dean@deanpemberton.com>

>Subject: Re: [sig-policy] Proposal 99

>To: Xing Li xing@cernet.edu.cn

>Cc: "sig-policy@apnic.net SIG List" <sig-policy@apnic.net>

>Message-ID:

> <CACfPNNSQ-8oS3K0GmdR3EDLYrF18Cf=9LThcsvJCTLvUvUqPkg@mail.gmail.com>

>Content-Type: text/plain; charset=UTF-8

>Thank you for that reference.

>The example in your slides shows a situation where a /27 is required

>over a multi year period but that under the current system this is

>allocated as two /29s and a /28. Your presentation claims that this

>causes problems with non-optimal network design.

I am also interested to know why this example cannot be resolved

by APNIC's current sparse allocation policy.

Regards,

Ren-Hung

>I am interested to hear from Sanjaya or the hostmasters if this would

>actually be a problem in reality.

>If I were a member who came to APNIC with comprehensive documentation

>showing a network rollout over 5 years which needed a /27, would this

>be allocated under provisions in the following section of

>apnic-089-v010

>------

>5.2.3 Larger initial allocations

>Initial allocations larger than /32 may be justified if:

>a) The organization provides comprehensive documentation of planned

>IPv6 infrastructure which would require a larger allocation;

>------

>In other words, if I can show that I have a need for larger network,

>can this be currently addressed without the need to change policy.

>Regards,

>Dean

--
Ren-Hung Hwang
Research Distinguished Professor
Dept. of Computer Science & Information Engineering
National Chung Cheng Univ.
Chia-Yi, Taiwan, 621
http://exodus.cs.ccu.edu.tw/~rhhwang
WebOffice: http://mmc.elearning.ccu.edu.tw/home/rhhwang

9 10

Replies

Terence Zhang YH

20 Jul 8:23 a.m.

I cannot speak for the authors, but what I understand is:

Sparse allocation tries to make sure an organization get contiguous IPv6 space,

but prop-099 tries to make sure each PoP within an organization also get contiguous IPv6 space.

For example, under the current situation, when an organization gets an /32, and

there are 4 PoPs in this organization, he will sub-allocate /34 to each PoP,

next time this organization get another /32, and also sub-allocate /34 to

each PoP, although the 2*/32 can be aggregated as /31, each PoP's 2*/34

can't be aggregated since they are from different /32.

In the above example, sparse allocation tries to ensure the 2*/32 are contiguous,

but prop-099 tries to ensure the 2*/34 are contiguous.

Regards

Terence Zhang

CNNIC

----- Original Message -----

From: Ren-Hung Hwang

To: SIG policy

Sent: Friday, July 20, 2012 10:08 AM

Subject: Re: [sig-policy] Proposal 99

>Message: 7

>Date: Fri, 20 Jul 2012 10:51:31 +1200

>From: Dean Pemberton <dean@deanpemberton.com>

>Subject: Re: [sig-policy] Proposal 99

>To: Xing Li xing@cernet.edu.cn

>Cc: "sig-policy@apnic.net SIG List" <sig-policy@apnic.net>

>Message-ID:

> <CACfPNNSQ-8oS3K0GmdR3EDLYrF18Cf=9LThcsvJCTLvUvUqPkg@mail.gmail.com>

>Content-Type: text/plain; charset=UTF-8

>

>Thank you for that reference.

>

>The example in your slides shows a situation where a /27 is required

>over a multi year period but that under the current system this is

>allocated as two /29s and a /28. Your presentation claims that this

>causes problems with non-optimal network design.

I am also interested to know why this example cannot be resolved

by APNIC's current sparse allocation policy.

Regards,

Ren-Hung

>

>I am interested to hear from Sanjaya or the hostmasters if this would

>actually be a problem in reality.

>

>If I were a member who came to APNIC with comprehensive documentation

>showing a network rollout over 5 years which needed a /27, would this

>be allocated under provisions in the following section of

>apnic-089-v010

>

>------

>5.2.3 Larger initial allocations

>Initial allocations larger than /32 may be justified if:

>

>a) The organization provides comprehensive documentation of planned

>IPv6 infrastructure which would require a larger allocation;

>------

>

>In other words, if I can show that I have a need for larger network,

>can this be currently addressed without the need to change policy.

>

>Regards,

>Dean

--
Ren-Hung Hwang
Research Distinguished Professor
Dept. of Computer Science & Information Engineering
National Chung Cheng Univ.
Chia-Yi, Taiwan, 621
http://exodus.cs.ccu.edu.tw/~rhhwang
WebOffice: http://mmc.elearning.ccu.edu.tw/home/rhhwang

* sig-policy: APNIC SIG on resource management policy *
_______________________________________________
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Aftab Siddiqui

20 Jul 10:22 a.m.

Hi Terence,

In the above example, sparse allocation tries to ensure the 2*/32 are contiguous,

but prop-099 tries to ensure the 2*/34 are contiguous.

I believe thats not the case because lets say if initially they got 2001:db8::/32 and they allocated /34 each for 4 pops

e.g.

2001:db8::/34
2001:db8:4000::/34
2001:db8:8000::/34
2001:db8:c000::/34

right?

Now for the subsequent allocation the prefix they will get can't make 2*/34 contiguous. So any POP is growing than they either have to renumber or use 2 discontiguous /34. Correct me if I misinterpret.

Nevertheless, I don't support this proposal. And for the corner cases Sanjaya's suggestion is fine.

Regards,

Aftab A. Siddiqui

Terence Zhang YH

20 Jul 10:50 a.m.

Hi,Aftab,

If I understand correctly , the example you gave is absolutely right,

and that's the issue prop-099 tries to address.

That's what prop-099's multiple prefixes allocation is about,

In this case, prop-099 suggest allocate 4*/34 to the organization

instead of a single /32, and next time also allocate 4*/34,

then each PoP's /34s can be aggregated, and after a peirod of time,

the organization will get 1 single /30 and each PoP get 1 single /32.

(the above is for example only, what prop-099 talks about is

very large ISP, so there will be many large PoPs, and each time

the allocation to each PoP will be larger than /32)

Best regards

Terence

CNNIC

----- Original Message -----

From: Aftab Siddiqui

To: Terence Zhang YH

Cc: Ren-Hung Hwang ; SIG policy

Sent: Friday, July 20, 2012 6:22 PM

Subject: Re: [sig-policy] Proposal 99

Hi Terence,

In the above example, sparse allocation tries to ensure the 2*/32 are contiguous,

but prop-099 tries to ensure the 2*/34 are contiguous.

I believe thats not the case because lets say if initially they got 2001:db8::/32 and they allocated /34 each for 4 pops

e.g.

2001:db8::/34
2001:db8:4000::/34
2001:db8:8000::/34
2001:db8:c000::/34

right?

Now for the subsequent allocation the prefix they will get can't make 2*/34 contiguous. So any POP is growing than they either have to renumber or use 2 discontiguous /34. Correct me if I misinterpret.

Nevertheless, I don't support this proposal. And for the corner cases Sanjaya's suggestion is fine.

Regards,

Aftab A. Siddiqui

Naresh Ajwani

21 Jul 4:37 a.m.

And for the corner cases Sanjaya's suggestion is fine.

Sorry Aftab, I have missed out this suggestion, wud u mind sharing the same please?

Regards & best wishes,

Naresh Ajwani

On 20-Jul-2012, at 3:52 PM, Aftab Siddiqui <aftab.siddiqui@gmail.com> wrote:

Hi Terence,

In the above example, sparse allocation tries to ensure the 2*/32 are contiguous,

but prop-099 tries to ensure the 2*/34 are contiguous.

I believe thats not the case because lets say if initially they got 2001:db8::/32 and they allocated /34 each for 4 pops
e.g.
2001:db8::/34
2001:db8:4000::/34
2001:db8:8000::/34
2001:db8:c000::/34

right?

Now for the subsequent allocation the prefix they will get can't make 2*/34 contiguous. So any POP is growing than they either have to renumber or use 2 discontiguous /34. Correct me if I misinterpret.

Nevertheless, I don't support this proposal. And for the corner cases Sanjaya's suggestion is fine.

Regards,

Aftab A. Siddiqui

* sig-policy: APNIC SIG on resource management policy *
_______________________________________________
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Sanjaya

23 Jul 7:25 a.m.

Hi Naresh & all,

My suggestion is to allow APNIC hostmasters delegate multiple prefixes (disaggregated ranges) to very large networks based on the following statement in section 5.3.3 Subsequent Allocation Size:

"Where possible, except where separate disaggregated ranges are requested for multiple discreet networks, the allocation will be made from an adjacent address block, meaning that its existing allocation is extended by one bit to the left."

Of course, the APNIC hostmasters will evaluate the requests carefully and consider global routing table size impact before making any such delegation.

If this suggestion is accepted then the problem stated in prop-099 could be solved, without any policy change.

Cheers, Sanjaya

On 21/07/2012 2:37 PM, Naresh Ajwani wrote:

...

...
And for the corner cases Sanjaya's suggestion is fine.

...

Sorry Aftab, I have missed out this suggestion, wud u mind sharing the same please?

Regards & best wishes,

Naresh Ajwani

ajwaninaresh＠gmail.com

23 Jul 8:21 a.m.

Speaking for myself, I appreciate and agree to your suggestion.

Regards

Naresh Sent from my BlackBerry® smartphone from Tata Indicom

-----Original Message----- From: Sanjaya sanjaya@apnic.net Sender: sig-policy-bounces@lists.apnic.net Date: Mon, 23 Jul 2012 17:25:26 To: SIG policysig-policy@apnic.net Subject: Re: [sig-policy] Proposal 99

Hi Naresh & all,

My suggestion is to allow APNIC hostmasters delegate multiple prefixes (disaggregated ranges) to very large networks based on the following statement in section 5.3.3 Subsequent Allocation Size:

Of course, the APNIC hostmasters will evaluate the requests carefully and consider global routing table size impact before making any such delegation.

If this suggestion is accepted then the problem stated in prop-099 could be solved, without any policy change.

Cheers, Sanjaya

On 21/07/2012 2:37 PM, Naresh Ajwani wrote:

...

...
And for the corner cases Sanjaya's suggestion is fine.

...

Sorry Aftab, I have missed out this suggestion, wud u mind sharing the same please?

Regards & best wishes,

Naresh Ajwani

* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy

Aftab Siddiqui

23 Jul 8:31 a.m.

Hi,

[Looking for prop-099 authors]

Hi Naresh & all,

My suggestion is to allow APNIC hostmasters delegate multiple prefixes
(disaggregated ranges) to very large networks based on the following
statement in section 5.3.3 Subsequent Allocation Size:

"Where possible, except where separate disaggregated ranges are
requested for multiple discreet networks, the allocation will be made
from an adjacent address block, meaning that its existing allocation is
extended by one bit to the left."

Of course, the APNIC hostmasters will evaluate the requests carefully
and consider global routing table size impact before making any such
delegation.

I agree to this but would like to see the comments from the authors.

Regards,

Aftab A. Siddiqui

Xing Li

24 Jul 9:19 a.m.

Sanjaya ??:

...

Hi Naresh & all,

My suggestion is to allow APNIC hostmasters delegate multiple prefixes (disaggregated ranges) to very large networks based on the following statement in section 5.3.3 Subsequent Allocation Size:

"Where possible, except where separate disaggregated ranges are requested for multiple discreet networks, the allocation will be made from an adjacent address block, meaning that its existing allocation is extended by one bit to the left."

Of course, the APNIC hostmasters will evaluate the requests carefully and consider global routing table size impact before making any such delegation.

If this suggestion is accepted then the problem stated in prop-099 could be solved, without any policy change.

This is exactly the proposal 99 trying to achieve. xing

...

Cheers, Sanjaya

On 21/07/2012 2:37 PM, Naresh Ajwani wrote:

...
...
And for the corner cases Sanjaya's suggestion is fine.

...
Sorry Aftab, I have missed out this suggestion, wud u mind sharing the same please?

Regards & best wishes,

Naresh Ajwani
         sig-policy:  APNIC SIG on resource management policy           *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy

Dean Pemberton

24 Jul 9:49 a.m.

So it sounds like Sanjaya is saying that your objectives are possible within the current policies and that no additional policy is required to achieve these goals.

In light if that is prop-99 still necessary?

Regards

Dean

On Tuesday, July 24, 2012, Xing Li wrote:

This is exactly the proposal 99 trying to achieve. xing

--
Regards,

Dean

Chu, Yi [NTK]

20 Jul 11:55 a.m.

So under current policy, would it be OK for the ISP to put in multiple requests, one per PoP? Of course, all the allocations for the PoP's are not guaranteed to be summerizatble into one superblock. However, APNIC staff can also take summerization into consideration. Wouldn't that be an administrative function?

Yi Chu Sprint ________________________________________ From: sig-policy-bounces@lists.apnic.net [sig-policy-bounces@lists.apnic.net] on behalf of Terence Zhang YH [zhangyinghao@cnnic.cn] Sent: Friday, July 20, 2012 3:23 AM To: Ren-Hung Hwang; SIG policy Subject: Re: [sig-policy] Proposal 99

I cannot speak for the authors, but what I understand is:

Sparse allocation tries to make sure an organization get contiguous IPv6 space, but prop-099 tries to make sure each PoP within an organization also get contiguous IPv6 space.

For example, under the current situation, when an organization gets an /32, and there are 4 PoPs in this organization, he will sub-allocate /34 to each PoP, next time this organization get another /32, and also sub-allocate /34 to each PoP, although the 2*/32 can be aggregated as /31, each PoP's 2*/34 can't be aggregated since they are from different /32.

In the above example, sparse allocation tries to ensure the 2*/32 are contiguous, but prop-099 tries to ensure the 2*/34 are contiguous.

Regards Terence Zhang CNNIC

----- Original Message ----- From: Ren-Hung Hwangmailto:rhhwang@gmail.com To: SIG policymailto:sig-policy@apnic.net Sent: Friday, July 20, 2012 10:08 AM Subject: Re: [sig-policy] Proposal 99

...

Message: 7 Date: Fri, 20 Jul 2012 10:51:31 +1200 From: Dean Pemberton <dean@deanpemberton.commailto:dean@deanpemberton.com> Subject: Re: [sig-policy] Proposal 99 To: Xing Li xing@cernet.edu.cnmailto:xing@cernet.edu.cn Cc: "sig-policy@apnic.netmailto:sig-policy@apnic.net SIG List" <sig-policy@apnic.netmailto:sig-policy@apnic.net> Message-ID: <CACfPNNSQ-8oS3K0GmdR3EDLYrF18Cf=9LThcsvJCTLvUvUqPkg@mail.gmail.commailto:CACfPNNSQ-8oS3K0GmdR3EDLYrF18Cf=9LThcsvJCTLvUvUqPkg@mail.gmail.com> Content-Type: text/plain; charset=UTF-8

Thank you for that reference.

The example in your slides shows a situation where a /27 is required over a multi year period but that under the current system this is allocated as two /29s and a /28. Your presentation claims that this causes problems with non-optimal network design.

I am also interested to know why this example cannot be resolved by APNIC's current sparse allocation policy. Regards, Ren-Hung

...

I am interested to hear from Sanjaya or the hostmasters if this would actually be a problem in reality.

If I were a member who came to APNIC with comprehensive documentation showing a network rollout over 5 years which needed a /27, would this be allocated under provisions in the following section of apnic-089-v010

5.2.3 Larger initial allocations Initial allocations larger than /32 may be justified if:

a) The organization provides comprehensive documentation of planned IPv6 infrastructure which would require a larger allocation;

In other words, if I can show that I have a need for larger network, can this be currently addressed without the need to change policy.

Regards, Dean

-- Ren-Hung Hwang Research Distinguished Professor Dept. of Computer Science & Information Engineering National Chung Cheng Univ. Chia-Yi, Taiwan, 621 http://exodus.cs.ccu.edu.tw/~rhhwang WebOffice: http://mmc.elearning.ccu.edu.tw/home/rhhwang

________________________________

This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

Download
Add to favorites Remove from favorites

Activity Summary

4149 days inactive
4149 days old
sig-policy@lists.apnic.net
9 participants
10 comments