[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ž
>>>> 
>> 
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3976 bytes
Desc: S/MIME Cryptographic Signature
URL: </ripe/mail/archives/ipv6-wg/attachments/20170815/197df58a/attachment.p7s>