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

From: Robert Cragie <[email-masked]>
Date: Wed, 21 Nov 2012 18:09:16 +0000

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

---

From: Dario Tedeschi <[email-masked]>
Date: Wed, 21 Nov 2012 17:00:55 -0800

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Thu, 22 Nov 2012 01:06:15 +0000

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 <[email-masked]<mailto:[email-masked]>> 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll

---

From: Robert Cragie <[email-masked]>
Date: Thu, 22 Nov 2012 10:05:42 +0000

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
>
>> need to read the Length field so it can make sure the 'S' field 
>> wasn't lying.
>>
>> - Dario
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Dario Tedeschi <[email-masked]>
Date: Thu, 22 Nov 2012 13:27:26 -0800

I have no strong opinion on the matter. Besides, I don't want to get 
stuck in an argument over 1 bit. :-)

If you think sub-TLVs could be a real use-case, I'm fine with it. 
However, I will say that I'm unaware of any hop-options that have sub-TLVs.

- Dario

On 21/11/2012 5:06 PM, Jonathan Hui (johui) wrote:
>>> 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
>>>
>>>
>>>