[ipv6-wg] Version 6 of IPv6 prefix delegations BCOP is out

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


-------------- 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/20170809/7acd0184/attachment.p7s>