[spring] Re: wglc: draft-ietf-pim-p2mp-policy-ping

["Hooman Bidgoli (Nokia)" <[e-mail]>]

Hi Andrew

Much appreciate your comments!

Inline

Regards
Hooman

From: Andrew Stone (Nokia) <andrew.stone=[e-mail]>
Sent: Tuesday, June 18, 2024 5:13 PM
To: Jorge Rabadan (Nokia) <jorge.rabadan=[e-mail]>; Michael McBride <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: [spring] Re: wglc: draft-ietf-pim-p2mp-policy-ping

Hi PIM,

I've reviewed the latest version and support its progression. The document is a fairly straight forward read extending on the existing P2MP architecture documents and leverages the existing p2mp mpls ping capabilities in an SR way in a clean way.

Authors, some minor text comments/suggestions below.

Thanks
Andrew



Section 3 - it says the ping/traceroute can be initiated from the node that initiates the P2MP Policy. Would it more clear to just say "From the root of the P2MP Policy"?
HB> I am not sure if the P2MP policy is always the root, in the case of Nokia implementation a P2MP policy is the root, you are correct, but I know other vendors can stitch a unicast policy from a root to a P2MP policy on a transit router. As an example even the candidate path on the router that is initiating the P2MP policy can have a incoming SID for its replication segment . In this case the ping or traceroute should work from the P2MP policy segment onward.
Section 3.1 - /packet are/packets are/
HB> thank you will change this.
Section 3.1 /appropriate respond is send/appropriate response is sent/
HB> thank you will correct this.
Section 3.1 "trace route" and others have "Traceroute" - suggest one or the other
HB> thanks!
Section 3.1 - " On the egress node the corresponding CP and its PI should respond irrespective if it is the active CP or a backup CP."

Seems this statement iis intermixing a few terms that can be misinterpreted depending on the perspective due to the CP, backup CP, and PI active terms. The term "egress" was throwing me off a bit as well. My understanding is the purpose of the text is to indicate the following:

- Every transit and leaf node along the path which has a path instance, those instances are installed, and SHOULD process and respond to ping/traceroute even if that path instance is not active.
- At the root, you may originate a ping/traceroute on the CP even if it is a backup CP. The downstream replication segments installed are independent and follow the previous bullet point.

Therefore would the following text be clearer summary of this?:

"Upon reception of a P2MP Ping/Traceroute, every PI installed on every node SHOULD process and respond to ping/traceroute even if not the active PI"
HB> I understand the confusion will rework the text. Thanks!

HB> will update the new version with the above changes by Friday.

From: Jorge Rabadan (Nokia) <jorge.rabadan=[e-mail]<mailto:jorge.rabadan=[e-mail]>>
Date: Friday, June 14, 2024 at 1:49 AM
To: Michael McBride <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [pim] Re: wglc: draft-ietf-pim-p2mp-policy-ping
Hi,

I went through the document and I think it is ready.
It’s an important draft and has implementations, so I support its publication.

Thanks,
Jorge

From: Michael McBride <[e-mail]<mailto:[e-mail]>>
Date: Friday, June 7, 2024 at 7:44 PM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [pim] wglc: draft-ietf-pim-p2mp-policy-ping

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.


Hello,

Today begins a 2 week wglc for https://datatracker.ietf.org/doc/draft-ietf-pim-p2mp-policy-ping/. Please give it a review and let us know if you think it’s ready for advancement.

thanks,
mike