[pim] Re: [Shepherding AD review] review of draft-ietf-pim-light-03

["Gunter van de Velde (Nokia)" <[e-mail]>]

No issue to keep in Normative and add into the downref register when good reason exists. (more red tape, but thats okay)

G/

-----Original Message-----
From: Hooman Bidgoli (Nokia) <[e-mail]> 
Sent: Monday, August 12, 2024 7:49 PM
To: Stig Venaas <[e-mail]>
Cc: Gunter van de Velde (Nokia) <[e-mail]>; [e-mail]; [e-mail]
Subject: RE: [pim] Re: [Shepherding AD review] review of draft-ietf-pim-light-03

Gunter 

What is your recommendation please? If we can keep the experimental RFC in normative reference that is my preference 

Thanks
Hooman

-----Original Message-----
From: Stig Venaas <[e-mail]> 
Sent: Friday, August 9, 2024 2:55 PM
To: Hooman Bidgoli (Nokia) <[e-mail]>
Cc: Gunter van de Velde (Nokia) <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [pim] Re: [Shepherding AD review] review of draft-ietf-pim-light-03


CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.



Hi Hooman and Gunter

I think it's useful to explain that pim light can work with PORT and how, and in this case I also think it needs to be a normative reference. Isn't it ok to have a down reference as long as we have a reasonable reason?

The pim light solution itself does not depend on PORT, so I think it can be Standards Track even if PORT isn't. It only affects section 3.5 that explicitly talks about PORT.

If we really need to avoid the down reference, I would rather the reference be made informational. But in that case I think 3.5 should be reworded slightly so that one doesn't need to understand PORT to understand the text.

Thanks,
Stig

On Fri, Aug 9, 2024 at 11:24 AM Hooman Bidgoli (Nokia) <hooman.bidgoli=[e-mail]> wrote:
>
> Hi Gunter
>
>
>
> RFC 6559 is the PIM over Reliable Transport (PORT) which the section 3.5 of draft is addressing. So the reader needs to understand RFC6559 this is why I put it in Normative References. Personally I am ok with removing section 3.5  and saying that this draft doesn’t cover (PORT). But anyway if section 3.5 stays I guess we need RFC6559 in Normative References again if @[e-mail] and you agree I can move it to informative reference. Please let me know.
>
>
>
>
>
> draft-ietf-bier-pim-signaling, ok moved it.
>
>
>
> Duplication of RFC 2119 and RFC 8174, no idea what is happening here. Looking at some of the other RFCs they list them both under Normative references. Anyone?
>
>
>
> Thanks
>
> Hooman
>
>
>
>
>
>
>
>
>
> From: Gunter van de Velde (Nokia) <[e-mail]>
> Sent: Friday, August 9, 2024 4:06 AM
> To: Hooman Bidgoli (Nokia) <[e-mail]>; [e-mail]
> Subject: RE: Re: [pim] [Shepherding AD review] review of 
> draft-ietf-pim-light-03
>
>
>
> Hi Hooman,
>
>
>
> Many thanks for the swift actions.
>
>
>
> The draft is almost ready to go. One last sanity check when running 
> idnits tool, few messages are seen: a downref and a duplicate ref 
> (which i am confused about why it is shown)
>
>
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth
> or-tools.ietf.org%2Fapi%2Fidnits%3Furl%3Dhttps%3A%2F%2Fwww.ietf.org%2F
> archive%2Fid%2Fdraft-ietf-pim-light-05.txt&data=05%7C02%7Chooman.bidgo
> li%40nokia.com%7Cb4a87e620ef64ae381b908dcb8a4c8d1%7C5d4717519675428d91
> 7b70f44f9630b0%7C0%7C0%7C638588265125986875%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
> C%7C%7C&sdata=p3%2BcCFGLbG3Cnp%2BGBa526na%2BjlIHqweIOlewyQvD0SE%3D&res
> erved=0
>
>
>
> Is the downref to an experimental needed for PIM light? If yes, we will need to add it to the downref register. (This is something PIM AD, IESG and RFC editor will process, hence no workload for the authors. However we do try to avoid downrefs if possible. If the reference would be used as an example, and not formal procedures it is an informational reference.
>
>
>
> In addition the Normative reference to “draft-ietf-bier-pim-signaling” seems to be better as Informational. I think it is only used in examples. If we make this Normative, then the PIM Light draft is fate sharing with draft-ietf-bier-pim-signaling which seems undesired and not required.
>
>
>
> Any thoughts about this few final aspects?
>
>
>
> G/
>
>
>
> From: Hooman Bidgoli (Nokia) <[e-mail]>
> Sent: Thursday, August 8, 2024 1:04 AM
> To: [e-mail]; Gunter van de Velde (Nokia) 
> <[e-mail]>
> Subject: Re: [pim] [Shepherding AD review] review of 
> draft-ietf-pim-light-03
>
>
>
> Hi Gunter
>
>
>
> Thanks for your review and comments. I uploaded a new version of the document.
>
>
>
> Some points/comments please
>
>
>
>
>
> RFC 7761, Section 4.3.1, outlines the PIM neighbor discovery mechanism using Hello messages. Section 4.5 specifies that if a router receives a Join/Prune message from an IP source address without having previously received a PIM Hello message from that source, the router SHOULD discard the Join/Prune message without further processing. This procedure ensures that only messages from authenticated PIM neighbors are processed, maintaining the integrity and reliability of the multicast routing infrastructure.
>
>
>
> HB> “This procedure ensures that only messages from authenticated PIM neighbors are processed, maintaining the integrity and reliability of the multicast routing infrastructure.”
> HB> I think you are misunderstanding the authenticated part. the hello messages can’t authenticate the neighbor without IPsec AH mode or an authentication protocols like HMAC. This is why RFC7761 section 4.5 is pointing to section 6.3 and eventually IPsec for authentication.
>
> HB> I am omitting this last bit of your suggestion and going with the original text.
>
>
>
>
>
> The following rewrite may be more clear for consumers of the document.
>
> The fact that with PIM Light there is processing of packets from an 
> unauthenticated neighbor seems as a serious security concern. This 
> shoul dbe mentioned as a concern and operational guidelines to reduce 
> the risk vector
>
>
>
> HB> again I think you are confusing authentication of a router to PIM hello adjacency. Authentication is done via IPsec or HMAC hash over the PIM hello packets and other packets including join/prunes. This authentication is possible with PIM Light as well as mentioned in the security section. Hello messages do not authenticate the router.
>
>
>
> 3.
>
> The existing IANA registery for "PIM Message Types" may not be sufficient for PIM Light and may need update.
>
> The existing table may need a new column, used explicit for PIM Light to show which of the PIM Message Types is supported.
>
> It would be to lock the Message types currently supported and allows a framework for the future, unless through WG consensus the expectation is never any message ar eto be supported for PLI?
>
>
>
> HB> I can’t see us supporting any new message for PLI in near future. As PLI only support join/prune message.
>
>
>
>
>
> _______________________________________________
> pim mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]