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

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

Hi Alvaro

Sorry I completely missed this email until I saw Mike’s email today pointing to this email

I uploaded version 7 of the draft so you can see the changes. Please go through the response below and provide feedback as you see fit.

Inline HB>

Thanks
Hooman


From: Alvaro Retana <[e-mail]>
Sent: Wednesday, June 19, 2024 2:31 PM
To: [e-mail]; Michael McBride <[e-mail]>
Cc: [e-mail]
Subject: [pim] Re: 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.


Hi!

I'm not opposed to advancing this draft, but it still needs some work -- see comments in-line below.

My main concern is that there is no specification contained in the document.  Instead, this sentence appears in §3.1: "This draft reuses most procedures for mLDP in RFC [RFC6425]"

It is not clear from the text which procedures from rfc6425 are reused and which are not.  Specifically, rfc6425 didn't deal with SR, so the procedures specified there, even if similar, are different.  It should be clear in this document how the procedures in rfc6425 relate to the new functionality and which don't apply.

I am sure the people working on the existing implementation (and the authors) know exactly what the sentence in §3.1 means, but I doubt that an interoperable implementation can be coded just from the text in this document.

HB> thanks, as you know RFC 6425 is common procedures for P2MP RSVP-TE and Multicast LDP. The only specific section for the two is section 3.1.1 where the identification of P2MP LSP is done and 3.2.1 where  egress Address P2MP responder sub-tlv  is only for P2MP RSVP-TE and multicast LDP.

HB> so how about the following text
HB> “This draft reuses procedures for mLDP in [RFC6425]. A P2MP policy and its corresponding Candidate Paths and path instances do not have a signaling layer and are setup manually via CLI or automatically via a controller. As an example, as per [RFC6425] section 3.2.1 just like Multicast LDP for each replication segment acting as LSR, there is no way to know the identity of the downstream leaf nodes. This draft will follow the Multicast LDP  procedures in section 3, 4, 5 and 6 with exception of section 3.1 which explains the procedures and TLVs needed to identify the LSP under test. The procedures to identify the LSP is explained in this draft. “

Thanks!

Alvaro.



[Line numbers from idnits.]

...
103  3.  Motivation

105    A P2MP Policy and its corresponding Replication Segments are usually
106    setup via a controller, the root and the leaves are discovered as per
107    [draft-ietf-pim-sr-p2mp-policy].  The tree is calculated from the
108    root to the leaves.  There is no underlay protocol to signal the P2MP
109    Policy from the root to the Leaf routers, as such when a P2MP tree
110    fails to deliver user traffic, the failure can be difficult to pin
111    point without a ping/traceroute mechanism to isolate the fault in the
112    P2MP tree.  The P2MP Policy ping/traceroute can be utilize to detect
113    faults on the path of the tree and its associated replication
114    segments [draft-ietf-spring-segment-routing-policy-13].  These tools
115    can be used to periodically ping the leaves to ensure connectivity.
116    If the ping fails, trace route can be initiated to determine where
117    the failure lies.  The ping/traceroute can be initiated from the node
118    that initiates the P2MP policy.

[minor] "The P2MP Policy ping/traceroute can be utilize to detect faults on the path of the tree and its associated replication segments [draft-ietf-spring-segment-routing-policy-13]."

draft-ietf-spring-segment-routing-policy, now RFC9256, doesn't talk about replication segments.  Is that the intended reference?

HB> Thanks! Good catch! It should use RFC9524.

...
161  3.2.1.  Identifying a P2MP Policy

163    [RFC8029] defines a simple and efficient mechanism to detect data-
164    plane failures in Multiprotocol Label Switching (MPLS) Label Switched
165    Paths (LSPs).  In order to identify the correct replication segment
166    for the CP and its PI, the echo request message MUST carry an
167    Identifier TLV for the Candidate path and the Path instance that is
168    under test.  This draft defines a new sub-TLV: a P2MP policy MPLS
169    Candidate Path sub-TLV.  The new sub-TLV is assigned Sub-Type
170    identifiers (TBD), and is described in the following sections.

[major] "MUST carry an Identifier TLV for the Candidate path and the Path instance that is under test"

At first, I assumed you were referring to the "P2MP Responder Identifier TLV" [rfc6425].  But it later (in the IANA section!) became clear that you're talking about the Target FEC Stack TLV.  Please be specific.

HB> ok updated.


172    artwork

[nit] "artwork" is present in two places and should be removed.


HB> done

...
177  3.2.1.1.  P2MP Policy CP FEC Stack Sub-TLVs

179    The format of the P2MP Policy MPLS Candidate Path sub-TLV value field
180    is specified in the following figure.  The value fields are taken
181    from the definitions of the P2MP Policy section 3 of
182    [draft-ietf-pim-sr-p2mp-policy]

[nit] s/section 3/Section 2

HB> done

...
198    *  Address Family: Two-octet quantity, containing a value from
199       ADDRESS FAMILY NUMBERS in [IANA-AF] that encodes the address
200       family for the Root Address.

[major] There's no reference to "IANA-AF".

HB> done

202    *  Address Length: Length of the Root Address in octets, IPv4 or
203       IPv6.

[major] The length is not "IPv4 or IPv6".  It is "4 for IPv4 or 16 for IPv6".

HB> thanks done.

[minor] What if the value is not 4 or 16?  I couldn't what to do after a quick glance at rfc6425/rfc8029.

HB> I didn’t take an action here, I guess we can add a paragraph that says we need to drop the packet, but again I don’t want to have new procedures in this draft compare to RFC6425.

205    *  Root Address: The address of Root node of P2MP tree instantiated
206       by the SR P2MP Policy

208    *  Tree-ID: A identifier that is unique in context of the Root.  This
209       is an unsigned 32-bit number.

211    *  Instance-ID: 32 bit value to identify the Path-Instance ID
212       [draft-ietf-pim-sr-p2mp-policy]

[major] Instead of copying definitions, use references.

For example, the text above says that the "fields are taken from the definitions...[in]...[draft-ietf-pim-sr-p2mp-policy]".  But the term is "Root" (not Root Address).

Also, Instance-ID is defined as "the identifier of an instance of a Candidate Path", and "Path-Instance ID" is not mentioned at all in draft-ietf-pim-sr-p2mp-policy.

HB> yes we need to make some changes to the P2MP policy
We will change the P2MP policy draft to something like this. “Instance-ID is the identifier of an Path Instance within the Candidate Path. A Candidate Path can have multiple Path Instances for global optimization.”


...
261  5.  IANA Consideration
...
270    41: P2MP Policy MPLS Candidate Path

s/TBD/41/g

HB> sorry not following this, 41 was already assigned as a temporary value for this draft.

272  6.  Security Considerations

274    Overall, the security needs for P2MP policy ping is same as
275    [RFC8029].  The P2MP policy ping is susceptible to the same three
276    attack vectors as explained in RFC8029 section 5.  The same
277    procedures and RECOMMENDATIONS explained in RFC8029 section 5 should
278    be taken and implemented to mitigate these attack vectors for P2MP
279    policy Ping as well.

[] s/RECOMMENDATIONS/recommendations

HB> thanks

...
297  8.2.  Informative References

299    [draft-ietf-pim-sr-p2mp-policy]
300               "D. Yoyer, C. Filsfils, R.Prekh, H.bidgoli, Z. Zhang,
301               "draft-ietf-pim-sr-p2mp-policy"", October 2019.

[major] This reference should be Normative because the contents of the new sub-TLV are taken from it.

HB> done

...
307    [RFC6425]  "S. Saxena, G. Swallow, Z. Ali, A. Farrel, S. Yasukawa,
308               T.Nadeau "Detecting Data-Plane Failures in Point-to-
309               Multipoint MPLS"", November 2011.

[major] This reference has to be Normative because the procedures used here come from it.

HB> ok done

311    [RFC7942]  "S. Saxena, G. Swallow, Z. Ali, A. Farrel, S. Yasukawa,
312               T.Nadeau "Detecting Data-Plane Failures in Point-to-
313               Multipoint MPLS"", July 2016.

[major] The information about this reference is wrong.

HB> I removed this all together since this paragraph will be removed anyway.

[EoR-05]


On June 7, 2024 at 10:44:21 PM, Michael McBride ([e-mail]<mailto:[e-mail]>) wrote:
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
_______________________________________________
pim mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>