Hi Jan, two last-minute comments from me...
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. > 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. 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. btw, thanks for all the great work on this doc! -- 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ž >>> >
