Re: [pim] AD Review draft-ietf-pim-null-register-packing-11

["Ananya Gopal (ananygop)" <[e-mail]>]

Hi Alvaro, Stig,
Version-13 has been submitted.
Here are the responses to the review comments:
[RC12-1] The abstract seems to contain references ([RFC7761]), which it
   shouldn't.  Please replace those with straight textual mentions of the
   documents in question.
AG> Reference removed, text is sufficiently explanatory.


[RC12-2.1 ] The header ("PIM Version...Source Address:") is not needed.
There's no need to indent the paragraph.  This applies to the other
descriptions as well.
136          P:
138             Capability bit: When set, it indicates the ability of the RP to
139             receive PIM Packed Null-Register messages, and send PIM Packed
140             Register-Stop messages.
AG> Indentations removed, fixed the descriptions.

[RC12-2.2 ] Suggestion>
   P (Capability bit / Flag Bit TBD1): When set...
AG> Added.

[RC12-3 ]
> AG> If it is not too late at this stage, and if we can proceed without these
> AG> two fields, I can update the draft accordingly. I have the proposed draft
> AG> ready as well.
Because there are no implementations, changes are ok.
I would like to hear from Stig.  We should also check with the WG.
AG> Removed the count, reserved fields, removed the text that refers to these fields as well.
The artwork & descriptions now match the new packet format.


[RC12-4 ]
Related -- I wonder if §7 (Fragmentation Considerations) should be
stronger.  It currently reads:

286        7.  Fragmentation Considerations
288          When building a PIM Packed Null-Register message or PIM Packed
289          Register-Stop message, a router should include as many records as
290          possible based on the path MTU towards RP, if path MTU discovery is
291          done.  Otherwise, the number of records should be limited by the MTU
292          of the outgoing interface.
[major] "...should include as many records as possible based on the
path MTU towards RP...[OR]...should be limited by the MTU of the
outgoing interface."
The MTU on the interface could be larger than the MTU on the path.  If
PMTUD is not used then the sender wouldn't know and may send more
records than can be transmitted.
Can the size limit be required?  Note that rfc7761 already requires
PTUD (for IPv6).

Suggestion>
   In line with rfc7761, the sender of the PIM Packed Null-Register
   or PIM Packed Register-Stop messages is REQUIRED to perform Path
   MTU Discovery and fragment the messages as needed.  The number of
   records in a message MUST be limited by the MTU towards the RP.

AG>
Changed.. please review..

...
[RC12-5 ]Once the DR starts using the new messages, does it have to always use
> them? Can a mixture of packed and unpacked messages be used?
>
> AG> We are allowed to use a mixture, but most implementations would probably
> AG> find it easier to stick to the new format as long as the RP is capable.
> AG> There is no harm in using a mixture.
Ok, please add something to the corresponding step:
234          *  When a Register-Stop message with the P-bit set is received, the
235             DR MAY send PIM Packed Null-Register messages (Section 3) to the
236             RP instead of multiple Register messages with the N-bit set
237             [RFC7761].
Something like: The DR may use a mixture of PIM Packed Null-Register
messages  and Register messages; the decision is up to the
implementation and out of the scope of this document.
AG> Added: “The decision is up to the implementation and out of the scope of this document. However, it is RECOMMENDED to stick to the packed format as long as the RP and DR are capable.”

...
[RC12-6 ]When it is ok for the RP to not use PIM Packed Register-Stop
> messages? IOW, why is this action recommended and not required?
>
> I assume that even if supported, the RP may decide (by configuration??) that
> if doesn't want to use the new messages. If this is the justification, then
> it seems to me that a better Normative keyword would be "MAY" (instead of
> SHOULD).
>
> AG> The configuration may not be enabled on the RP, while it is ON on the DR.
> AG> In that case, after receiving DR's PIM Null-Register message, RP sends a
> AG> normal Register-Stop without any capability information. DR then sends
> AG> PIM Null-Registers in the unpacked format.
In the context of the description of the functionality you should
assume that both sides support it/have it configured.  Similar to the
operation of the DR, it seems that the use of the packed messages my
the RP is also OPTIONAL (MAY), right?
AG> Added: “The decision is up to the implementation and out of the scope of this document. However, it is RECOMMENDED to stick to the packed format as long as the RP and DR are capable.”
<>

...
[RC12-8]
s/rfc4610/RFC4610
Otherwise the tools don't pick the reference up.
AG> Changed as suggested.

[RC12-9]
If the DR receives the P-bit from an RP, should it assume that the
> condition is met, or is there a way to verify?
>
> AG> If the P-bit is set, then we can safely assume that the RP is capable
> AG> since it is a reserved flag bit for a special purpose.
Right, but there's no way to verify that *all* the routers in the
Anycast-RP set support it -- until one of them fails.
AG> That’s right.. not sure what I can add here.

[RC12-10]"should be enabled" Is Normative language needed? What is the impact
> of a partial deployment?
>
> AG> Yes, normative language is needed. If routing changes, you might have
> AG> been sending registers to a packed register capable router, and now you
> AG> start sending to one that is not capable. In that case, the register
> AG> stops would be ignored until we fall back to not using packed registers.
> AG> I can add this as the next sentence to the draft(version 13) to explain
> AG> why it is “SHOULD”.
No -- actually, your explanation (and the fact that there's no way to
verify) justifies that the text should not be Normative (don't change
the "should" for "SHOULD").
AG>
You are right, I have left the text as is. not changing the should to SHOULD.
With anycast RP we send registers to the anycast RP address, and it depends on routing which RP actually receives the message. So if there are routing changes, it might be that we used to reach an RP that supported P, but now suddenly we are sending them to an RP that doesn't support P.
Since there is no way an implementation can guard against this. It is more for whoever deploys it to make sure of this.

[RC12-11]
> 306 Consider a PIM RP router that supports PIM Packed Null-Registers and
> 307 PIM Packed Register-Stops. When this router downgrades to a software
> 308 version which does not support PIM Packed Null-Registers and PIM
> 309 Packed Register-Stops, the DR that sends the PIM Packed Null-Register
> 310 message will not get a PIM Register-Stop message back from the RP.
> 311 In such scenarios the DR can send an unpacked PIM Null-Register and
> 312 check the PIM Register-Stop to see if the capability bit (P-bit) for
> 313 PIM Packed Null-Register is set or not. If it is not set then the DR
> 314 will continue sending unpacked PIM Null-Register messages.
>
> [major] "In such scenarios the DR can..."
>
> How does the DR detect this situation? Is there a timer (rfc7761 ??) that can
> alert the DR of the lack of support?
>
> [AG] We think this needs to be discussed more. But some options are:
> [AG]
> [AG] If more than N consecutive packet register messages have been sent
> [AG] without getting register stop?.. N can be 5 for example.
> [AG] Or if we revert to data registers due to no null registers received,
> [AG] start a timer. If no register packed register stop or register stop with
> [AG] capability is seen within N seconds, assume RP does no longer support
> [AG] packed registers. and this timer could be configurable, with N’s default
> [AG] value as 60 seconds.
> [AG]
> [AG] I can add a section for Configurable Parameters, and also add this to
> [AG] Operational Considerations in the next draft as a separate section
> [AG] (Section 6.3)
Either way works for me.  I asked about a timer because rfc7761
defines Register_Probe_Time which might be reused.
Pending Stig's comments, I suggest that you pick one so the WG can weigh in.
AG> I have added information about Packed_Register_Probe_Time

[RC12-12]
Fixed IANA considerations
<End of Review Response >

The count & reserved fields have been removed.. and the Timer Packed_Register_Probe_Time has been introduced in version 13. Please let me know if further changes are needed.

Thanks.
Ananya

From: Stig Venaas (svenaas) <[e-mail]>
Date: Monday, February 6, 2023 at 3:36 PM
To: Alvaro Retana <[e-mail]>, Ananya Gopal (ananygop) <[e-mail]>, Stig Venaas <[e-mail]>
Cc: [e-mail] <[e-mail]>, Mike McBride <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: RE: [pim] AD Review draft-ietf-pim-null-register-packing-11
Hi Alvaro and Ananya

The bigger change is regarding the count in the new message formats, right? I agree there is no reason to have a count in the new message formats. It just complicates parsing and validation. There is no reason to add a reserved field either.

We should certainly check with the WG. Mike, since you are the shepherd, can you do this?

It is probably best to have a new email just focusing on this one question, but of course the WG will have the chance to review the new version as well.

Thanks,
Stig

> -----Original Message-----
> From: Alvaro Retana <[e-mail]>
> Sent: Monday, February 6, 2023 2:32 PM
> To: Ananya Gopal (ananygop) <[e-mail]>; Stig Venaas
> <[e-mail]>
> Cc: [e-mail]; Mike McBride <[e-mail]>; draft-ietf-
> [e-mail]; [e-mail]
> Subject: Re: [pim] AD Review draft-ietf-pim-null-register-packing-11
> Importance: High
>
> On February 6, 2023 at 2:52:36 PM, Ananya Gopal wrote:
>
>
> Ananya:
>
> Hi!
>
> > Thank you for the helpful and careful review. Please find my responses
> below.
> > We would need another draft once I know your thoughts about [RC10] and
> > specially, [RC18].
>
> I put my opinion below, but definitely want to hear from Stig -- and the
> changes will need confirmation from the WG.
>
> Once you submit a new version we can start the IETF Last Call and poll the
> WG in parallel.
>
> Thanks!
>
> Alvaro.
>
>
> ...
> > draft-ietf-pim-null-register-packing-12 as per your suggestions.
>
> ** The abstract seems to contain references ([RFC7761]), which it
>    shouldn't.  Please replace those with straight textual mentions of the
>    documents in question.
>
>
>
> ...
> > [RC7.2] Suggestions about changing the field definitions
> >
> >
> > AG> All three figures now have the new header and field definitions
> > AG> per RFC8736. Also, the packet field definitions have also been
> changed.
>
> 130      PIM Version, Type, Flag bits, Checksum, Group Address, Source
> 131      Address:
>
> 133         The fields in the PIM Register-Stop message are defined in
> 134         Section 4.9.4 of [RFC7761], and the common header in [RFC8736].
>
> [nit] The header ("PIM Version...Source Address:") is not needed.
> There's no need to indent the paragraph.  This applies to the other
> descriptions as well.
>
>
> 136      P:
>
> 138         Capability bit: When set, it indicates the ability of the RP to
> 139         receive PIM Packed Null-Register messages, and send PIM Packed
> 140         Register-Stop messages.
>
> [nit] Suggestion>
>
>    P (Capability bit / Flag Bit TBD1): When set...
>
>
>
> ...
> > [RC10] The length of the message is not explicit in the PIM message,
> > but it is inferred from the IP layer. What should the receiver do if
> > the count indicates a number of records that would result in a message
> > with a length different from that is expected?
> >
> > AG> I think that the count field is not really required in the packet
> > AG> format
> > AG> - we would parse and obtain each record after the header, until
> > AG> the length of the message (inferred from the IP layer). Its
> > AG> presence leads to unnecessary checks and processing. Also, we
> > AG> don’t need the reserved field as well, because we can use the Flag
> > AG> Bits for special purposes when the Type is PIM Packed
> > AG> Null-Register Type and/or PIM Packed Register-Stop.
> > AG>
> > AG> If it is not too late at this stage, and if we can proceed without
> > AG> these two fields, I can update the draft accordingly. I have the
> > AG> proposed draft ready as well.
>
> Because there are no implementations, changes are ok.
>
> I would like to hear from Stig.  We should also check with the WG.
>
> Related -- I wonder if §7 (Fragmentation Considerations) should be
> stronger.  It currently reads:
>
> 286   7.  Fragmentation Considerations
>
> 288      When building a PIM Packed Null-Register message or PIM Packed
> 289      Register-Stop message, a router should include as many records as
> 290      possible based on the path MTU towards RP, if path MTU discovery
> is
> 291      done.  Otherwise, the number of records should be limited by the
> MTU
> 292      of the outgoing interface.
>
> [major] "...should include as many records as possible based on the path
> MTU towards RP...[OR]...should be limited by the MTU of the outgoing
> interface."
>
> The MTU on the interface could be larger than the MTU on the path.  If
> PMTUD is not used then the sender wouldn't know and may send more
> records than can be transmitted.
>
> Can the size limit be required?  Note that rfc7761 already requires PTUD (for
> IPv6).
>
> Suggestion>
>    In line with rfc7761, the sender of the PIM Packed Null-Register
>    or PIM Packed Register-Stop messages is REQUIRED to perform Path
>    MTU Discovery and fragment the messages as needed.  The number of
>    records in a message MUST be limited by the MTU towards the RP