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

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

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.


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

Thanks to the authors for addressing all the comments raised.



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