[pim] Re: Ketan Talaulikar's Discuss on draft-ietf-pim-p2m p-policy-ping-18: (with DISCUSS and COMMENT)

Hi Hooman,

This looks great. I'll clear my DISCUSS position once the update is posted.

Thanks again for your (and your co-authors) patience through these
discussions. I hope it has helped improve the document.

Thanks,
Ketan


On Fri, Sep 5, 2025 at 4:00 AM Hooman Bidgoli (Nokia) <
[email protected]> wrote:

> By the way here is the Diff. If you are ok I will upload it
>
>
>
>
>
>
>
> *From:* Hooman Bidgoli (Nokia) <[email protected]>
> *Sent:* Thursday, September 4, 2025 5:19 PM
> *To:* Ketan Talaulikar <[email protected]>
> *Cc:* Rishabh Parekh (editor) <[email protected]>; The IESG <
> [email protected]>; [email protected];
> [email protected]; [email protected]; [email protected]
> *Subject:* RE: Ketan Talaulikar's Discuss on
> draft-ietf-pim-p2mp-policy-ping-18: (with DISCUSS and COMMENT)
>
>
>
> Hi Ketan
>
>
>
> Inline HB>
>
>
>
> Thanks
>
> Hooman
>
>
>
>
>
> *From:* Ketan Talaulikar <[email protected]>
> *Sent:* Thursday, September 4, 2025 1:15 AM
> *To:* Hooman Bidgoli (Nokia) <[email protected]>
> *Cc:* Rishabh Parekh (editor) <[email protected]>; The IESG <
> [email protected]>; [email protected];
> [email protected]; [email protected]; [email protected]
> *Subject:* Re: Ketan Talaulikar's Discuss on
> draft-ietf-pim-p2mp-policy-ping-18: (with DISCUSS and 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.
>
>
>
> Hi Hooman,
>
>
>
> Thanks for your quick response and update. While the updates clear the
> first of the two DISCUSS points, there are some further changes required to
> clear the second one.
>
>
>
> The section 3.1.3 title needs to be updated. Suggestion -
>
> s/Considerations for Interworking with Unicast SR Domains/Considerations
>
> for P2MP Trees with Unicast Paths
>
>
>
> HB> thanks done.
>
>
>
> In the body of the section 3.1.3, it would help to convey that the two
> ways to build the P2MP Tree and here can put a reference to
> https://www.ietf.org/archive/id/draft-ietf-pim-sr-p2mp-policy-20.html#appendix-A
> and perhaps use the terms adjacent/non-adjacent to describe the two ways to
> build the tree. Then convey that with adjacent replication segments, the
> operations there are no special considerations for the TTL/Hop Limit
> propagation - i.e., Uniform mode has to be used.
>
>
>
> HB> ok I added this, that said I did not used Uniform, as uniform is
> really for the case of TTL propagation from one label to the other.
>
>
>
> However, for the trees built using non-adjacent replication segments,
> there are these unicast paths between the replication segments that require
> the use of the PIPE mode.
>
>
>
> HB> as we agreed for trace route we need to set it to pipe mode, but for
> ping it is an implementation choice between uniform mode and pipe mode,
> changed the paragraph to be more precise. Thanks
>
>
>
>
>
> As discussed during the meeting yesterday, this clarity on the two ways to
> build the trees and the considerations for each of them should be covered
> here.
>
>
>
> There was also the AI (taken by Rishabh?) to cross-check and confirm if
> anything is needed for SRv6 or if it is covered in the pseudocode of the
> base SR P2MP policy draft. If the authors want to add these details for
> SR-MPLS as well in the base SR P2MP Policy draft instead of in the ping
> document, then that is OK as well (ping document can simply reference it).
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> On Thu, Sep 4, 2025 at 8:27 AM Hooman Bidgoli (Nokia) <
> [email protected]> wrote:
>
> Hello
>
>
>
> Version 21 of the draft was posted based on today’s conversation.
>
>
>
> Thanks
>
> Hooman
>
>
>
> *From:* Hooman Bidgoli (Nokia) <[email protected]>
> *Sent:* Monday, August 25, 2025 8:13 AM
> *To:* Ketan Talaulikar <[email protected]>; Rishabh Parekh (editor) <
> [email protected]>
> *Cc:* The IESG <[email protected]>; [email protected];
> [email protected]; [email protected]; [email protected]
> *Subject:* RE: Ketan Talaulikar's Discuss on
> draft-ietf-pim-p2mp-policy-ping-18: (with DISCUSS and COMMENT)
>
>
>
> HI Keta
>
>
>
> I think we should have one meeting with @Rishabh Parekh (editor)
> <[email protected]> for both (Ping and P2MP Policy) document to conclude.
>
>
>
> Thanks
>
> Hooman
>
>
>
> *From:* Ketan Talaulikar <[email protected]>
> *Sent:* Monday, August 25, 2025 5:12 AM
> *To:* Hooman Bidgoli (Nokia) <[email protected]>
> *Cc:* The IESG <[email protected]>; [email protected];
> [email protected]; [email protected]; [email protected]
> *Subject:* Re: Ketan Talaulikar's Discuss on
> draft-ietf-pim-p2mp-policy-ping-18: (with DISCUSS and 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.
>
>
>
> Hi Hooman,
>
>
>
> Thanks for posting the updated version. I've revised the ballot to remove
> the points that have been closed.
>
>
>
> Please check a few points where this document does not seem to be in sync
> with the base. If you would like to discuss between the authors of these
> two documents and post an update, then please do so.
>
>
>
> For the open items, we'll discuss over a call (I will schedule it).
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> On Mon, Aug 25, 2025 at 7:22 AM Hooman Bidgoli (Nokia) <
> [email protected]> wrote:
>
> Uploaded version 19
>
>
>
> Hooman
>
>
>
> *From:* Ketan Talaulikar <[email protected]>
> *Sent:* Friday, August 22, 2025 8:01 AM
> *To:* Hooman Bidgoli (Nokia) <[email protected]>
> *Cc:* The IESG <[email protected]>; [email protected];
> [email protected]; [email protected]; [email protected]
> *Subject:* Re: Ketan Talaulikar's Discuss on
> draft-ietf-pim-p2mp-policy-ping-18: (with DISCUSS and 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.
>
>
>
> Hi Hooman,
>
>
>
> Thanks for the continued discussion. Please check inline for follow-ups
> with KT2.
>
>
>
> At this point, I think it would be great if you (and your co-authors)
> could post an update with the changes discussed and agreed so far. This way
> we can focus on the outstanding points alone. I am asking the same for the
> base SR P2MP Policy document as well - this way can ensure that both are in
> sync and consistent.
>
>
>
> Note: My responses may be slow next week.
>
>
>
>
>
> On Fri, Aug 22, 2025 at 4:09 AM Hooman Bidgoli (Nokia) <
> [email protected]> wrote:
>
> Hi Ketan
>
>
>
> Inline HB2>
>
> Addressing your major concerns
>
>
>
> Thank
>
>
>
> *From:* Ketan Talaulikar <[email protected]>
> *Sent:* Thursday, August 21, 2025 3:25 AM
> *To:* Hooman Bidgoli (Nokia) <[email protected]>
> *Cc:* The IESG <[email protected]>; [email protected];
> [email protected]; [email protected]; [email protected]
> *Subject:* Re: Ketan Talaulikar's Discuss on
> draft-ietf-pim-p2mp-policy-ping-18: (with DISCUSS and 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.
>
>
>
> Hi Hooman,
>
>
>
> Thanks for your quick response. Please check inline below for
> clarifications.
>
>
>
>
>
> On Wed, Aug 20, 2025 at 11:23 PM Hooman Bidgoli (Nokia) <
> [email protected]> wrote:
>
> Hi Ketan
>
> Thanks for your comments
>
> Inline
>
> Thanks
> Hooman
>
>
> -----Original Message-----
> From: Ketan Talaulikar via Datatracker <[email protected]>
> Sent: Wednesday, August 20, 2025 7:00 AM
> To: The IESG <[email protected]>
> Cc: [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]
> Subject: Ketan Talaulikar's Discuss on draft-ietf-pim-p2mp-policy-ping-18:
> (with DISCUSS and 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.
>
>
>
> Ketan Talaulikar has entered the following ballot position for
> draft-ietf-pim-p2mp-policy-ping-18: Discuss
>
> 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.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-pim-p2mp-policy-ping/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thanks to the authors and the WG for their work on this document.
>
> I have a few points that I would like to discuss with the authors and the
> WG.
>
> discuss#1 This one should be easy to fix. Since the document is about MPLS
> and not SRv6, the correct title for this document would be "Segment Routing
> MPLS Point-to-Multipoint (P2MP) Policy Ping" ?
>
> HB> sorry I am not following, as per draft this doc only addresses the
> MPLS encapsulation and not the SRv6. SRv6 will be in future documents.
>
>
>
> KT> Can you change the title of the draft from "Segment Routing
> Point-to-Multipoint (P2MP) Policy Ping" to "Segment Routing MPLS
> Point-to-Multipoint (P2MP) Policy Ping" or better still "LSP Ping for
> Segment Routing Point-to-Multipoint (P2MP) Policy" ?
>
>
>
>  HB2> ok done thanks
>
>
>
>
> discuss#2 This is related to a point of discussion that I've also raised
> on the p2mp policy document. It arises from the lack of clarity on whether
> the SR P2MP Policy construct is instantiated on the root node or not. There
> is text in section 3.1.1 which seems to leave this critical aspect to
> implementations and will result in interoperability problems. The base spec
> needs to be very clear on this point and then this document updated to
> reflect it. I believe having the construct instantiated in the root will
> greatly benefit and simplify OAM operations. And things would then become
> very similar to RSVP-TE P2MP trees?
>
> Quoting some text from section 3.1.1 that is problematic:
>
> "Only the Root node, where the P2MP SR Policy is programmed, may have
> visibility  into the leaf nodes."
>
> "In the case of P2MP SR Policies, the Root of the tree may have full
> visibility into the egress nodes if the P2MP SR Policy is PCC-initiated. If
> the P2MP SR Policy is PCE-initiated, the Root may or may not have
> visibility into the egress  nodes, as this depends on the specific
> implementation and configuration of the PCE. "
>
> Further dependencies like the following seem unnecessary:
>
> "Based on this, a P2MP SR Policy SHOULD follow the recommendations in
> Section
> 4.3.1 of [RFC6425], depending on the level of visibility the Root has into
> the  egress nodes. For example, in a PCC-initiated P2MP SR Policy, the Root
> can learn egress node identities through Next-Generation MVPN procedures
> and BGP, as described in [RFC6514]. In contrast, for a PCE-initiated P2MP
> SR Policy, the PCE may not provide the egress node information to the Root,
> making this process optional and implementation-specific."
>
> The lack of clarity hurts interoperability and would affect operations in
> a multi-vendor network. I would like to discuss why all of this cannot be
> simplified by ensuring that the SR P2MP Policy construct is instantiated on
> the root node.
>
> HB> Thanks but I think this is clearly been explained in the introduction,
> as per below paragraph. I clearly says P2MP Policy finest object is a TI
> which is the actual P2MP tunnel setup from the "Root" to a set of leaves.
>
>
>
> KT> And I see issues with that approach.
>
>
>
>
> "A P2MP Policy can have one or multiple Candidate Paths (CPs). 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 Tree Instances (TIs), allowing for Make-Before-Break (MBB)
> procedures between an active TI and a newly established, optimized TI. A TI
> is the actual P2MP tunnel set up from the Root to a set of Leaves via
> transit routers. 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."
>
> discuss#3 My understanding is that the P2MP MPLS trees that are setup by
> MLDP or RSVP-TE are hop by hop in nature. While in this case, the packet
> can travel multiple hops from one node to the next intermediate node using
> that next intermediate node's Prefix SID.
>
> HB> That is not correct, a P2MP MPLS tree for mLDP, P2MP RSVP-TE or
> treeSID is signalled from the root to the a let of leaves. There is no
> difference on the datapath between mLDP, P2MP RSVP-TE or treeSID. They all
> use MPLS switching to forward a multicast stream from the root to a set of
> leaves.
>
>
>
> KT> MLDP and RSVP-TE P2MP are signalled hop-by-hop through the network and
> as such the state for the P2MP LSP is present in all hops/routers along the
> path. While the SR P2MP tree is provisioned on specific (intermediate)
> nodes in the network and, therefore, there can be transit routers which do
> not have any state for the SR P2MP Tree. Am I correct about this
> fundamental difference?
>
>
>
> HB2> that is not the case, it is exactly like mLDP and RSVP-TE P2MP. If
> there is a replication segment there needs to be a state. That said like
> mLDP where 2 mLDP routers can tunnel over unicast RSVP-TE in some segments
> of the network, treeSID can also tunnel over a unicast tunnel including SR
> Policy, SR-TE etc… but the replication SID needs to be at the bottom of the
> stack so when the unicast labels are popped at the destination the
> downstream replication router can take action based on the replication SID.
>
>
>
> KT2> Perhaps it is better if we discuss this over a call? Next week is
> tough for me, but I'll reach out with some suitable slots.
>
>
>
>
>
>
>
>
> In this case, how would operation like traceroute (or even errors in the
> case of ping) work when the packet is exposed at a node that is doing
> unicast forwarding and has no replication segment context for that specific
> P2MP Tree? Now, section 3.1.3 is covering this, but talking about it as
> "unicast SR domains" is very misleading since there is only an SR domain
> and it is just that the specific P2MP tree context is not required to be
> instantiated on a transit node. Does this mean that this mechanism works
> only when the P2MP Tree is setup up hop-by-hop? If so, this should be
> clearly called out as a caveat upfront and the text in 3.1.3 updated
> appropriately.
>
> HB> the replication SID is at the bottom of the stack, so a transit node
> that is capable of treeSID can push adjacency SID or node SID of another
> treeSID router that is multi-hop away. As such 2 treeSID capable routers
> can be connected via a unicast SR domain, i.e. treeSID tunnel over Unicast
> SR tunnel (tunnel over tunnel). Only the treeSID routers will decrement the
> treeSID TLL and make appropriate decisions if the TLL has expired. This
> tunnel in tunnel concept is nothing new to treeSID and it is the concept of
> segment routing which treeSID is part of.
>
>
>
> KT> The concept of "unicast SR domain" as you describe above is
> misleading. Consider a single SR domain and all routers have SR P2MP
> capabilities. While the root, intermediate and leaf nodes have state for a
> specific SR P2MP tree, the other transit routers don't have that specific
> SR P2MP tree state. There isn't a tunnel per se (it's a stack of labels)
> that is going multi-hop across these transit routers, but even if one were
> to call it a tunnel then it is going to break the OAM procedures - or at
> least they are no longer the same as existing P2MP LSPs. I am OK if this is
> called out as a caveat of this proposal and operational guidance provided
> to avoid multi-hop such that all replication branches for every replication
> segment are just going single hop.
>
>
>
> HB2> Sure I can call out this draft does not address the case when a SR
> P2MP OAM packet is traversing a unicast portion of the SR domain. i.e. if
> the corresponding unicast labels TTLs value expires while the label stack
> contains a replication SID is not covered by this draft.
>
>
>
> KT2> I have a problem with the characterization of "unicast portion".
> While this is an improvement over "Unicast SR domain", it does not address
> my point. Can we take this over a call ?
>
>
>
>
>
>
> discuss#4 This is an easy one to fix - the following is not a normative
> reference, please move to informative.
>
> [IANA-AF]
> "IANA Assigned Port Numbers, "
> http://www.iana.org/assignments/address-family-numbers"".
>
> HB> ok thanks done in version 19.
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Please also find below some comments provided inline in the idnits format
> of the v18 of this document. On all editorial and minor comments, I will
> leave it to the authors discretion. On the major ones, I would appreciate
> responses and clarifications.
>
> Please look for <EoRv18> at the end of this review and if it is not there,
> then likely the email has gotten truncated by your client (please refer to
> the mailing list in that case).
>
> 94      1.  Introduction
>
> 96         A P2MP Policy can have one or multiple Candidate Paths (CPs).
> The CP
>
> <minor> Please align terminologies with the SR P2MP policy draft. Term is
> SR P2MP Policy, then there is P2MP Tree (Instance), etc. Would be nice to
> avoid introducing new terms (e.g., TI) in this document related to any of
> the constructs.
>
> HB> ok thanks, changed to p2mp policy and p2mp tree instance
>
> 97         with highest preference is designated as the active CP, while
> all
> 98         other CPs are the backup CPs.  To enable seamless global
> optimization
>
> <minor> The CP preference is only the first tiebreaker in the selection of
> active CP. Perhaps "One of the CPs (e.g., with highest preference) is
> designated ..."
> HB> this might be implementation specific. In the SR p2mp policy the
> candidate path with highest preference is the active CP.
>
>
>
> KT> This isn't implementation specific. The SR P2MP Policy draft says that
> it is following RFC9256 (see
> https://www.ietf.org/archive/id/draft-ietf-pim-sr-p2mp-policy-18.html#section-2.3)
> - is there a disconnect? This is one of my comments on the SR P2MP Policy
> draft - to provide more clarity.
>
>
>
> The Root node selects the active Candidate Path based on the tie breaking
> rules defined in[RFC9256
> <https://www.ietf.org/archive/id/draft-ietf-pim-sr-p2mp-policy-18.html#RFC9256>
> ].
>
>
>
> HB2> I see, I’ll change the text to point to pim-sr-p2mp-policy for CP
> selection, thanks.
>
>
>
> KT2> Sure, or you can consider the text that I had suggested - "One of the
> CPs (e.g., with highest preference) is designated ..."
>
>
>
>
>
>
> 131        [draft-ietf-pim-sr-p2mp-policy] section 2, defines terms and
> concepts
> 132        specific to SR P2MP Policy including the CP and the TI.
>
> <minor> I couldn't find TI defined in that document. Please introduce in
> the base.
>
> HB> it is introduced in the introduction
> "To enable seamless global optimization a CP may consist of multiple P2MP
> Tree Instances (TIs), allowing for Make-Before-Break (MBB) procedures
> between an active TI and a newly established, optimized TI."
>
>
>
> KT> Please introduce architectural constructs in the architectural spec
> (i.e. the SR P2MP Policy draft) where it can be references by all protocol
> specs - this LSP Ping is one document, but I would expect it to be used in
> PCEP as well as perhaps in the YANG model.
>
>
>
>
> 142     3.  Motivation
>
> 144        A P2MP Policy and its corresponding Replication Segments are
> 145        typically provisioned via a centralized controller or configured
> 146        using NETCONF/YANG or CLI.  The root and the leaves are
> discovered in
>
> <minor> Perhaps you mean that the network topology that includes the root
> and leaves is discovered?
>
> HB> no, the controller sucks up the topology but the controller initiates
> the P2MP policy and its replication segments on the root, transit and leaf
> nodes.
>
>
>
> KT> What is there to be discovered about these nodes by the controller?
> Aren't they provisioned by the controller? My comment is that the choice of
> the word "discovered" is odd and unclear. Please clarify.
>
>
>
>
> 161        This diagnostic process can be initiated from the node
> responsible
> 162        for establishing the P2MP Policy, ensuring proactive monitoring
> and
> 163        rapid fault detection.
>
> <minor> Is use of "rapid" appropriate here? Rapid as in BFD?
>
> HB> There are cases and implementations, that rapid pings are send for
> fault detection.
>
>
>
> KT> Let me ask the question if the spec is going to suffer if "rapid" were
> to be removed. Or can you find a reference to an existing LSP Ping spec
> that talks about "rapid pings"? Implementations are free to make their own
> choices but we need to get consensus from MPLS WG if this document is
> introducing the concept of "rapid pings".
>
>
>
> HB2> I don’t understand this comment sorry. Rapid is implementation, if
> you send one ping or one ping a second or 1000 ping a second that is up to
> your implementation.
>
> HB2> that said knowing this implementation I have no issue removing the
> word “rapid”
>
>
>
> KT2> If you can remove the word rapid, then we please consider this point
> closed. If you would like to discuss further, we can take this up as well
> over a call?
>
>
>
>
>
>
> 295     3.2.1.1.  P2MP Policy CP FEC Stack Sub-TLVs
>
> 297        The P2MP Policy MPLS Candidate Path sub-TLV value field follows
> the
>
> <major> Please consider changing the name of this TLV since it is not
> about CP but about the P2MP Tree instance under a CP. Perhaps "SR P2MP
> Policy Tree FEC Stack sub-TLV" ... or something similar. I was trying to
> not make it too long by including the CP in there, but that would also be
> ok.
>
> HB> It is actually detecting fault on a CP. A CP can have single TI or
> multiple TI. Hence why we choose the CP as part of the name.
>
>
>
> KT> But as you say above, it is monitoring the TI under the CP and more
> importantly the FEC specifies a unique TI and not the CP. i.e. if the CP
> has multiple TI then each TI needs a separate LSP Ping session with its
> unique FEC.
>
>
>
> HB2> This is early allocation in IANA changing the name might be
> difficult. That said my next response might satisfy your concern.
>
>
>
> KT2> There is no issue with changing the TLV names until the final
> allocation and RFC publication.
>
>
>
>
>
>
>
> 298        format specified in Section 2 of
> [draft-ietf-pim-sr-p2mp-policy].
> 299        The structure of this sub-TLV is illustrated in the figure
> below.
>
> <major> Please add text to clarify here that the CP identifiers are not
> required since the Instance-ID is unique within the SR P2MP Policy context
> (with a reference to section 2.3 of the p2mp policy draft).
>
> HB> There is no CP identifier in any text or document. Adding this would
> create more confusion and have the reader searching for what is a CP
> identifier.
>
>
>
> KT> This looks like a disconnect. Refer
> https://www.ietf.org/archive/id/draft-ietf-pim-sr-p2mp-policy-18.html#section-2.3
> .. and this is why I've provided comments on the SR P2MP policy document to
> clarify some of those things inline.
>
>
>
> An SR P2MP Policy has one or more CPs. Identification of a CP in context
> of the P2MP Policy is as specified in Section 2.9 of [RFC9256
> <https://www.ietf.org/archive/id/draft-ietf-pim-sr-p2mp-policy-18.html#RFC9256>
> ].
>
>
>
> HB2> I can add a text to say that this sub-TLV is testing a P2MP Tree
> Instance as such it is not necessary to identify the candidate path.
>
> HB2> hopefully this will solve your concern with regards to the sub-tlv
> name as well.
>
>
>
> KT2> Yes, that text would help. Do still consider the change of sub-TLV
> name though - IANA doesn't have an issue with that - so the question is for
> the authors/WG really.
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
>
> 315        *  Address Family: (2 octets) IPv4/IPv6 ADDRESS FAMILY NUMBERS
> as
> 316           specified in [IANA-AF] , indicating the address family of the
> 317           Root.
>
> <major> Are all AFIs allowed? I believe it has to allow only IPv4 or IPv6?
>
> HB> as per text "Address Family: (2 octets) IPv4/IPv6 ADDRESS FAMILY
> NUMBERS as specified in"
>
>
>
> KT> Could you be more specific and disallow AFI values other than 1 and 2
> in the text?
>
>
>
> HB2> ok done thanks.
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
> 319        *  Address Length: (1 octet) specifying the length of the Root
> 320           Address in octets (4 octets for IPv4, 16 octets for IPv6).
>
> <major> reserved is missing; also I believe it MBZ
> HB> good point thanks!
>
> 382     5.  IANA Consideration
>
> 384        IANA has assigned a TEMPORARY code point for the "P2MP Policy
> MPLS
> 385        Candidate Path" Sub-TLV Name.  This Sub-TLV is assigned from
> TLV type
> 386        1 (Target FEC Stack) from the "Multi-Protocol Label Switching
> (MPLS)
> 387        Label Switched Paths (LSPs) Ping Parameters" registry group.
> The
> 388        Sub-TLVs for TLV type 1 are listen under "Sub-TLVs for TLV
> Types 1,
>
> <minor> s/listen/listed
>
> HB> thanks! Updated.
>
> 397     6.  Security Considerations
>
> 399        Overall, the security needs for P2MP policy ping are the same as
> 400        [RFC8029].  The P2MP policy ping is susceptible to the same
> three
> 401        attack vectors as explained in RFC8029 section 5.  The same
> 402        procedures and recommendations explained in [RFC8029] section 5
> 403        should be taken and implemented to mitigate these attack
> vectors for
> 404        P2MP policy Ping as well.
>
> <major> Should this not include reference to the security considerations
> of the SR P2MP policy draft as well?
>
> HB> ok thanks added a text
>
> <EoRv18>
>
>

_______________________________________________
pim mailing list -- [email protected]
To unsubscribe send an email to [email protected]