Subject: [pim] PIM Pop Count - Allow more than 16 options ?

From: Thomas Morin <[email-masked]>
Date: Thu, 07 Apr 2011 12:05:37 +0200

Hi working group, Greg, Dino,

Wouldn't it be a good idea to arrange for the possibility of having more 
than 16 options?

A possibility would be to give a special role to the last bit of the 
option bitmap: if set, it would mean that the next two bytes after the 
option bitmap would also carry an option bitmap (a second one for 15 
additional options), and the first option would start after this second 
option bitmap. And if the last bit of this second bitmap was set, then 
there would be yet another option bitmap...

Another possibility would be a TLV encoding for all the options...

Comments ?

-Thomas

PS: by the way, "options" here is not a great name, what about "fields" 
or "metrics"...?

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 7 Apr 2011 06:25:11 -0400

It might be easier to find the start of the first option if we have a length field to indicate how large the bitmap is, instead of relying on the last bit of each extension of the bit map?

That length field could be the first option itself.

Jeffrey

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Thomas Morin
> Sent: Thursday, April 07, 2011 11:06 AM
> To: [email-masked]; Greg Shepherd; [email-masked]
> Subject: [pim] PIM Pop Count - Allow more than 16 options ?
> 
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim
>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 7 Apr 2011 08:30:44 -0400

> That length field could be the first option itself.

To clarify, I meant the length/size of the extended bitmap (that is separated from the standard one), and it shoud come after (vs. before)  all the standard options. And for that reason, it might be better for it to be the last standard option.

Jeffrey

> Behalf Of Jeffrey (Zhaohui) Zhang
> Sent: Thursday, April 07, 2011 11:25 AM
> To: Thomas Morin; [email-masked]; Greg Shepherd; [email-masked]
> Subject: Re: [pim] PIM Pop Count - Allow more than 16 options ?
> 
> It might be easier to find the start of the first option if 
> we have a length field to indicate how large the bitmap is, 
> instead of relying on the last bit of each extension of the bit map?
>

---

From: Stig Venaas <[email-masked]>
Date: Thu, 07 Apr 2011 10:02:40 -0700

Hi Thomas

> there would be yet another option bitmap...

I have thought of this, and I think my idea is similar to yours. If we
start running out, we define the last option (option 16) to be a
bitmap option. At that time, we can define how big we want it, e.g.
2 bytes. Those 2 bytes would then be a bitmap showing which options
follow. Following the current rules, that bitmap would then come
after the currently known options in the packet.

If we again run out, the last option in that bitmap can be a new bitmap
option as well. But I don't think we should worry about this in the
current draft. As long as we know we have a way to do it. Does this
sound reasonable?

> Another possibility would be a TLV encoding for all the options...

It would require a lot more space, making the J/P messages a lot
bigger.

Stig

---

From: Thomas Morin <[email-masked]>
Date: Fri, 08 Apr 2011 09:34:37 +0200

Hi Stig,

Stig Venaas:
> option as well.

Yes, this is good (also quite close to what Jeffrey suggested).

> But I don't think we should worry about this in the

Even though there is no rush to fully define that 16th special option 
yet, documenting in the draft that extensibility would be brought by the 
method you have in mind would be nice, and indicate that extensions to 
this draft must not use the 16th bit of the option map for another purpose.

> It would require a lot more space, making the J/P messages a lot

I Agree.

-Thomas

---

From: Stig Venaas <[email-masked]>
Date: Fri, 08 Apr 2011 09:45:29 -0700

On 4/8/2011 12:34 AM, Thomas Morin wrote:
[...]
> this draft must not use the 16th bit of the option map for another purpose.

Yes, I think you are right :) Hopefully we are all around when it is
needed and we can do it then, but it is good to put it in the draft.
Will try to do an update soon.

It would be great if you (and others too of course) can review this
and see whether you think it's ready for wglc, or what other changes
you would like to see.

Thanks,

Stig