RE: Opsdir last call review of draft-ietf-pim-reserved-bits-03

["Susan Hares" <[e-mail]>]

Alvaro: 

 

See comments below.    

 

You have hit a rabbit hole in the testing of the 

pim specifications that I’ve hit when I was in charge 

of running code.

 

I am providing you feedback on how to close the rabbit hole. 

 

Sue 

 

From: Alvaro Retana [mailto:[e-mail]] 
Sent: Monday, September 16, 2019 12:57 PM
To: Susan Hares; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: Opsdir last call review of draft-ietf-pim-reserved-bits-03

 

On September 13, 2019 at 12:08:47 PM, Susan Hares via Datatracker ([e-mail]) wrote:

 

[Author hat on.]

 

Sue:

 

Hi!  Thanks for the review!

 

...

Issue: Issue/Error in document 
However, this document does not specify the error handling if a PIM implementation does 
not abid by the MUSTs in section 4 defined as follows:  

Unless otherwise specified, all the Flag Bits for each PIM type are 
Reserved [RFC8126]. They MUST be set to zero on transmission, and 
they MUST be ignored upon receipt. The specification of a new PIM 
type, MUST indicate whether the bits should be treated differently. 

This issues becomes a serious issue if it negates any error handling or changes 
any existing error handling. 

I suspect this is not really a serious issue, but a flaw in the write-up. 
I suspect that because you set to zero on transmission, and 
ignored on receipt you will not engage in any error handling. 

However, it is necessary to state that so that machines testing 
the PIM and SM-PIM protocols will easily add this to their testing suite.  

 

Alvaro ‘s comment: 

Ø  The Flag Bits are currently Reserved in rfc7761, which describes the field as: "Set to zero on transmission.  Ignored upon receipt.”  

Ø  IOW, the behavior doesn’t change at all…really just the name of the field and the per-type applicability.

Ø  I’m not sure what you would like to see added, given that there is no change in the behavior specified in rfc7761.  Can you suggest something?

What RFC 7761 states is :
Reserved: Set to zero on transmission.  Ignored upon receipt.

My comment on improving these specification: 

Ø  What happens if the implementations sends ones. Is it compliant or not?

Ø  Or should the protocols tester test this point.   

Ø  RFC7761 does not specify this point. 

If you are revising this specification, please consider stating something definite about this point.  I’ve hit this point on the PIM testing my code on the PIM specification. My feedback is fix it please.   I was not suggesting this in the text for the specification, but as manageability text for operations to suggest testing sequence.   Or perhaps you have a reference to some specification that states this type of advice.   

Remember - this was an OPS-DIR review.   

------------------------------
2) [RFC7761] and {RFC3973], but bogus error handling (depending how you do #1) 
may impact the security considerations. 

Ø  If someone sends random non-zero bits, it should not crash the router.  

Ø   

--------------------------

3) Minor Issue: Should Section 3 include a change to RFC3973 - section 4.7.1 

No.  PIM-DM (rfc3973) uses the packet formats (including the Header of course, §4.7.1) defined by PIM-SM…from §4.7: "All PIM-DM packets use the same format as PIM-SM packets.  In the event of a discrepancy, PIM-SM [4] should be considered the definitive specification.”  The reference is to rfc2362, the PIM-DM spec at the time, which has now been replaced by rfc7761

Ø  This logic should convince you it is hard to track down the complete state of rfc3973. 

Ø  However, BGP has some of these issues.  It’s a minor point. 

.Thanks!

Alvaro.