Re: [pim] AD Review of draft-ietf-pim-assert-packing-05

[Stig Venaas <[e-mail]>]

Hi Toerless

Agree. We do have cases where there are several assert messages per
second (which is why we need this), but maybe there will still be say
at least 1 message per second. So I think it's not unlikely that a new
router coming up might encounter the new assert format before its
hello is processed by other routers. So I think having a 0 first byte
would be good.

Regards,
Stig

On Thu, Feb 16, 2023 at 8:09 AM Toerless Eckert <[e-mail]> wrote:
>
> Ack. Happy to hear from any other WG members opinions.
>
> I do somewhat ponder that it would not be a bad idea to have the first byte of payload zero
> filled to be able to actually know that the new messages will not be misinterpreted
> in the case Stig mentioned. But i don't want to over-engineer either.
>
> Cheers
>     Toerless
>
> On Wed, Feb 15, 2023 at 07:52:53PM -0600, Alvaro Retana wrote:
> > FWIW — besides removing the count, I don’t think any of the other changes
> > are needed.
> >
> > Alvaro.
> >
> > On February 13, 2023 at 1:54:21 PM, Toerless Eckert ([e-mail]) wrote:
> >
> > Some quick thoughts:
> >
> > - It's fine to remove the count by me. I just did this rev with what i felt
> > was
> > necessary to solve Alvaros feedback. here is what i would suggest:
> >
> > - If we want to solve the small windows of inconsistency:
> > We can insert an 0-bit zero field as the first byte of the
> > PackedAsserts. This will ensure thart thhey always fail to
> > be valid Asserts because zero is reserved in the address types
> > used to encode the group address. And to keep the structures 16-bit
> > alignment (as ew have it now), we follow this up with 8 bit reserved.
> >
> > - For extensibility with future possible additional assert options,
> > we can add the notion to the PacketAssert option that a length
> > > 0 MAY be used, but will be ignored on receipt.
> > This means that we could avoid introducing a new IM Hello Option
> > codepoint if we would amend/revise the functionality in the
> > future with more/different assert message types. That would then
> > use some length > 0, and the spec would say to only use this
> > when all routers announce it.
> >
> > Cheers
> > Toerless
> >
> > On Fri, Feb 10, 2023 at 12:40:12PM -0800, Stig Venaas wrote:
> > > Hi Alvaro
> > >
> > > That's a great point. Sorry Toerless, I did not think about that when
> > > I emailed earlier.
> > >
> > > Only potential issue is that there might be some small window where an
> > > older implementation is coming up and is receiving such a message
> > > before the other routers parse its hellos. Not sure how likely that
> > > is. This is of course an issue with hello capabilities in general.
> > >
> > > Will have a closer look at the new version soon.
> > >
> > > Thanks,
> > > Stig
> > >
> > > On Fri, Feb 10, 2023 at 12:31 PM Alvaro Retana <[e-mail]>
> > wrote:
> > > >
> > > > On February 10, 2023 at 12:17:30 PM, Stig Venaas wrote:
> > > >
> > > > Stig:
> > > >
> > > > Hi!
> > > >
> > > >
> > > > > I see you are reusing the assert message type in the latest draft.
> > > > > That won't work. Existing implementations would not check the
> > reserved
> > > > > bits, they would just assume it is a regular assert. It is ok to use
> > a
> > > > > new message type, but using one for each of the packet formats is
> > > > > unnecessary.
> > > >
> > > > Yes, but that shouldn't be an issue because the drafts says that
> > > > "PackedAssert messages (Section 3.2) MUST only be sent when all PIM
> > > > routers in the same subnet announce this option." So all the
> > > > implementations will have to be updated for this to be used.
> > > >
> > > > Alvaro.
> >
> > --
> > ---
> > [e-mail]
>
> --
> ---
> [e-mail]