I'm not clear, about this, but presumably the presence of a 6CIO is backward
compatible. That is, an implementation that does not support 6CIO but receives
one does not crash, and either ignores it or tells the sender that something odd
was received.
 
So 6CIO serves much the same purpose as the T-flag and it seems (to me!) you
could use on or the other (or both, as you have done!)
 
I tend to disagree with Carsten that putting flags in MBZ fields typically has
worse backwards compatibility. They were defined as MBZ (must ignore)
specifically to be forward compatible with new usage.
 
Adrian
 
From: Pascal Thubert (pthubert) [mailto:[email protected]] 
Sent: 26 February 2018 18:01
To: [email protected]
Cc: Adrian Farrel ([email protected])
Subject: 6CIO in rfc 6775 update
 
Dear all
 
Quoting Adrian's RTG DIR review:
 
> 7.1.2
> 
>    One alternate way for a 6LN to discover the router's capabilities is
>    to start by registering...
> 
> You went to a lot of trouble to define the E-flag. You then made the use of
the
> 6CIO (and hence the E-flag) only a SHOULD, and you defined an alternate
> mechanism. (Note: you say "one alternate" implying there are
> more!)
> 
> Choice is not good. It complicates the specification and the implementation.
> Why go there? Can't you settle on one mechanism and make it necessary and
> sufficient?
> 
 
https://tools.ietf.org/html/draft-ietf-6lo-rfc6775-update-14#section-7.1.1
defines new capability bits for use in the 6CIO,  which was introduced by
RFC7400 to announce support of the spec.
When there is no 6CIO, there's a plan B using EUI-64 as RUID and IID in a
NS(EARO), which is fully backward compatible, and see if the response has an
EARO or not from the T flag.
Adrian indicates that a double mechanism is complexity. For backwards
compatibility we need to be able to live without 6CIO. Still 6CIO seems to be a
good mechanism to generalize and that's why we used it.
 
So should we keep the CIO mechanism, or should we drop it?
 
Pascal
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo

Reply via email to