Hi Hooman,
Apologies for the delay to follow-up as I was out of office.
My comment was that root-id is not defined in the based spec and what you are referring to is simply the Root.
I checked your latest version and see that this was fixed: " A PTI is identified on the Root node by the PTI's ...".
Thank you.
Cheers,
Med
> -----Message d'origine-----
> De : Hooman Bidgoli (Nokia)
> <[email protected]>
> Envoyé : vendredi 8 août 2025 22:57
> À : BOUCADAIR Mohamed INNOV/NET <[email protected]>;
> Hooman Bidgoli (Nokia)
> <[email protected]>; The IESG
> <[email protected]>
> Cc : [email protected]; pim-
> [email protected]; [email protected]; [email protected]
> Objet : RE: Mohamed Boucadair's No Objection on draft-ietf-pim-
> p2mp-policy-ping-15: (with COMMENT)
>
>
> Hi Med
>
> Sorry I am not following this comment
>
> The root-id is defined at the beginning
>
> "A TI is identified on the Root node by the Root-ID which is the
> Root's node IP address, treeID and TI's instance ID."
>
> Thanks
> Hooman
>
> -----Original Message-----
> From: [email protected] <[email protected]>
> Sent: Thursday, August 7, 2025 3:35 AM
> To: Hooman Bidgoli (Nokia)
> <[email protected]>; The IESG
> <[email protected]>
> Cc: [email protected]; [email protected];
> [email protected]; [email protected]
> Subject: RE: Mohamed Boucadair's No Objection on draft-ietf-pim-
> p2mp-policy-ping-15: (with COMMENT)
>
> Hi Hooman,
>
> Thanks for the follow-up and the changes made in -16.
>
> There is one pending comment, but I trust this impacts draft-ietf-
> pim-sr-p2mp-policy. Please see inline.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Hooman Bidgoli (Nokia)
> > <[email protected]>
> > Envoyé : mercredi 6 août 2025 21:44
> > À : BOUCADAIR Mohamed INNOV/NET <[email protected]>;
> The
> > IESG <[email protected]> Cc : draft-ietf-pim-p2mp-policy-
> [email protected];
> > [email protected]; [email protected]; [email protected] Objet :
> RE:
> > Mohamed Boucadair's No Objection on draft-ietf-pim-p2mp-
> > policy-ping-15: (with COMMENT)
> >
> >
> > Hi Mohamed
> >
> > Thanks for taking time reading the document and your comments,
> some
> > good catches!
> >
> > Inline
> >
> > Thanks
> > Hooman
> >
> > -----Original Message-----
> > From: Mohamed Boucadair via Datatracker <[email protected]>
> > Sent: Wednesday, August 6, 2025 6:48 AM
> > To: The IESG <[email protected]>
> > Cc: [email protected]; pim-
> [email protected];
> > [email protected]; [email protected]; [email protected]
> > Subject: Mohamed Boucadair's No Objection on draft-ietf-pim-
> p2mp-
> > policy-ping-15: (with COMMENT)
> >
> >
> > 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.
> >
> >
> >
> > Mohamed Boucadair has entered the following ballot position for
> > draft-ietf-pim-p2mp-policy-ping-15: No Objection
> >
> > 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.)
> >
> >
> > ----------------------------------------------------------------
> ----
> > --
> > COMMENT:
> > ----------------------------------------------------------------
> ----
> > --
> >
> > Hi Hooman, Zafar, Jeffrey, Anuj, and Dan,
> >
> > Thank you for the effort put into this document.
> >
> > Also, thanks to Linda Dunbar for the OPSDIR. I'm not reiterating
> any
> > of the points raised by Linda. I trust that agreed changes will
> be
> > made to the spec to reflect the ongoing discussion.
> >
> > Having some examples to illustrate the use of the extensions
> would be
> > helpful.
> >
> > Please find below some comments; major ones are tagged with (*).
> >
> > # Candidate Policy (*)
> >
> > The following is not consistent with the definition of CP:
> >
> > OLD: Each P2MP Policy can have multiple Candidate Paths (CPs).
> >
> > Please consider updating to
> >
> > NEW: A P2MP Policy can have one or multiple Candidate Paths
> (CPs).
> >
> > HB> thanks done.
> >
> > # Inappropriate use of normative language
> >
> > CURRENT:
> > The CP
> > with highest preference is designated as the active CP, while
> all
> > other CPs are the backup CPs. To enable seamless global
> > optimization
> > a CP MAY consist of multiple Path Instances (PIs),
> >
> > Please s/MAY/may
> >
> > HB> thanks done
> >
> > # Root, Root-ID, rootID (*)
> >
> > This document uses rootID, which deviates from draft-ietf-pim-
> sr-
> > p2mp-policy.
> >
> > draft-ietf-pim-sr-p2mp-policy says:
> >
> > A SR P2MP Policy is uniquely identified by the tuple <Root,
> Tree-
> > ID>,
> > where:
> >
> > * Root: The IP address of the Root node of P2MP trees
> instantiated
> > by the SR P2MP Policy. This is equivalent to the Headend
> of SR
> > Policy identifier tuple.
> >
> > + have one instance of Root-ID
> >
> > A shared Replication Segment SHOULD be identified using a
> Root-ID
> > set
> > to zero (0.0.0.0 for IPv4 and :: for IPv6) along with a
> > Replication-
> >
> > (1) I guess this is an issue to be fixed in draft-ietf-pim-sr-
> p2mp-
> > policy.
> >
>
> [Med] Root-ID is used without being defined; only Root is.
>
> > (2) Both specs have to be consistent. Please fix that.
> >
> > HB> changed to Root-ID
> >
> > # Deviation vs base P2MP SR Policy Spec
> >
> > OLD:
> > A PI is identified on the Root node by the rootID
> > which is the Root's node IP address, tree ID and PI's
> instance ID.
> >
> > NEW:
> > A PI is identified on the Root node by the Root-ID
> > which is the Root's node IP address, Tree-ID and PI's
> Instance- ID.
> >
> > HB> ok done thanks
> >
> > # Deviation, again
> >
> > CURRENT:
> > [draft-ietf-pim-sr-p2mp-policy] section 2, defines terms and
> > concepts
> > specific to SR P2MP Policy including the CP and the PI.
> >
> > There is no PI thing there :-(
> >
> > HB> good point! tree Instance and path instance are the same.
> > Talking to other co-authors we change all drafts to tree
> instance
> > (TI)! Thanks again!
> >
> > # Remind behavior
> >
> > CURRENT:
> > Consequently, these Sub-TLVs SHOULD NOT be used when an
> echo
> > request carries a P2MP Policy MPLS Candidate Path FEC.
> >
> > Can we remind in the text what happens if these were included?
> >
> > HB> ok added a sentence
> >
> > # Concretely
> >
> > CURRENT:
> > P2MP SR Policies SHOULD adhere to the common procedures
> specified
> > in
> > [RFC6425] for P2MP MPLS LSPs.
> >
> > What does "adhere" concretely means?
> >
> > HB> changed to "follow"
> >
> > # Problematic MUSTs
> >
> > CURRENT:
> > The Ping and Traceroute packets MUST be forwarded along
> > the specified CP and its PI, traversing the associated
> Replication
> > Segments. When a downstream node receives a Ping or
> Traceroute
> > packet, it MUST process the request and generate a response
> even if
> > the CP and its PI are not currently the active path.
> >
> > These two absolute MUSTs may be problematic as there are
> conditions
> > where this should not be the case. A typical example, is when
> there is
> > a rate-limit in place to protect a node against overload/DDoS,
> etc.
> >
> > I would adjust these two accordingly.
> >
> > HB> ok remassaged
> >
> > # Inappropriate use of normative language
> >
> > CURRENT:
> > For
> > example, when a P2MP Policy Ping or Traceroute packet between
> two
> > Replication Segment is transiting over a Unicast SR domain,
> it MUST
> > be only processed on Replication Segments, based on the
> Replication
> > SID and its TTL value.
> >
> > This is an example. Please s/MUST/must
> >
> > HB> done
> >
> > # Replication ID TTL (*)
> >
> > CURRENT:
> > The SR domain itself SHOULD be treated as a
> > single hop, meaning that the Replication SID TTL MUST be
> > decremented
> > by one before pushing the Unicast SR SIDs onto the
> Replication SID
> > stack.
> >
> > (1) Under which condition the SHOULD can be ignored?
> >
> > (2) I failed to find where "Replication SID TTL" is defined. Can
> you
> > please clarify that? Thanks.
> >
> >
> > HB> Replication SID is a label so the TTL is the label TTL
> >
> > # Address Family (*)
> >
> > CURRENT:
> > * Address Family: (2 octets) containing a value from ADDRESS
> > FAMILY
> > NUMBERS in [IANA-AF] , indicating the address family of
> the Root
> > Address.
> >
> > (1) Shouldn't this be restricted to IPv4/IPv6?
> >
> > (2) There is no "Root Address" field. Root is defined in the
> base spec
> > as an address. Please update accordingly.
> >
> > HB> ok updated.
> >
> > # Please find below some minor comments
> >
> > HB> ok thanks considered some of your suggestions including
> title
> > for version 16
> >
> >
> > ## Better title that reflect the content
> >
> > OLD: P2MP Policy Ping
> > NEW: Segment Routing Point-to-Multipoint (P2MP) Policy Ping
> >
> > ## Abstract
> >
> > OLD:
> > Segment Routing Point-to-Multipoint (SR-P2MP) Policies are
> used to
> > define and manage explicit P2MP paths within a network.
> These
> > ^^^^^^^^
> > policies are typically calculated via a controller-based
> mechanism
> > and installed via a Path Computation Element (PCE). In other
> cases
> > ^^^^^^^^^^^^
> > these policies can be installed manually via using YANG
> models or
> > CLI.
> > ^^^^^^^^^^^^^^^^^^
> > They are used to steer multicast traffic along optimized
> paths from
> > a
> > Root to a set of Leaf routers.
> >
> > This document defines extensions to Ping and Traceroute
> mechanisms
> > for SR-P2MP Policy with MPLS encapsulation to provide OAM
> > (Operations, Administration, and Maintenance) capabilities.
> The
> > proposed extensions enable operators to verify connectivity,
> > diagnose
> > ^^^^^^^^
> > failures and troubleshoot forwarding issues within P2MP
> Policy
> > multicast trees.
> >
> > NEW:
> > Segment Routing Point-to-Multipoint (SR-P2MP) Policies are
> used to
> > define and manage explicit P2MP paths within an SR domain.
> These
> > policies are typically calculated via a controller-based
> mechanism
> > and installed via, e.g., a Path Computation Element (PCE).
> In
> > other cases
> > these policies can be installed via using NETCONF/YANG or
> CLI.
> > They are used to steer multicast traffic along optimized
> paths from
> > a
> > Root to a set of Leaf routers.
> >
> > This document defines extensions to Ping and Traceroute
> mechanisms
> > for SR-P2MP Policy with MPLS encapsulation to provide OAM
> > (Operations, Administration, and Maintenance) capabilities.
> The
> > extensions enable operators to verify connectivity, diagnose
> > failures and troubleshoot forwarding issues within P2MP
> Policy
> > multicast trees.
> >
> > ## Introduction
> >
> > OLD:
> > This specification applies exclusively to Replication
> Segments
> > (Replication SIDs) that use MPLS encapsulation for forwarding
> and
> > ^^^^^^^^^^^^^^^^
> > does not cover Segment Routing over IPv6 (SRv6). The
> mechanisms
> > described herein build upon the concepts established in
> [RFC6425]
> > for
> > P2MP MPLS Operations, Administration, and Maintenance (OAM).
> All
> > consideration and limitations described in section 6 of
> [RFC6425]
> > ^^^^^^
> > applies apply to this document as well.
> > ^^^^^^
> >
> > NEW:
> > This specification applies exclusively to Replication
> Segments
> > (Replication-SIDs) that use MPLS encapsulation for forwarding
> and
> > does not cover Segment Routing over IPv6 (SRv6). The
> mechanisms
> > described herein build upon the concepts established in
> [RFC6425]
> > for
> > P2MP MPLS Operations, Administration, and Maintenance (OAM).
> All
> > considerations and limitations described in section 6 of
> [RFC6425]
> > apply to this document as well.
> >
> > ## Section 3
> >
> > OLD:
> > A P2MP Policy and its corresponding Replication Segments are
> > typically provisioned via a centralized controller or
> configured
> > statically using YANG models or CLI.
> > ^^^^^^^^^^^^^^^^^^^^
> >
> > NEW:
> > A P2MP Policy and its corresponding Replication Segments are
> > typically provisioned via a centralized controller or
> configured
> > using NETCONF/YANG or CLI.
> >
> > ## Section 3.1
> >
> > Which mechanisms extend 8029?
> >
> > CURRENT:
> > The procedures in [RFC6425] define fault detection and
> isolation
> > mechanisms for P2MP MPLS LSPs. These mechanisms extend the
> LSP
> > ping
> > techniques described in [RFC8029] such that they may be
> applied to
> > P2MP MPLS LSPs, ensuring alignment with existing fault
> management
> > tools.
> >
> > Cheers,
> > Med
> >
> >
>
> __________________________________________________________________
> __________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi que les pieces jointes. Les messages electroniques
> etant susceptibles d'alteration, Orange decline toute
> responsabilite si ce message a ete altere, deforme ou falsifie.
> Merci.
>
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should
> not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender
> and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that
> have been modified, changed or falsified.
> Thank you.
>
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_______________________________________________
pim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.