A big Thank You to Jan and the co-authors team for the huge amount of work they have put into this ! Rgds, Ray -----Original Message----- From: ipv6-wg [mailto:ipv6-wg-bounces@ripe.net] On Behalf Of Jan Zorz - Go6 Sent: 15. elokuuta 2017 12:41 To: ipv6-wg@ripe.net Subject: Re: [ipv6-wg] Version 6 of IPv6 prefix delegations BCOP is out On 13/08/2017 17:50, Tassos Chatzithomaoglou wrote:
Hi Jan,
two last-minute comments from me...
Hey, Thnx for your comments!
I seem to have a problem understanding the following paragraph:
Non-persistent prefix assignment also appears initially easier as it facilitates aggregation of internal routing tables according to end customer connection termination points. Every termination point has its own pool of IPv6 prefixes that are nicely aggregable, whilst with persistent IPv6 prefix assignments it is necessary to discover which customer is terminated at which termination point, group them into larger IPv6 pools, and then update our database accordingly. This is unless your provisioning system is doing it in the other way around from an AAA database and is typically tied to an IPAM for the initial assignment to each new customer> Can you please elaborate a little bit more? Give more details about the "database"? In my case, each customer may end up in a different BNG in the same aggregation area, due to load-balancing & redundancy reasons. So the only possible routing aggregation point is at a level higher than the BNG one.
In your case - that is true. At some point in time you need to decide at which level you are going to aggregate. We did not want to go that specific in the document, otherwise the size would grow infinitely if we would describe every specific detail.
However, the CPE rarely knows that before the reboot there was a different prefix on the network, and the packets to revoke the old IPv6 addresses do not get sent. Also, the "rarely" in the above statement is not applicable for us. We have multiple CPEs in our network and all of them store each delegated prefix, so when after a reboot a new one gets assigned, the old one is removed by sending the appropriate RAs. A few vendors had that functionality from the beginning, while most others fixed it later on. It's surely an issue, but imho an easy one to be solved.
Agree. When every CPE used in every network will have this functionality, then life will be quite easier for IPv6 deployment to the end customers. Until then, we need to find the common lowest denominator and try to give the advice that would not break people's networks ;) Later on in the text we give this advice: "If you wish to do non-persistent prefix delegation, you must verify that the CPEs used by the majority of your users will not have the problems described above. If this can’t be ensured, then the recommendation is to avoid using non-persistent prefixes and revisit the CPE and end user device implementations periodically to see whether this has become feasible if you still need that." I think that this is sufficient for majority of cases.
Ideally that should have been included in RFCs 6204/7084 (and TR-124), but since it wasn't clearly defined, we took L-13 and adjusted it to our needs.
Indeed! :) Operators need to vote with their wallets and push CPE vendors to implement those IPv6 mechanisms needed to make IPv6 deployment for end-customers easy and seamless, for example "remember what was the prefix before reboot and if there is a new prefix delegated - send RA packets for the old one with lifetime of 0 to withdraw it from the network"... That would help a lot ;)
btw, thanks for all the great work on this doc!
Thank you for your comments... We've been working on this document long enough (me think), it's time to make it a stable RIPE BCP document with a number ;) Cheers, Jan
-- Tassos
Jan Zorz - Go6 wrote on 11/8/17 13:22:
Hey,
On 09/08/2017 16:28, Yannis Nikolopoulos wrote:
Hello again and thank you for the effort, No problem...
I addressed some of your comments and here is the version 7 f the draft:
https://www.sinog.si/docs/draft-IPv6pd-BCOP-v7.pdf
I hope that now everyone is happy with the text and we can move on towards getting a stable RIPE BCP document (after RIPE NCC staff does the language pass... :) )
But, if there are substantial comments or suggestions, we are still in editing phase...
Cheers, Jan Zorz (on behalf of v6_pd BCOP co-authors)
just a few more comments
Executive Summary, b2: The benefit is not clear. "Differentiate..., even if it increases complexity". I would expect something along the lines of: "Differentiate..., even if it increases complexity, because of this and that benefit"
Chapter 3, third paragraph: "This may be immediate in terms of other networks or content providers...". We might want to rewrite this as "This may have an immediate impact, like when other networks or content providers..."
Chapter 4, first paragraph: "At this point, the IPv4 scarcity needs to be reconsidered because the abundance of IPv6 addresses enables numbering decisions to be taken differently." . Its not the scarcity that needs to be reconsidered, its the numbering decisions due to that scarcity.
4.1.2: "Finally, certain hardware in the ISP infrastructure may consume resources when using numbered links. This is a very specific situation that you may need to consider." As a more general comment, I feel that this BCOP is lacking examples that make the points "relatable"
4.2.1: "This is probably the most practical and pragmatic way..." Desired it may be, pragmatic it certainly isn't
cheers,
Yannis
On 08/08/2017 12:01 PM, Jan Zorz - Go6 wrote:
Dear RIPE IPv6 WG,
We received offline some good and valuable comments from MarcoH, addressed them and issued the version 6 of the document draft.
https://sinog.si/docs/draft-IPv6pd-BCOP-v6.pdf
Please, read and comment, if you think that we need to carry on with editing this document. If not, I would like to see if we can reach a consensus to move forward and ask RIPE staff to do the language check and publish this document as RIPE BCP.
Any comments? Suggestions?
For v6_pd_BCOP co-authors team, Jan Žorž