Re: [Roll] 'S' field in MPL Options

[Robert Cragie <[e-mail]>]

OK, so we're onto the subject of backwards compatibility. So we have two 
choices here (not mutually exclusive):

 1. Always maintain backwards compatibility
 2. Allow future revisions to change the format

(1) is desirable of course but means more restrictions in how the format 
can be changed. (2) gives flexibility but breaks backwards compatibility.

 1. If we are ever going to consider (2) we need some sort of version
    numbering (implicit or explicit) and an ability to discard the
    packet if the header is not understood. We sort of have that now
    with the 'rsv' field as mentioned in previous posts but it might be
    better to specify at least one bit as a version field to ensure a
    "version > 0" option format sets that bit to ensure "version == 0"
    implementations discard it (better to discard than erroneously process).
 2. If we always want to maintain backwards compatibility from now on,
    we don't strictly need a version number providing the rules are
    clear in "version == 0" and the format allows extension of the
    option. In this case,  we would need to:
     1. Keep the 'S' field
     2. State that future revisions MUST only extend using sub-TLVs and
        cannot fundamentally change the format of the option (see point 2.4)
     3. State that any unknown extension of the option MUST be skipped over
     4. Suggest changing the rules for 'rsv' to be set to 0 and ignored
        on receipt. This would allow future revisions to use these bits
        and remain backwards compatible

On point 2.4, we could still have a version number/bit in the 'rsv' 
field meaning that future revisions have a choice. I can't think why a 
future revision would deliberately break backward compatibility - the 
only possible one would be compact encoding (TLVs are not that efficient).

Robert


On 22/11/2012 1:06 AM, Jonathan Hui (johui) wrote:
>
> The question is whether we want to allow sub-TLVs in the MPL Option. 
>  A future specification could introduce sub-TLVs, but that would not 
> be backwards compatible if we did not have an explicit length for the 
> seed-id.  Given the small namespace for IPv6 Options, we might want to 
> consider having a way of including additional fields that is backwards 
> compatible.
>
> --
> Jonathan Hui
>
> On Nov 21, 2012, at 5:00 PM, Dario Tedeschi <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>> I agree
>>
>> The 'S' field seems redundant, because an implementation would still 
>> need to read the Length field so it can make sure the 'S' field 
>> wasn't lying.
>>
>> - Dario
>>
>> On 21/11/2012 10:09 AM, Robert Cragie wrote:
>>> Referring to 
>>> http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-02 section 
>>> 4.1 - maybe I'm missing something but why is the 'S' field needed? 
>>> Given that the text for Opt Data Len is wrong (it should say "Length 
>>> of the Option Data field in octets. MUST be set to 2, 4, 10 or 18"), 
>>> surely Opt Data Len is sufficient for working out which Seed IDs are 
>>> in there?
>>>
>>> Robert
>>>
>>>
>>>
>>> _______________________________________________
>>> Roll mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/roll
>>
>> _______________________________________________
>> Roll mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/roll
>