On 09/08/2017 16:28, Yannis Nikolopoulos wrote:
Hello again and thank you for the effort,
just a few more comments
Hi, Does that bring us to v.7 of the draft and another cycle? If so, let's do it ;)
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"
We had that in there, but decided to leave it out intentionally. The only benefit there is "to make ISP's sales/marketing people happy, because they can then show/market the difference between business and residential data packet" :) That's the only benefit of /48 for business and /56 for residentials and we felt that this might not be the serious reason enough to have it in there. Some people do it, but I would leave them to decide if they want it or not. Or not? :)
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..."
fixed.
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.
fixed.
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"
We should not go to very details as then the document becomes too long... Anonymizing one of the ISP's comments from one of the first versions of this document: ------- Certain type of BNG/BRAS uses a resource called a "subscriber-host" to track addressing bound to a subscriber regardless of encapsulation (whilst allowing a single queue to be used for all traffic, and a single accounting data stream, and other per-subscriber stuff like uRPF). A subscriber-host is consumed for each GUA prefix routed to that subscriber (link-local is handled separately as it's only used for DHCP/ND), so adding a GUA WAN address adds an additional one of these (3 instead of 2 for a dual-stack subscriber). There is a limit of subscriber-hosts per-linecard, and per-chassis, and it's one of the key resources involved in scaling a BNG. Cisco ASR9k has similar approach and limits with doing hardware-based BNG iirc. ------- So, if that is the case with the "reader", they'll know what is being discussed there ;) Do you have a suggestion how to describe that in one short sentence? I could not find the way, therefore we omitted it.
4.2.1: "This is probably the most practical and pragmatic way..." Desired it may be, pragmatic it certainly isn't
I argue that it is very pragmatic :) Everyone the same size and be done with it ;) We can remove "pragmatic", if that's the issue... Cheers, Jan
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ž