Re: [pim] Robert Wilton's Discuss on draft-ietf-pim-null-register-packing-14: (with DISCUSS and COMMENT)

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

Hi Robert, Alvaro:

Thanks for reviewing the document..

For the DISCUSS comment below:

(1) p 3, sec 3.  PIM Packed Null-Register message format

      0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |PIM Ver| Type  |Subtype|  FB   |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Group Address[1]   (Encoded-Group format)                 |
      |     Source Address[1]  (Encoded-Unicast format)               |
      .                                                               .
      .                                                               .
      .                                                               .
      .                                                               .
      .     Group Address[N]                                          .
      |     Source Address[N]                                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Figure 2: PIM Packed Null-Register message format

I'm not familiar with PIM, but it wasn't clear to me how the receiver infers
how many addresses are in the message.  E.g., I note that the Join/Prune
Message Format contains a count "Num Groups", but conversely the "Hello Message
Format" does not include a count of options.  Hence, I presume that the N, the
address count, is inferred by the packet length?  If so, would that be worth
stating here (and in section 4)?

AG >>
Yes, N is the total number of source-group pairs.
This draft's earlier versions had the count field in the header, but when we looked at it closely, it seemed like a redundant field. We removed it version #13 onwards.

Here is my related discussion/comment from prev emails:
"I think that the count field is not really required in the packet format - we would parse and obtain each record after the header, until the length of the message (inferred from the IP layer). Its presence leads to unnecessary checks and processing. Also, we don’t need the reserved field as well because we can use the Flag Bits for special purposes when the Type is PIM Packed Null-Register Type and/or PIM Packed Register-Stop.
       If it is not too late at this stage, and if we can proceed without these two fields, I can update the draft accordingly. I have the proposed draft ready as well."

Draft#15 Section 3 now has the following text:
“A record consists of a Group Address and Source Address pair. N, as indicated in Figures 2 and 3, is the total number of records. After the PIM common header is parsed, individual records are parsed one by one until the length of the PIM Packed Null-Register message. This length is inferred from the IP layer.”

Similar for Section #4.

Thanks, Alvaro for responding to rest of the comments #2, #3, #4.

The new version should be available shortly.
Thanks,
Ananya

From: pim <[e-mail]> on behalf of Robert Wilton via Datatracker <[e-mail]>
Date: Monday, February 27, 2023 at 5:47 AM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: [pim] Robert Wilton's Discuss on draft-ietf-pim-null-register-packing-14: (with DISCUSS and COMMENT)
Robert Wilton has entered the following ballot position for
draft-ietf-pim-null-register-packing-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pim-null-register-packing/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi,

Thanks for this document.  I've flagged this as discuss because I found part of
the spec to by unclear:

(1) p 3, sec 3.  PIM Packed Null-Register message format

      0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |PIM Ver| Type  |Subtype|  FB   |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Group Address[1]   (Encoded-Group format)                 |
      |     Source Address[1]  (Encoded-Unicast format)               |
      .                                                               .
      .                                                               .
      .                                                               .
      .                                                               .
      .     Group Address[N]                                          .
      |     Source Address[N]                                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Figure 2: PIM Packed Null-Register message format

I'm not familiar with PIM, but it wasn't clear to me how the receiver infers
how many addresses are in the message.  E.g., I note that the Join/Prune
Message Format contains a count "Num Groups", but conversely the "Hello Message
Format" does not include a count of options.  Hence, I presume that the N, the
address count, is inferred by the packet length?  If so, would that be worth
stating here (and in section 4)?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Minor level comments:

(2) p 2, sec 2.  Packed Null-Register Packing Capability

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |PIM Ver| Type  |P|6 5 4 3 2 1 0|           Checksum            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |             Group Address (Encoded-Group format)              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Source Address (Encoded-Unicast format)            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Figure 1: PIM Register-Stop message with Packing Capability option

I found the description of the flag bits to be unclear:
 - Are the "6 5 .. 1 0", the flag bits?
 - Is 'P' the "Packed Capability" bit?  If so, this diagram implies that it
 takes the value 7, but the text indicates that it hasn't been permanently
 assigned yet.

(3) p 3, sec 3.  PIM Packed Null-Register message format

      0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |PIM Ver| Type  |Subtype|  FB   |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Group Address[1]   (Encoded-Group format)                 |
      |     Source Address[1]  (Encoded-Unicast format)               |
      .                                                               .
      .                                                               .
      .                                                               .
      .                                                               .
      .     Group Address[N]                                          .
      |     Source Address[N]                                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Figure 2: PIM Packed Null-Register message format

Unclear what FB means, "Flag Bits"?  Also in section 4.

Nit level comments:

(4) p 4, sec 5.  Protocol operation

                                                             However, it
      is RECOMMENDED to stick to the packed format as long as the RP and
      DR have the feature enabled.

As an editorial nit, I would suggest combining these two sentences together to
make it clear what "the decision" is referring to.  The same comment also
applies to the pragraph below.

Regards,
Rob



_______________________________________________
pim mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pim