Subject: [pim] review of draft-ietf-pim-null-register-packing-06

From: Leonard Giuliano <[email-masked]>
Date: Wed, 16 Dec 2020 12:54:52 -0800

I reviewed the Null-Register packing draft and found it to be a 
well-written, concise and clear doc specifying a very simple optimization. 
Very much appreciate the brevity of this doc.  A few very minor (mostly 
editorial) nits, plus one question:

-sect2, 1st para, last sentence: "when it learns RP is capable"
 	-learns the RP

-sect8, last sentence: "the number of records should be limited to the MTU 
of the outgoing interface."
 	-might be more appropriate to say "limited by the MTU"

-sect9, 2nd para, last sentence: "these messages are not required for 
PIM-SSM."
 	-'required' implies they could be optionally used in SSM, so it 
might be better to say "these messages are not used in PIM-SSM."

-sect9, 3rd para, 1st sentence: "case where a spoof Register can be sent"
 	-"spoofed Register message"

-sect9, 3rd para, 2nd sentence: "This can cause Null-Registers to not be 
received by the RP."
 	-might be better to say "This can cause packed Null-Registers to 
be sent to an RP that doesnt support this packed format."

-sect9, 3rd para, 3rd sentence: consider revising this sentence.  Maybe 
something like "For example, uRPF can be used to filter spoofed packets."

-Sect6: this recommendation seems equally applicable to Anycast RP with 
MSDP for the same reasons as it is being recommended for Anycast RP with 
PIM.

Substantive question: could there ever be a case where an RP might need to 
send Register-stops for only a subset of the s-g pairs that were in the 
packet null-register message?  I couldn't think of a reason, but thought 
I'd ask.

-Lenny

---

From: Leonard Giuliano <[email-masked]>
Date: Tue, 22 Dec 2020 13:04:10 -0800

One more item after seeing Abhishek's coments that warrants clarification:

-Sect 7: Last 2 sentences of this para refer to "unpacked PIM Register" 
messages.  I assumed these were referring to data-encapped PIM register 
messages, not Null-Registers.  Is my assumption correct?  If not, I think 
the doc should consistently specify "Null-Registers" when referring to 
Register messages without encapped data, and "Register messages" (without 
the "Null" before it) should always be assumed to have data-encap.

-Lenny

On Wed, 16 Dec 2020, Leonard Giuliano wrote:

| 
| I reviewed the Null-Register packing draft and found it to be a well-written,
| concise and clear doc specifying a very simple optimization. Very much
| appreciate the brevity of this doc.  A few very minor (mostly editorial) nits,
| plus one question:
| 
| -sect2, 1st para, last sentence: "when it learns RP is capable"
| 	-learns the RP
| 
| -sect8, last sentence: "the number of records should be limited to the MTU of
| the outgoing interface."
| 	-might be more appropriate to say "limited by the MTU"
| 
| -sect9, 2nd para, last sentence: "these messages are not required for
| PIM-SSM."
| 	-'required' implies they could be optionally used in SSM, so it might
| be better to say "these messages are not used in PIM-SSM."
| 
| -sect9, 3rd para, 1st sentence: "case where a spoof Register can be sent"
| 	-"spoofed Register message"
| 
| 
| -sect9, 3rd para, 2nd sentence: "This can cause Null-Registers to not be
| received by the RP."
| 	-might be better to say "This can cause packed Null-Registers to be
| sent to an RP that doesnt support this packed format."
| 
| -sect9, 3rd para, 3rd sentence: consider revising this sentence.  Maybe
| something like "For example, uRPF can be used to filter spoofed packets."
| 
| -Sect6: this recommendation seems equally applicable to Anycast RP with MSDP
| for the same reasons as it is being recommended for Anycast RP with PIM.
| 
| Substantive question: could there ever be a case where an RP might need to
| send Register-stops for only a subset of the s-g pairs that were in the packet
| null-register message?  I couldn't think of a reason, but thought I'd ask.
| 
| -Lenny
|