[pim] Ketan Talaulikar's Discuss on draft-ietf-pim-p2mp-poli cy-ping-18: (with DISCUSS and COMMENT)

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

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.

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

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


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

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

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.


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?


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?

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.


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


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?


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

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

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?

<EoRv18>



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