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

[Alvaro Retana <[e-mail]>]

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.

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?



...
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.



172   artwork

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



...
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



...
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".



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".


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



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.



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

s/TBD/41/g



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



...
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.



...
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.



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.

[EoR-05]

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