Re: Minutes of the IPv6 WG at RIPE 27 and 28
On Nov 30, 12:08am, Thomas Trede wrote:
Subject: Minutes of the IPv6 WG at RIPE 27 and 28
Hello,
the draft minutes for the IPv& WG at RIPE 27 and 28 have been circulated on the mailing list and are published at www.ripe.net. If someone has comments or changes, please give me a feedback. If there are no comments or request for changes up to the 10th of December 1997, the status will be advanced from "draft" to "final"
I was not at this RIPE meeting, but I have received the following message from Daniel Karrenberg and Robert Blokzijl (speaking in the name of RIPE and RIPE-NCC) as a response to an IESG last call. I would like to know if this subject was discussed or not at RIPE IPv6 WG and if this statement reflect the position of this WG, - Alain Durand. ^_^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ U (* *) Alain DURAND | Preserve keyboards: | ( v ) I.M.A.G. | use completion. | /~~~\ Direction des Moyens Informatiques |----------------------------- <|=< IP >= BP 53 38041 Grenoble Cedex 9 | E-Mail: Alain.Durand@imag.fr | \ v6/ France | Phone: +33 4 76 63 57 03 | <~~< Postmaster@imag.fr | Fax: +33 4 76 51 49 64 ~ ~ On Nov 26, 6:05pm, Daniel Karrenberg wrote:
Subject: (IPng 4984) Re: Last Call: IP Version 6 Addressing Architecture t To: iesg@ietf.org
Authors
Robert Blokzijl RIPE Chair
Daniel Karrenberg RIPE NCC General Manager
Background
RIPE is an organisation founded in 1989 wich aims to ensure the technical and administrative coordination necessary for the operation of the Internet in Europe [ripe-01].
The RIPE NCC performs activities for the benefit of the Internet service providers (ISPs) in Europe and the surrounding areas; primarily activities that the ISPs need to organise as a group, although they may be competing with each other in other areas. In particular the RIPE NCC, as Regional Internet Registry, allocates and assigns IPv4 address space in Europe and surrounding areas [ripe-162]. The RIPE NCC started operations in 1992. It currently allocates address space to more than 800 local Internet Registries almost all of which are operated by ISPs. The number of local IRs is expected to reach 1250 in 1998. There are currently no indications that the number of local IRs will stop growing.
The authors have contributed significantly to the development of the distributed Internet registry system which is used for the allocation and assignment of provider based IPv4 address space today. As such they have ample experience with the development of address space allocation and assignment policies. One important element of current policies is that the size of address space allocations is determined by previous justified use of address space. A prerequisite for this policy is that the size of allocations can start small and increase or decrease according to previous justified usage [ripe-159].
Argument
We believe <draft-ietf-ipngwg-unicast-aggr-02.txt> is critically flawed because it standardises address aggregation boundaries without any explicit technical justification. In particular the length of the TLA and NLA fields are proposed to be standardised as fixed at prarticular values with no technical justification for either the fact that these lengths need to be fixed nor for the particular values chosen. The lack of technical justification is significant because the standardisation of TLA and NLA lengths directly influences many elements of Internet operations including address space allocation policies. In particular the TLA being fixed at 13bit length makes only 8K TLAs available per FP. Consequently Internet Registries will not be able to use proven allocation policies but rather engage in regulatory practises. The rules proposed in <draft-ietf-ipngwg-tla-assignment-01.txt> are clear evidence of this. Broad acceptance of such rules and their implementation is extremely unlikely unless there is convincing technical reasoning behind the constraints that necessitate the rules.
Because of this critical flaw we request that the IESG not advance <draft-ietf-ipngwg-unicast-aggr-02.txt> and <draft-ietf-ipngwg-addr-arch-v2-05.txt> to proposed standard yet. We suggest that the IESG refer these documents back to the authors and the WG with the request to provide technical justification for the placement of aggregation boundaries and to consider making these boundaries variable where technically feasible.
References
The referenced RIPE documents can be accessed at
http://www.ripe.net/docs/ripe-xxx.html HTML ftp://ftp.ripe.net/ripe/docs/ripe-xxx.txt ASCII ftp://ftp.ripe.net/ripe/docs/ripe-xxx.ps PostScript
-------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -- End of excerpt from Daniel Karrenberg
Hello Alain, the subject of Daniel-and-Rob's eMail was NOT discussed at RIPE IPv6 WG. Since this subject was not discussed in the IPv6 WG, neither I can say that this is nor I can say that this is not the position of this WG. I propose to take this up at the next RIPE Meeting, I guess that Daniel and Rob will provide input/presentation ? Regards, Thomas On Mon, 1 Dec 1997, Alain Durand wrote:
On Nov 30, 12:08am, Thomas Trede wrote:
Subject: Minutes of the IPv6 WG at RIPE 27 and 28
Hello,
the draft minutes for the IPv& WG at RIPE 27 and 28 have been circulated on the mailing list and are published at www.ripe.net. If someone has comments or changes, please give me a feedback. If there are no comments or request for changes up to the 10th of December 1997, the status will be advanced from "draft" to "final"
I was not at this RIPE meeting, but I have received the following message from Daniel Karrenberg and Robert Blokzijl (speaking in the name of RIPE and RIPE-NCC) as a response to an IESG last call.
I would like to know if this subject was discussed or not at RIPE IPv6 WG and if this statement reflect the position of this WG,
- Alain Durand.
^_^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ U (* *) Alain DURAND | Preserve keyboards: | ( v ) I.M.A.G. | use completion. | /~~~\ Direction des Moyens Informatiques |----------------------------- <|=< IP >= BP 53 38041 Grenoble Cedex 9 | E-Mail: Alain.Durand@imag.fr | \ v6/ France | Phone: +33 4 76 63 57 03 | <~~< Postmaster@imag.fr | Fax: +33 4 76 51 49 64 ~ ~
On Nov 26, 6:05pm, Daniel Karrenberg wrote:
Subject: (IPng 4984) Re: Last Call: IP Version 6 Addressing Architecture t To: iesg@ietf.org
Authors
Robert Blokzijl RIPE Chair
Daniel Karrenberg RIPE NCC General Manager
Background
RIPE is an organisation founded in 1989 wich aims to ensure the technical and administrative coordination necessary for the operation of the Internet in Europe [ripe-01].
The RIPE NCC performs activities for the benefit of the Internet service providers (ISPs) in Europe and the surrounding areas; primarily activities that the ISPs need to organise as a group, although they may be competing with each other in other areas. In particular the RIPE NCC, as Regional Internet Registry, allocates and assigns IPv4 address space in Europe and surrounding areas [ripe-162]. The RIPE NCC started operations in 1992. It currently allocates address space to more than 800 local Internet Registries almost all of which are operated by ISPs. The number of local IRs is expected to reach 1250 in 1998. There are currently no indications that the number of local IRs will stop growing.
The authors have contributed significantly to the development of the distributed Internet registry system which is used for the allocation and assignment of provider based IPv4 address space today. As such they have ample experience with the development of address space allocation and assignment policies. One important element of current policies is that the size of address space allocations is determined by previous justified use of address space. A prerequisite for this policy is that the size of allocations can start small and increase or decrease according to previous justified usage [ripe-159].
Argument
We believe <draft-ietf-ipngwg-unicast-aggr-02.txt> is critically flawed because it standardises address aggregation boundaries without any explicit technical justification. In particular the length of the TLA and NLA fields are proposed to be standardised as fixed at prarticular values with no technical justification for either the fact that these lengths need to be fixed nor for the particular values chosen. The lack of technical justification is significant because the standardisation of TLA and NLA lengths directly influences many elements of Internet operations including address space allocation policies. In particular the TLA being fixed at 13bit length makes only 8K TLAs available per FP. Consequently Internet Registries will not be able to use proven allocation policies but rather engage in regulatory practises. The rules proposed in <draft-ietf-ipngwg-tla-assignment-01.txt> are clear evidence of this. Broad acceptance of such rules and their implementation is extremely unlikely unless there is convincing technical reasoning behind the constraints that necessitate the rules.
Because of this critical flaw we request that the IESG not advance <draft-ietf-ipngwg-unicast-aggr-02.txt> and <draft-ietf-ipngwg-addr-arch-v2-05.txt> to proposed standard yet. We suggest that the IESG refer these documents back to the authors and the WG with the request to provide technical justification for the placement of aggregation boundaries and to consider making these boundaries variable where technically feasible.
References
The referenced RIPE documents can be accessed at
http://www.ripe.net/docs/ripe-xxx.html HTML ftp://ftp.ripe.net/ripe/docs/ripe-xxx.txt ASCII ftp://ftp.ripe.net/ripe/docs/ripe-xxx.ps PostScript
-------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -- End of excerpt from Daniel Karrenberg
------------------------------------------------------------------- Thomas Trede Nacamar Data Communications Senior Network Engineer P.O.Box 102262 63268 Dreieich / Germany e-mail: trede@nacamar.net voice: +49-6103-993-910 www : www.nacamar.net fax : +49-6103-993-999 -------------------------------------------------------------------
Thomas Trede <tom@nacamar.de> writes: I propose to take this up at the next RIPE Meeting, I guess that Daniel and Rob will provide input/presentation ?
Both Rob and I certainly will do that. This subject has come up in the local discussion well after the RIPE meeting and is not exclusively an IPv6 issue. It is also a lir-wg issue. Daniel
Thomas Trede <tom@nacamar.de> writes: Hello Alain,
the subject of Daniel-and-Rob's eMail was NOT discussed at RIPE IPv6 WG. Since this subject was not discussed in the IPv6 WG, neither I can say that this is nor I can say that this is not the position of this WG. I propose to take this up at the next RIPE Meeting, I guess that Daniel and Rob will provide input/presentation ?
With hindsight I think we should take this up now rather than wait for the next meeting. The input and presentation is in the message itself really. Any discussion? Daniel
participants (3)
-
Alain Durand -
Daniel Karrenberg -
Thomas Trede