[pim] Ketan Talaulikar's Discuss on draft-ietf-pim-sr-p2mp-p olicy-19: (with DISCUSS and COMMENT)

Ketan Talaulikar has entered the following ballot position for
draft-ietf-pim-sr-p2mp-policy-19: 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-sr-p2mp-policy/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks to the authors and the WG for your work on this document.

This is an updated ballot for the v19 posted by the authors. Note that the
numbering of open points in the DISCUSS position is being retained as in the
original ballot for ease of tracking.

While the proposal is quite straightforward, it took me a few passes to grasp
the the information model of the different constructs introduced in this
document
 and their interrelationship. Perhaps it is because I am comparing it with
RFC9256 that specified the constructs for SR Policy.

I will attempt to describe the model based on my reading of the document, and
would appreciate if the authors can correct/clarify any errors in my
understanding. Please note some discussions points that I've brought up as part
of this description so as to provide a better context.

An SR P2MP Policy is a construct that represents a (set of?) P2MP trees in a
SR domain that can be used for delivery of P2MP service (i.e., multicast
traffic). Each SR P2MP Policy is identified by <Root, Tree-ID>.

An SR P2MP Policy can have one or more CPs where each provides constraints and
optimization objective for the computation of a specific tree topology from root
to leaves.

Each CP is identified by <Protocol Origin, Originator, Discriminator> which is
same as in the case of a SR Policy CP. Please see my comment on making this
explicit.

Each CP that is valid (i.e., for which a tree can be computed) has at least
one P2MP tree instance associated with it. There can be more than one instance
in cases like make-before-break (MBB). Within a SR P2MP Policy, each P2MP tree
instance is identified by an Instance-ID.

At any point, only one CP is active and this is selected based on the same
tie-breaking logic as for SR Policy CPs.

All the constructs until this point are instantiated only on the root node
(not considering the controller for now).

Now, we switch to RFC9524 that specified Replication Segment which is
identified as <replication node id, replication-id>.

Note that per RFC9524 the replication-id is a variable length field and is not
actually specified in that document. This document actually specifies the
replication-id to be <Root, Tree-ID, Instance-ID>.

--
discuss #2 : The text in 2.3 that conveys this is not very clear (please see
the comments section for suggestions). It also makes me wonder if this document
should "update" RFC9524?

This remains open for discussion
--

The replication segment thus represents a unique per P2MP tree
context at each root, intermediate and leaf nodes of a specific P2MP tree
within the context of an SR P2MP Policy CP in the network.

--
discuss #3: This makes the section 3.2 of shared replication segments somewhat
confusing. That section seems to say that replication segment MAY be shared
across different P2MP tree instances and then says shared replication segment
MUST NOT be associated with an SR P2MP tree in v17. In v18, this text is
modified but the explanation is still not clear on how they are used for the
P2MP tree.

This remains open for discussion
--

The instantiation of these per P2MP tree replication segment constructs on the
root, intermediate and leaf nodes in the computed tree setup the forwarding
context in the network.

Now, the terminology section says that the terms 'P2MP tree instance' and
'P2MP tree' are used interchangeably.

--
discuss #4: Why can't the same consistent term 'P2MP tree' be used throughout
the document? Is there a subtle difference with the use of "instance" here?

In the updated version, can this text now be removed from section 1.1?
"This document uses terms P2MP tree instance and P2MP tree interchangeably."
--

Then we come to section 3 which specifies the P2MP tree construct in a way
that is disconnected with the SR P2MP Policy construct. Is it because the SR
P2MP Policy construct is something that only exists on the controller (see
discuss#1 above) ?

Then the replication segment and its replication SID constructs from RFC9524
are introduced within the P2MP Tree context.

--
discuss #6: Section 2.4 introduces the term Binding SID for SR P2MP Policy but
does not specify what it is. It says Tree-SID of the active CP SHOULD be used
as the BSID, but does not say what happens if that is not the case? Is there a
need to introduce BSID here and is it not sufficient to only use the Tree-SID
always in the context of SR P2MP Policy?

Note: In the updated text, the part of the BSID (which is constant), getting
swapped with the currently active Tree SID (which may be changing) is not
covered even though that was one of the points that came out during the
discussion on this topic. Wanted to cross-check that it was left out
intentionally. --

--
discuss #7: Sections 4.1, talks about allocation of Tree SID. However, it does
specify whether allocation is from the SRGB, SRLB, dynamic range, or any of
them (along with any recommendations). Same goes for the replication SIDs at
intermediate and leaf nodes. Please also note a detailed comment below about
section 4.1 and need for some text to indicate how these SIDs are managed across
multiple nodes and how conflicts/errors (e.g., due to unavailability) are
handled. I would expect that this impacts the order in which a controller
needs to provision and setup (as also update) the P2MP trees across the nodes
- perhaps starting from the leaves and building the tree until the root?

This is largely addressed in the updated text. However, the following text in
section 5.5 seems odd - did you mean "reporting this success"?

"A node SHOULD report a successful installation of a Replication segment.
The exact procedure for reporting this failure is outside the scope of this
document."
--


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to the authors for addressing all the comments in v19



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