Re: [Idr] WG adoption of draft-heitz-idr-large-community; one week to comment on early code point allocation

["Peter van Dijk" <[e-mail]>]

Hello Remco,

On 24 Sep 2016, at 12:39, Remco van Mook wrote:

>> 2) Does the section 3 'textual representation' wording allow 
>> sufficient
>>    flexibility to accomodate BIRD- or JunOS-style syntax?
>
> Personally, I don't see the merit in requiring all the integers - 
> instead, I
> think it's bad for readability (but then again I might have been 
> exposed to
> IPv6 for too long). I think there's nobody who's going to 
> misunderstand
> 65535::, 65535:1:, 65535::1 or even ::1:2.

For interoperability, management and for software testing, it is best to 
have a single canonical representation. Experience with the IPv6 
‘compression’ feature shows that vendors are unable to implement 
this consistently. Note for example the perl hack in here 
https://github.com/PowerDNS/pdns/blob/master/regression-tests/tests/basic-aaaa-resolution/command 
- this is because OSX (at least in 10.10 which I’m still running) 
*gets it wrong*. If you allow compression like this, even if you specify 
exactly when to compress (which RFC 5952 does a theoretically fine job 
of), vendors will mess it up. Look at your own ‘::1:2’ as an example 
of how confusing compression is especially on such short values. I 
understand why v6 has the compression - you get a heap of zeros in many 
cases. But for large communities we are talking a few zeroes max. Better 
to have a strict canonical format that is as simple as possible.

Also, without compression, there is no chance of mistaking a large 
community for a v6 address. Once you allow compression, is 2001::5 a v6 
address or a large community? Perhaps this is not the strongest point 
but if we can avoid this at zero cost, why not?

In short, the current approach with mandatory zero fields but no leading 
zeros looks sane to me. It is canonical, there is no confusion, and 
vendors should be able to get it right.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/