"Requirements For IPv6 in ICT Equipment" comment
Regarding: http://www.ripe.net/ripe/docs/ripe-501.html I find no mention of flow instrumentation in the November 2010 document. I suggest that "router and layer 3 switch" Mandatory support should include maintenance and export of flow records , ideally compliant with rfc 3917, with sampling rate capability of at least 1 per 1000 packets, at the maximum packet rate of the device. Regards Steve Nash ________________________ Steve Nash CEng MIET Consulting Engineer Arbor Networks office +44 118 967 4917 mobile +44 772 029 1359 www.arbornetworks.com<http://www.arbornetworks.com/> How networks grow(tm) ________________________
Steve, Do not you think that this is going too far? Especially if everyone is adding his/her own requirements... For example, I cannot imagine a residential CPE having any kind of flow export ;-) I would prefer to have RIPE-501 focus on the bare minimum requirements in order to get IPv6 deployed as soon as possible: this means enough requirements to be deployed in a secure, interoperable and manageable way but no more as we (at least I) prefer to have multiple 'compliant' devices. Hope this helps and does not sound to vendor originated (see my affiliation) -éric From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of Nash, Steve Sent: mercredi 5 janvier 2011 10:40 To: ipv6-wg@ripe.net Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment Regarding: http://www.ripe.net/ripe/docs/ripe-501.html I find no mention of flow instrumentation in the November 2010 document. I suggest that "router and layer 3 switch" Mandatory support should include maintenance and export of flow records , ideally compliant with rfc 3917, with sampling rate capability of at least 1 per 1000 packets, at the maximum packet rate of the device. Regards Steve Nash ________________________ Steve Nash CEng MIET Consulting Engineer Arbor Networks office +44 118 967 4917 mobile +44 772 029 1359 www.arbornetworks.com <http://www.arbornetworks.com/> How networks grow(tm) ________________________
On 5.1.11 12:38, Eric Vyncke (evyncke) wrote:
Steve,
Do not you think that this is going too far? Especially if everyone is adding his/her own requirements...
For example, I cannot imagine a residential CPE having any kind of flow export ;-)
I would prefer to have RIPE-501 focus on the bare minimum requirements in order to get IPv6 deployed as soon as possible: this means enough requirements to be deployed in a secure, interoperable and manageable way but no more as we (at least I) prefer to have multiple ‘compliant’ devices.
Eric, hi. Yes, as primary author of RIPE-501 I completely agree with this statement. I was searching for words saying exactly same thing, well put :) On the other hand my thinking goes into direction, that what you say needs to be done in "mandatory" sections of different equipment specs. I see "mandatory" sections as prerequisite for IPv6 to be "deployed in a secure, interoperable and manageable way but no more". Optional requirements is a candy for those vendors, who did their homework or at least biggest part of it. If tender iniciator says "mandatory is non-debatable, but you get more points for optional requirements and vendor with more optional requirements wins and gets the business", this might be a good reason why to implement as much IPv6 in equipment as it can be done. I see this as encouragement to develop and push IPv6 deployment on the next qualitative level.
Hope this helps and does not sound to vendor originated (see my affiliation)
Eric, we know who you are ;) ;) Cheers, Jan
On 5 Jan 2011, at 12:18, Jan Zorz @ go6.si wrote:
Yes, as primary author of RIPE-501 I completely agree with this statement. I was searching for words saying exactly same thing, well put :)
On the other hand my thinking goes into direction, that what you say needs to be done in "mandatory" sections of different equipment specs. I see "mandatory" sections as prerequisite for IPv6 to be "deployed in a secure, interoperable and manageable way but no more".
Optional requirements is a candy for those vendors, who did their homework or at least biggest part of it. If tender iniciator says "mandatory is non-debatable, but you get more points for optional requirements and vendor with more optional requirements wins and gets the business", this might be a good reason why to implement as much IPv6 in equipment as it can be done. I see this as encouragement to develop and push IPv6 deployment on the next qualitative level.
Well, as the document appears (to me) to be guidance for tender documents for large enterprises, then requesting flow exports for router/layer 3 equipment is reasonable. Were it a set of requirements for SOHO CPE, then it wouldn't be. A certain platform we have now in a campus setting does IPv6 flow exports, but only over IPv4 transport. By having a good set of recommendations for tenders we can hope that vendors improve that support, and adjust their roadmaps accordingly. Tim
<>start snip<> A certain platform we have now in a campus setting does IPv6 flow exports, but only over IPv4 transport. By having a good set of recommendations for tenders we can hope that vendors improve that support, and adjust their roadmaps accordingly. <>end snip<> And as result drop those other features you desire to have? Resources are limited, even for a technology as IPv6. I can only applaud the work that Jan and team has done with RIPE-501. It is a good initiative and will help people get the best bang for their bucks within Europe. (and yes... it makes live a vendor slightly harder and in some way easier as it helps us prioritize. The recommendations in there are already quite in sync with other certifications for targeted 'very very' big vendor customers of vendors, so it is no surprise). What we (me and Cisco) have been seeing is users confused and ask for everything of RIPE-501, and that is an important reality check. What I would like to see in addition to the current RIPE-501, and I have been discussing this thought process with Jan already 1-2-1 is to make the document slightly larger, and add focus for common user scenario's... like NREN, University, small enterprise, medium enterprise and big enterprise, and then also for ISP tier-1 -2 -3 ... I am not sure he is convinced, however I hope he is :-) and yes, just as Eric mentioned suggested I am taking my affiliation into account and at the same time try to work with the pragmatism of reality. G/ -----Original Message----- From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of Tim Chown Sent: woensdag 5 januari 2011 14:51 To: ipv6-wg@ripe.net Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment On 5 Jan 2011, at 12:18, Jan Zorz @ go6.si wrote:
Yes, as primary author of RIPE-501 I completely agree with this
statement. I was searching for words saying exactly same thing, well put :)
On the other hand my thinking goes into direction, that what you say
needs to be done in "mandatory" sections of different equipment specs. I see "mandatory" sections as prerequisite for IPv6 to be "deployed in a secure, interoperable and manageable way but no more".
Optional requirements is a candy for those vendors, who did their
homework or at least biggest part of it. If tender iniciator says "mandatory is non-debatable, but you get more points for optional requirements and vendor with more optional requirements wins and gets the business", this might be a good reason why to implement as much IPv6 in equipment as it can be done. I see this as encouragement to develop and push IPv6 deployment on the next qualitative level. Well, as the document appears (to me) to be guidance for tender documents for large enterprises, then requesting flow exports for router/layer 3 equipment is reasonable. Were it a set of requirements for SOHO CPE, then it wouldn't be. A certain platform we have now in a campus setting does IPv6 flow exports, but only over IPv4 transport. By having a good set of recommendations for tenders we can hope that vendors improve that support, and adjust their roadmaps accordingly. Tim
On 5.1.11 15:38, Gunter Van de Velde (gvandeve) wrote:
I can only applaud the work that Jan and team has done with RIPE-501. It is a good initiative and will help people get the best bang for their bucks within Europe. (and yes... it makes live a vendor slightly harder and in some way easier as it helps us prioritize.
Thnx :)
The recommendations in there are already quite in sync with other certifications for targeted 'very very' big vendor customers of vendors, so it is no surprise). What we (me and Cisco) have been seeing is users confused and ask for everything of RIPE-501, and that is an important reality check.
True. We need to fix that.
What I would like to see in addition to the current RIPE-501, and I have been discussing this thought process with Jan already 1-2-1 is to make the document slightly larger, and add focus for common user scenario's... like NREN, University, small enterprise, medium enterprise and big enterprise, and then also for ISP tier-1 -2 -3 ... I am not sure he is convinced, however I hope he is :-)
This is getting complex. I am convinced we need to do that, but not sure how to do that in order not to confuse readers even harder. What is crossing my mind in this moment is online web application, where you start with selecting "I would like to choose my role (NREN, Eneterprise, ISP, ...)" or "I would like to specify by equipment type". If you choose "Role", then your progress goes on a different way, but if you choose "Equipment", then series of questions gets asked, like Sander mentioned me in one offlist email: Step 1: Do you need (a) IPv4 support (b) IPv6 support (c) Both Step 2: Do you need network management? (a) Yes (b) No Step 2a: Do you need to do flow exporting? (a) Yes (b) No Step 2b: Do you need to transport the flow exports over IPv6? (a) Yes (b) No etc... At the end you get the list of requirements you should ask for. Would this ease the selection process? If we need selection process that complex, than paper is not the right media, but online app would be nice choice. Any ideas? Cheers, Jan Zorz
On 5 Jan 2011, at 14:52, Jan Zorz @ go6.si wrote:
On 5.1.11 15:38, Gunter Van de Velde (gvandeve) wrote:
I can only applaud the work that Jan and team has done with RIPE-501. It is a good initiative and will help people get the best bang for their bucks within Europe. (and yes... it makes live a vendor slightly harder and in some way easier as it helps us prioritize.
Thnx :)
Absolutely, it's a really useful text. One of the IPv6 issues that has come up in the JANET community is how to obtain good independent advice on IPv6 requirements to include in procurements. Those requirements are much broader than for other 'new' technologies, and both include 'like for like' features for IPv4/IPv6 and new IPv6-specific features.
The recommendations in there are already quite in sync with other certifications for targeted 'very very' big vendor customers of vendors, so it is no surprise). What we (me and Cisco) have been seeing is users confused and ask for everything of RIPE-501, and that is an important reality check.
True. We need to fix that.
Fair point - RIPE-501 has some excellent suggestions, pointers and info in it, and not everyone will want everything. Though the primary audience is government and large enterprises. Vendors can still continue to prioritise feature releases based on the NIST and IPv6 Ready initiatives.
What I would like to see in addition to the current RIPE-501, and I have been discussing this thought process with Jan already 1-2-1 is to make the document slightly larger, and add focus for common user scenario's... like NREN, University, small enterprise, medium enterprise and big enterprise, and then also for ISP tier-1 -2 -3 ... I am not sure he is convinced, however I hope he is :-)
This is getting complex. I am convinced we need to do that, but not sure how to do that in order not to confuse readers even harder.
Well, the flow export feature is just one that is likely to be desirable in large enterprise networks, and is certainly an issue I and others have raised when talking to vendor(s). Of course it's just one feature, and not a make or break one :)
What is crossing my mind in this moment is online web application, where you start with selecting "I would like to choose my role (NREN, Eneterprise, ISP, ...)" or "I would like to specify by equipment type".
...
Would this ease the selection process? If we need selection process that complex, than paper is not the right media, but online app would be nice choice.
I think this would be a significant amount of work. I suspect the better approach is for some volunteers in appropriate communities to take RIPE-501, advertise it to those communities, and provide some suggestions as to which requirements are priorities for that community, e.g. for campus enterprise networks. There will, following the Option 1 model, be some (though not many) mandatory and optional features that have different priorities in that environment, or a small number of features that are missing and can be added. RIPE-501 provides a very nice foundation for such guidance. Whether vendors like what is in that guidance shouldn't really be a concern :) Tim
Eric I agree with you that it would be excessive to make flow records mandatory on Residential CPE. However the Introduction says that the document is BCP for "governments and large enterprises" so I had considered residential CPE out-of-scope. To achieve the objectives you state of "secure,..and manageable..." I would say that instrumentation is essential. It is possible to identify devices more specifically. Mandatory should apply to: 1/ layer3 devices that are to be AS border routers 2/ layer3 CPE WAN-edge devices where the site offers service to off-site clients (and is therefore vulnerable to denial of service attacks) Most large enterprises today use flow instrumentation in IPv4, so overlooking it for v6 might be a mistake. If an organisation is convinced that it will not make use of flow data, then it can choose to ignore this recommendation, like any other in the document. I had not viewed this requirement as restrictive to vendor selection, as all the major vendors support flow (especially Cisco). But the requirement will help buyers to size equipment appropriately and avoid purchasing something in the short-term that is inadequate for the life of the device. Regards Steve From: Eric Vyncke (evyncke) [mailto:evyncke@cisco.com] Sent: 05 January 2011 11:38 To: Nash, Steve; ipv6-wg@ripe.net Subject: RE: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment Steve, Do not you think that this is going too far? Especially if everyone is adding his/her own requirements... For example, I cannot imagine a residential CPE having any kind of flow export ;-) I would prefer to have RIPE-501 focus on the bare minimum requirements in order to get IPv6 deployed as soon as possible: this means enough requirements to be deployed in a secure, interoperable and manageable way but no more as we (at least I) prefer to have multiple 'compliant' devices. Hope this helps and does not sound to vendor originated (see my affiliation) -éric From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of Nash, Steve Sent: mercredi 5 janvier 2011 10:40 To: ipv6-wg@ripe.net Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment Regarding: http://www.ripe.net/ripe/docs/ripe-501.html I find no mention of flow instrumentation in the November 2010 document. I suggest that "router and layer 3 switch" Mandatory support should include maintenance and export of flow records , ideally compliant with rfc 3917, with sampling rate capability of at least 1 per 1000 packets, at the maximum packet rate of the device. Regards Steve Nash ________________________ Steve Nash CEng MIET Consulting Engineer Arbor Networks office +44 118 967 4917 mobile +44 772 029 1359 www.arbornetworks.com<http://www.arbornetworks.com/> How networks grow(tm) ________________________
On 7.1.11 9:52, Nash, Steve wrote:
Eric
I agree with you that it would be excessive to make flow records mandatory on Residential CPE.
However the Introduction says that the document is BCP for “governments and large enterprises” so I had considered residential CPE out-of-scope.
To achieve the objectives you state of “secure,..and manageable...” I would say that instrumentation is essential.
It is possible to identify devices more specifically.
Hi, I'm thinking about using If statement here under Mandatory sections (where needed): "If maintenance and export of flow records is needed, then Netflow 9 [RFC3917], must be supported with sampling rate capability of at least 1 per 1000 packets, at the maximum packet rate of the device." Does this makes sense? Cheers, Jan Zorz
Greetings to all and happy new year. We also used this document to extract basic features (in our environment) for customer CPEs. In my opinion, the "document" format must be preserved as a single place to contain the entire information. I guess 'if' statements like Jan mentions is one way to achieve the desired outcome. Regards, Kostas Zorbadelos
Good point, and having a Consumer CPE spec as a RIPE standard would help for last mile access requirements. RIPE-501 only aimed for government and enterprise deployments. Access is where IPv4 is being depleted rapidly, thus mentioning how IPv6 can coexist with limited IPv4 addresses, with the objective of conserving consumer CPE cost by keeping IPv6 features on CPEs to the minimum, is needed. Two approaches should be covered in access: Tunneling for dual-stack access (such as TSP and 6RD for v6-in-v4, plus DS-Lite and DSTM for v4-in-v6), as well as Translation for single stack IPv6-only hosts using protocols such as NAT64/DNS64. Each protocol's suitability for rapid transition, as well as its edge network requirements, should be mentioned. Note that I am affiliated with an access vendor, gogo6 / Hexago, which runs the global Freenet6 network using tunneling CPEs and soft clients. Regards, -Ahmed From: kzorba@otenet.gr Sent: Saturday, January 08, 2011 1:11 PM To: ipv6-wg@ripe.net Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment Greetings to all and happy new year. We also used this document to extract basic features (in our environment) for customer CPEs. In my opinion, the "document" format must be preserved as a single place to contain the entire information. I guess 'if' statements like Jan mentions is one way to achieve the desired outcome. Regards, Kostas Zorbadelos
On 9 jan 2011, at 05:40, Ahmed Abu-Abed wrote:
Good point, and having a Consumer CPE spec as a RIPE standard would help for last mile access requirements. RIPE-501 only aimed for government and enterprise deployments.
My personal preference would be to keep pointing to the work done in the IETF. The problem with standards is, there usually are too many. Adding another one will only lead to more confusion, let alone the time it will take to get consensus. Grtx, MarcoH -- "Good tests kill flawed theories; we remain alive to guess again"
My suggestion was to develop a best practice for consumer CPE specifications based on existing IETF standards/drafts. Regards, -Ahmed From: Marco Hogewoning Sent: Sunday, January 09, 2011 1:22 PM To: Ahmed Abu-Abed Cc: kzorba@otenet.gr ; ipv6-wg@ripe.net Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment On 9 jan 2011, at 05:40, Ahmed Abu-Abed wrote:
Good point, and having a Consumer CPE spec as a RIPE standard would help for last mile access requirements. RIPE-501 only aimed for government and enterprise deployments.
My personal preference would be to keep pointing to the work done in the IETF. The problem with standards is, there usually are too many. Adding another one will only lead to more confusion, let alone the time it will take to get consensus. Grtx, MarcoH -- "Good tests kill flawed theories; we remain alive to guess again"
----- Original message -----
My suggestion was to develop a best practice for consumer CPE specifications based on existing IETF standards/drafts.
Regards, -Ahmed
Hi, Thank you for suggestion. Mandatory part should not be a big challenge, but optional section might be tricky... We'll try to compile first beta draft text for the CPE and see if community likes it and what we need to change/add. best, Jan Zorz
From: Marco Hogewoning Sent: Sunday, January 09, 2011 1:22 PM To: Ahmed Abu-Abed Cc: kzorba@otenet.gr ; ipv6-wg@ripe.net Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment
On 9 jan 2011, at 05:40, Ahmed Abu-Abed wrote:
Good point, and having a Consumer CPE spec as a RIPE standard would help for last mile access requirements. RIPE-501 only aimed for government and enterprise deployments.
My personal preference would be to keep pointing to the work done in the IETF. The problem with standards is, there usually are too many. Adding another one will only lead to more confusion, let alone the time it will take to get consensus.
Grtx,
MarcoH
-- "Good tests kill flawed theories; we remain alive to guess again"
It's probably best to start from the existing "Basic Requirements for IPv6 Customer Edge Routers" draft. You might also want to check whether a CPE-focused RIPE document wouldn't reinvent the wheel. http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-09 Ivan
-----Original Message----- From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of Jan Zorz @ go6.si Sent: Sunday, January 09, 2011 1:30 PM To: Ahmed Abu-Abed; RIPE IPv6 Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment
----- Original message -----
My suggestion was to develop a best practice for consumer CPE specifications based on existing IETF standards/drafts.
Regards, -Ahmed
Hi,
Thank you for suggestion. Mandatory part should not be a big challenge, but optional section might be tricky...
We'll try to compile first beta draft text for the CPE and see if community likes it and what we need to change/add.
best, Jan Zorz
From: Marco Hogewoning Sent: Sunday, January 09, 2011 1:22 PM To: Ahmed Abu-Abed Cc: kzorba@otenet.gr ; ipv6-wg@ripe.net Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment
On 9 jan 2011, at 05:40, Ahmed Abu-Abed wrote:
Good point, and having a Consumer CPE spec as a RIPE standard would help for last mile access requirements. RIPE-501 only aimed for government and enterprise deployments.
My personal preference would be to keep pointing to the work done in the IETF. The problem with standards is, there usually are too many. Adding another one will only lead to more confusion, let alone the time it will take to get consensus.
Grtx,
MarcoH
-- "Good tests kill flawed theories; we remain alive to guess again"
----- Original message -----
It's probably best to start from the existing "Basic Requirements for IPv6 Customer Edge Routers" draft. You might also want to check whether a CPE-focused RIPE document wouldn't reinvent the wheel.
http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-09
Ivan
Ivan, hi. Ole already proposed this and I'm also looking into BBF TR124r2 as possible reference. /Jan
-----Original Message----- From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of Jan Zorz @ go6.si Sent: Sunday, January 09, 2011 1:30 PM To: Ahmed Abu-Abed; RIPE IPv6 Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment
----- Original message -----
My suggestion was to develop a best practice for consumer CPE specifications based on existing IETF standards/drafts.
Regards, -Ahmed
Hi,
Thank you for suggestion. Mandatory part should not be a big challenge, but optional section might be tricky...
We'll try to compile first beta draft text for the CPE and see if community likes it and what we need to change/add.
best, Jan Zorz
From: Marco Hogewoning Sent: Sunday, January 09, 2011 1:22 PM To: Ahmed Abu-Abed Cc: kzorba@otenet.gr ; ipv6-wg@ripe.net Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment
On 9 jan 2011, at 05:40, Ahmed Abu-Abed wrote:
Good point, and having a Consumer CPE spec as a RIPE standard would help for last mile access requirements. RIPE-501 only aimed for government and enterprise deployments.
My personal preference would be to keep pointing to the work done in the IETF. The problem with standards is, there usually are too many. Adding another one will only lead to more confusion, let alone the time it will take to get consensus.
Grtx,
MarcoH
-- "Good tests kill flawed theories; we remain alive to guess again"
Keep in mind that the document Ivan kindly proposed is still work in process... and that the last has not been mentioned about it. It is a good initial reference for this point in time, but to 'formaly' reference to it would result in a moving target I fear. G/ -----Original Message----- From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of Ivan Pepelnjak Sent: zondag 9 januari 2011 13:54 To: 'Jan Zorz @ go6.si'; 'Ahmed Abu-Abed'; 'RIPE IPv6' Subject: RE: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment It's probably best to start from the existing "Basic Requirements for IPv6 Customer Edge Routers" draft. You might also want to check whether a CPE-focused RIPE document wouldn't reinvent the wheel. http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-09 Ivan
-----Original Message----- From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of Jan Zorz @ go6.si Sent: Sunday, January 09, 2011 1:30 PM To: Ahmed Abu-Abed; RIPE IPv6 Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment
----- Original message -----
My suggestion was to develop a best practice for consumer CPE specifications based on existing IETF standards/drafts.
Regards, -Ahmed
Hi,
Thank you for suggestion. Mandatory part should not be a big challenge, but optional section might be tricky...
We'll try to compile first beta draft text for the CPE and see if community likes it and what we need to change/add.
best, Jan Zorz
From: Marco Hogewoning Sent: Sunday, January 09, 2011 1:22 PM To: Ahmed Abu-Abed Cc: kzorba@otenet.gr ; ipv6-wg@ripe.net Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment
On 9 jan 2011, at 05:40, Ahmed Abu-Abed wrote:
Good point, and having a Consumer CPE spec as a RIPE standard would help for last mile access requirements. RIPE-501 only aimed for government and enterprise deployments.
My personal preference would be to keep pointing to the work done in the IETF. The problem with standards is, there usually are too many. Adding another one will only lead to more confusion, let alone the time it will take to get consensus.
Grtx,
MarcoH
-- "Good tests kill flawed theories; we remain alive to guess again"
Gunter,
Keep in mind that the document Ivan kindly proposed is still work in process... and that the last has not been mentioned about it.
It is a good initial reference for this point in time, but to 'formaly' reference to it would result in a moving target I fear.
let me correct that. the document is done. and will be published as an RFC shortly. to provide the background. -07 was sitting in the RFC editor queue awaiting normative referenced documents to progress. because of some issues with broken host implementations and multiple prefixes, we chose to reiterate the document one more time, to lessen the change of dual stack breakage. -09 is now making its way back onto the queue. (since the referenced documents are still to be published this did not in any way delay the CPE router draft). cheers, Ole
Keep in mind that the document Ivan kindly proposed is still work in
Happy to be corrected... and happy to see this CPE journey come to a final conclusion :-) G/ -----Original Message----- From: Ole Troan [mailto:ot@cisco.com] Sent: maandag 10 januari 2011 11:02 To: Gunter Van de Velde (gvandeve) Cc: Ivan Pepelnjak; Jan Zorz @ go6.si; Ahmed Abu-Abed; RIPE IPv6 Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment Gunter, process... and that
the last has not been mentioned about it.
It is a good initial reference for this point in time, but to 'formaly' reference to it would result in a moving target I fear.
let me correct that. the document is done. and will be published as an RFC shortly. to provide the background. -07 was sitting in the RFC editor queue awaiting normative referenced documents to progress. because of some issues with broken host implementations and multiple prefixes, we chose to reiterate the document one more time, to lessen the change of dual stack breakage. -09 is now making its way back onto the queue. (since the referenced documents are still to be published this did not in any way delay the CPE router draft). cheers, Ole
Hi Ahmed, The IETF document I was refering to (http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router) is basically that. If there is strong support from the community to do something similar and turn it into a RIPE document we could look into this, but I personally would stick with the IETF one instead of doing it all over again and possibly ending up with minor differences. From personal experience I can tell it's already hard to get vendors to follow the IETF, most CPE builders are more familiar with the broadband forum. Having yet another 'standard' from yet another body won't help in this. Especially when from a vendor's perspective, you have customer A pointing to one document en customer B asking to be compliant to another one. Marco On 9 jan 2011, at 13:01, Ahmed Abu-Abed wrote:
My suggestion was to develop a best practice for consumer CPE specifications based on existing IETF standards/drafts.
Regards, -Ahmed
From: Marco Hogewoning Sent: Sunday, January 09, 2011 1:22 PM To: Ahmed Abu-Abed Cc: kzorba@otenet.gr ; ipv6-wg@ripe.net Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment
On 9 jan 2011, at 05:40, Ahmed Abu-Abed wrote:
Good point, and having a Consumer CPE spec as a RIPE standard would help for last mile access requirements. RIPE-501 only aimed for government and enterprise deployments.
My personal preference would be to keep pointing to the work done in the IETF. The problem with standards is, there usually are too many. Adding another one will only lead to more confusion, let alone the time it will take to get consensus.
Grtx,
MarcoH
-- "Good tests kill flawed theories; we remain alive to guess again"
From personal experience I can tell it's already hard to get vendors to follow the IETF, most CPE builders are more familiar with the broadband forum. Having yet another 'standard' from yet another body won't help in this. Especially when from a vendor's perspective, you have customer A pointing to one document en customer B asking to be compliant to another one.
I fully agree. For RIPE-501 creating a document created one point for vendors and enterprises to focus on. Doing this again for CPEs when the IETF is already working on draft-ietf-v6ops-ipv6-cpe-router would be counter-productive. - Sander
From personal experience I can tell it's already hard to get vendors to follow the IETF, most CPE builders are more familiar with the broadband forum. Having yet another 'standard' from yet another body won't help in
My suggestion was to develop a best practice for consumer CPE specifications based on existing IETF standards/drafts.
Regards, -Ahmed
From: Marco Hogewoning Sent: Sunday, January 09, 2011 1:22 PM To: Ahmed Abu-Abed Cc: kzorba@otenet.gr ; ipv6-wg@ripe.net Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment
On 9 jan 2011, at 05:40, Ahmed Abu-Abed wrote:
Good point, and having a Consumer CPE spec as a RIPE standard would help for last mile access requirements. RIPE-501 only aimed for government and enterprise deployments.
My personal preference would be to keep pointing to the work done in
I agree on this with Marco... A vendor would like to have centralization of certification requirements for operational cost and time investment effectiveness. Just imagine the potential effect... one certification for RIPE, one for ARIN, one for APNIC, etc... and then for the BBand forum, and for the v6 logo... Then another for governments etc... What is in current RIPE-501 is nice as it piggy-backs upon certification existing already which has attention of vendors already G/ -----Original Message----- From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of Marco Hogewoning Sent: zondag 9 januari 2011 16:00 To: Ahmed Abu-Abed Cc: RIPE IPv6 Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment Hi Ahmed, The IETF document I was refering to (http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router) is basically that. If there is strong support from the community to do something similar and turn it into a RIPE document we could look into this, but I personally would stick with the IETF one instead of doing it all over again and possibly ending up with minor differences. this. Especially when from a vendor's perspective, you have customer A pointing to one document en customer B asking to be compliant to another one. Marco On 9 jan 2011, at 13:01, Ahmed Abu-Abed wrote: the IETF. The problem with standards is, there usually are too many. Adding another one will only lead to more confusion, let alone the time it will take to get consensus.
Grtx,
MarcoH
-- "Good tests kill flawed theories; we remain alive to guess again"
On 8.1.2011 12:11, kzorba@otenet.gr wrote:
Greetings to all and happy new year.
We also used this document to extract basic features (in our environment) for customer CPEs. In my opinion, the "document" format must be preserved as a single place to contain the entire information. I guess 'if' statements like Jan mentions is one way to achieve the desired outcome.
Kostas, hi. If you did some stuff in that direction, can you send what you extracted from other sections and in your opinion fits the CPE requirements. All ideas and preliminary draft texts helps to go forward with the 501 doc. Regards, Jan P.S: Did we met in Athens at v6 TF meeting last summer?
Quoting "Jan Zorz @ go6.si" <jan@go6.si>:
On 8.1.2011 12:11, kzorba@otenet.gr wrote:
Greetings to all and happy new year.
We also used this document to extract basic features (in our environment) for customer CPEs. In my opinion, the "document" format must be preserved as a single place to contain the entire information. I guess 'if' statements like Jan mentions is one way to achieve the desired outcome.
Kostas, hi.
Hi Jan,
If you did some stuff in that direction, can you send what you extracted from other sections and in your opinion fits the CPE requirements.
Since I am out of the office these days, I will get back to you with this in the following days. Another colleague gathered the requirements and we also consulted IETF documents from what I know.
All ideas and preliminary draft texts helps to go forward with the 501 doc.
From what I understood in the discussions of the thread, the idea will be to provide pointers in the 501 doc to IETF documents, right? Some people expressed concerns that the RIPE document should not duplicate IETF work or come up with any sort of differences. Of course the 501 doc is not any form of standard, just some work that will help in moving IPv6 deployment a bit closer...
Regards, Jan P.S: Did we met in Athens at v6 TF meeting last summer?
Yes ;-) Regards, Kostas
On 9.1.2011 22:32, kzorba@otenet.gr wrote:
If you did some stuff in that direction, can you send what you extracted from other sections and in your opinion fits the CPE requirements.
Since I am out of the office these days, I will get back to you with this in the following days. Another colleague gathered the requirements and we also consulted IETF documents from what I know.
Kostas, hi. Thnx, appreciated.
All ideas and preliminary draft texts helps to go forward with the 501 doc.
From what I understood in the discussions of the thread, the idea will be to provide pointers in the 501 doc to IETF documents, right? Some people expressed concerns that the RIPE document should not duplicate IETF work or come up with any sort of differences. Of course the 501 doc is not any form of standard, just some work that will help in moving IPv6 deployment a bit closer...
I'm still thinking and need a discussion first with authors and see what community thinks - but pointing to RFC or draft is ok for us, we know how to read RFC and so on - problem is when somebody writes a tender for buying ICT equipment - in this case going to read RFC or draft or something might be quite complicated for some people. Not sure yet, do we just point to Ole's draft (that is excellent imho) or do we write a list of mandatory RFCs that are 1:1 in sync with the draft and BBF paper (Ole is also editing that) and keep the list in sync if draft/RFC changes. This way tender initiator can just copy/paste RFCs and this way the job is easy. Any thoughts? Cheers, Jan
Wouldn't it be easier to ask Ole to provide a list of mandatory and optional RFCs in his document than to extract them into another document (with all the resulting synchronization challenges)?
I'm still thinking and need a discussion first with authors and see what community thinks - but pointing to RFC or draft is ok for us, we know how to read RFC and so on - problem is when somebody writes a tender for buying ICT equipment - in this case going to read RFC or draft or something might be quite complicated for some people.
Not sure yet, do we just point to Ole's draft (that is excellent imho) or do we write a list of mandatory RFCs that are 1:1 in sync with the draft and BBF paper (Ole is also editing that) and keep the list in sync if draft/RFC changes. This way tender initiator can just copy/paste RFCs and this way the job is easy.
Any thoughts?
Cheers, Jan
On 10.1.2011 8:46, Ivan Pepelnjak wrote:
Wouldn't it be easier to ask Ole to provide a list of mandatory and optional RFCs in his document than to extract them into another document (with all the resulting synchronization challenges)?
Ivan hi, changing the document that is in IESG queue and "done" by IETF measures is not something anyone would want to do... :S /jan
Hi Jan,
Not sure yet, do we just point to Ole's draft (that is excellent imho) or do we write a list of mandatory RFCs that are 1:1 in sync with the draft and BBF paper (Ole is also editing that) and keep the list in sync if draft/RFC changes. This way tender initiator can just copy/paste RFCs and this way the job is easy.
Any thoughts?
I think the best way is to point to the IETF document. There are no reason to duplicate the work, especially while it is in draft. I suggest that we work with the second update of the RIPE-501 document with the "Basic Requirements for IPv6 Customer Edge Routers" draft ans mandatory, and keep the updated RIPE document in draft until the IETF document gets a RFC number. When this is done there are no need to do any changes to the RIPE document if the IETF document changes. So my suggestion is to only refer to the IETF document, not to duplicate it. Best Regards Ragnar Anfinsen Network Engineer Altibox AS
On 9 Jan 2011, at 22:10, Jan Zorz @ go6.si wrote:
I'm still thinking and need a discussion first with authors and see what community thinks - but pointing to RFC or draft is ok for us, we know how to read RFC and so on - problem is when somebody writes a tender for buying ICT equipment - in this case going to read RFC or draft or something might be quite complicated for some people.
Not sure yet, do we just point to Ole's draft (that is excellent imho) or do we write a list of mandatory RFCs that are 1:1 in sync with the draft and BBF paper (Ole is also editing that) and keep the list in sync if draft/RFC changes. This way tender initiator can just copy/paste RFCs and this way the job is easy.
Any thoughts?
I would assume the RFCs are what the vendors/implementors look to first, while the RIPE-501 text is, at least from what it says, aimed at enterprise sites writing procurement texts. So there's room in RIPE-501 to present the requirements in more general terms that are easier to (almost) cut and paste into tender documents. I think there's a lot of value in being able to point enterprises (e.g. universities) to RIPE-501 for procurement guidance. While some may be able to extract equivalent information from RFCs, RIPE-501 would in my view remain a valuable and useful abstraction of that information. Tim
I absolutely agree with your who-needs-what perspective. However, in an ideal world, Ole's draft would contain the "Mandatory/Recommended/Optional RFCs" section that would be ready for a cut-and-paste into a procurement document, in which case RIPE-501bis would only need to refer to that section of Ole's (future) RFC (or even have a copy of it, with pointer to the source). Ivan
-----Original Message----- From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of Tim Chown Sent: Monday, January 10, 2011 12:54 PM To: ipv6-wg@ripe.net Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment
On 9 Jan 2011, at 22:10, Jan Zorz @ go6.si wrote:
I'm still thinking and need a discussion first with authors and see what
community thinks - but pointing to RFC or draft is ok for us, we know how to read RFC and so on - problem is when somebody writes a tender for buying ICT equipment - in this case going to read RFC or draft or something might be quite complicated for some people.
Not sure yet, do we just point to Ole's draft (that is excellent imho)
or do we write a list of mandatory RFCs that are 1:1 in sync with the draft and BBF paper (Ole is also editing that) and keep the list in sync if draft/RFC changes. This way tender initiator can just copy/paste RFCs and this way the job is easy.
Any thoughts?
I would assume the RFCs are what the vendors/implementors look to first, while the RIPE-501 text is, at least from what it says, aimed at enterprise sites writing procurement texts. So there's room in RIPE-501 to present the requirements in more general terms that are easier to (almost) cut and paste into tender documents. I think there's a lot of value in being able to point enterprises (e.g. universities) to RIPE-501 for procurement guidance. While some may be able to extract equivalent information from RFCs, RIPE-501 would in my view remain a valuable and useful abstraction of that information.
Tim
Hello, On 01/10/2011 12:10 AM, Jan Zorz @ go6.si wrote:
On 9.1.2011 22:32, kzorba@otenet.gr wrote:
If you did some stuff in that direction, can you send what you extracted from other sections and in your opinion fits the CPE requirements.
Since I am out of the office these days, I will get back to you with this in the following days. Another colleague gathered the requirements and we also consulted IETF documents from what I know.
actually, the requirements were mostly gathered from http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-07 (haven't checked the diff with the new version yet). I agree with Marco and others about using the IETF doc as reference but I'm not sure if there's much of a point in making a RIPE document that basically points to the IETF draft. <snip>
I'm still thinking and need a discussion first with authors and see what community thinks - but pointing to RFC or draft is ok for us, we know how to read RFC and so on - problem is when somebody writes a tender for buying ICT equipment - in this case going to read RFC or draft or something might be quite complicated for some people.
Not sure yet, do we just point to Ole's draft (that is excellent imho) or do we write a list of mandatory RFCs that are 1:1 in sync with the draft and BBF paper (Ole is also editing that) and keep the list in sync if draft/RFC changes. This way tender initiator can just copy/paste RFCs and this way the job is easy.
that last proposal makes sense to me
Any thoughts?
Cheers, Jan
cheers, Yannis
Yannis, hi. On 1/17/11 4:09 PM, Dez wrote:
actually, the requirements were mostly gathered from http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-07 (haven't checked the diff with the new version yet). I agree with Marco and others about using the IETF doc as reference but I'm not sure if there's much of a point in making a RIPE document that basically points to the IETF draft.
Facing the crossroad here... We would like to make the doc as simple as possible and pointing to RFC is easiest way to do this. On the other hand, not only simple, RIPE-501bis needs to be usefull and can be used even by people that don't read RFCs.
Not sure yet, do we just point to Ole's draft (that is excellent imho) or do we write a list of mandatory RFCs that are 1:1 in sync with the draft and BBF paper (Ole is also editing that) and keep the list in sync if draft/RFC changes. This way tender initiator can just copy/paste RFCs and this way the job is easy.
that last proposal makes sense to me
The key question here is how stable that draft is and what would be syncing efforts like. When looking from shape point of view, we have currently 4 sections of equipment, all of them says: Mandatory: ... [list] Optional: ... [list] And 5th section would say Mandatory -> external RFC. Hmm. Cheers, Jan
participants (13)
-
Ahmed Abu-Abed -
Anfinsen, Ragnar -
Dez -
Eric Vyncke (evyncke) -
Gunter Van de Velde (gvandeve) -
Ivan Pepelnjak -
Jan Zorz ＠ go6.si -
kzorba＠otenet.gr -
Marco Hogewoning -
Nash, Steve -
Ole Troan -
Sander Steffann -
Tim Chown