[pim] Mohamed Boucadair's No Objection on draft-ietf-pim-sr- p2mp-policy-15: (with COMMENT)

Mohamed Boucadair has entered the following ballot position for
draft-ietf-pim-sr-p2mp-policy-15: No Objection

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/



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

Hi Rishabh, Dan, Clarence, Hooman, and Jeffrey,

Thank you for the effort put into this specification, which leverages RFC9524
and RFC9256.

Please find some comments below:

# Check

Section 2 has the following:

   It is similar to SR Policy
   [RFC9256].  Like SR Policy, SR P2MP Policy has one or more Candidate
   Paths and uses same criteria to select the Active Candidate Path.

I’d like to check this as I’m not sure that all parameters are inherited. For
example, do we still have Discriminator for the P2MP case as well?

# Active instance of a Candidate Path?!

Section 2.3 says:
   The controller designates an active instance of a CP at the Root node
   of SR P2MP Policy by signalling this state through the protocol used
   to instantiate the Replication segment of the instance.

(1) What is meant by “an active instance of a CP”?

(2) How this behavior interacts with the tie-breaking rules?

As I’m there, please fix this: s/The controller/A controller

# Section 2.4

CURRENT:
   The Tree-SID of the active
   instance of the active Candidate Path SHOULD be used as the Binding
   SID of the SR P2MP Policy.

Why this is not MUST? (see also next comment)

# Steering behavior

CURRENT:
   The Root node can steer an incoming packet into a SR P2MP Policy in
   one of following methods:

   *  Local Policy-Based Routing: The Root node selects the active P2MP
      tree instance of the active Candidate Path of the SR P2MP Policy
      based on local policy.  The procedures to map an incoming packet
      to a SR P2MP Policy are out of scope of this document.

   *  Tree-SID Based Routing: The Binding SID (Tree-SID) in the incoming
      packet is used to map the packet to the appropriate P2MP tree
      instance.

(1) Should the behavior of the root node be part of the instructions received
from the controller?

(2) As discussed earlier in the document, there is room for a case where
BID!=Tree-SID. What is the expected behavior in such cases?

(3) s/Local Policy-Based Routing/Local Policy-Based forwarding and s/Tree-SID
Based Routing/Tree-SID Based forwarding

# Section 3.1

CURRENT:
   The Tree-SID SHOULD also
   serve as the Replication-SID for the Replication segments at
   intermediate Replication nodes and Leaf nodes.

Please provide the rationale for this one. What are the implications if this
SHOULD is not followed?

# Section 3.2

(1)

CURRENT:
   A shared Replication Segment SHOULD be identified using a Root-ID set
   to zero (0.0.0.0 for IPv4 and :: for IPv6) along with a Replication-
   ID that is unique within the context of the node where the
   Replication segment is instantiated.

Idem as previous point, why this isn’t a MUST? At least the rationale should be
called out.

(2)

CURRENT:
   However, a shared Replication segment MUST NOT be associated with an
   SR P2MP tree.

Does this apply even if this is shared only between a subset and not all
instances?

# Section 3.3

## Transport/Service Context

CURRENT:
   For multi-point services, the transport identifier which is the Tree-
   SID or Replication SID at a Leaf node is also associated with the
   service context because it is not always feasible to separate the
   transport and service context with efficient replication in core
   since a) multi-point services may have differing sets of end-points,
   and b) downstream allocation of service context cannot be encoded in
   packets replicated in the core.

I guess I understand what is meant here by these contexts, but it would be
better to introduce these first.

## Deployment matter?

CURRENT:
   However, for SR-MPLS deployments, if it is known a priori that multi-
   point services mapped to a P2MP tree can be uniquely identified
   within the SR domain, a controller MAY opt not to instantiate
   Replication Segments at Leaf nodes.

How is that made known to the controller? Also, shouldn’t this better handled
by a policy?

# Section 4.2

CURRENT:
   A controller performs the following functions in general:

   *  Topology Discovery: A controller discovers network topology across
      Interior Gateway Protocol (IGP) areas, levels or Autonomous
      Systems (ASs).

   *  Capability Exchange: A controller discovers a node's capability to
      participate in SR P2MP tree as well as advertise it’s capability
      to compute P2MP trees.

It also need to retrieve installed tree instances in the underly domain when it
first bootstraps.

# Section 4.3

## Loops

CURRENT:
   A controller MUST compute a P2MP tree such that there are no loops in
   the tree at steady state as required by [RFC9524]).

I guess this should be conditional: IF the controllers computes a tree, then it
must be forwarding loop-free.

(nit) delete the extra “)”.

## Policy-based

CURRENT:
   A controller SHOULD modify a P2MP tree of a Candidate Path on
   detecting a change in the network topology or in case a better path
   can be found based on the new network state.  In this case, the
   controller MAY create a new instance of a P2MP tree and remove the
   old instance of the tree from the network in order to minimize
   traffic loss.

The SHOULD is scoped vaguely. No every topology change will trigger a
modification of the tree.

Also, I guess some policy is needed to drive the controller behavior for
migrating to a new path/instance.

# Section 4.5.2

CURRENT:
   It is possible for a controller create a disjoint backup tree
   instance for providing end-to-end path protection.

Well, this depends on the underlying topology.

Not sure this statement (even if adjusted) adds much to the discussion.

# Additional Operational Considerations

I was expecting some discussion about scalability matters and how to test an
active CP.

Please consider adding some discussion about these. Adding readily-available
pointers (if any) would work as well. Thanks

# Minor points

## Abstract

(1) Circular definition

CURRENT :
   A SR P2MP Policy consists of Candidate Paths (CP) which
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   define the topology of P2MP tree instances in each Candidate Path.
   ^^^^^^                                     ^^^^^^^^^^^^^^^^^^^^^^

(2) (nit) s/Paths and and how P2MP trees/Paths and how P2MP trees

## Introduction

(1) Cite an authoritative reference

CURRENT:
   A Multi-point service delivery can be realized with P2MP trees in a
   Segment Routing domain.
   ^^^^^^^^^^^^^^^^^^^^^^

(2) There might be multiple roots

OLD:
   A controller computes P2MP tree instances, from the Root to Leaf
   nodes,

NEW:
   A controller computes P2MP tree instances, from a Root to Leaf
   nodes,

(3) nit

OLD: Once computed, the controller instantiate a P2MP tree instance
NEW: OLD: Once computed, the controller instantiates a P2MP tree instance

(4) Missing references

CURRENT:
   The Replication segments of a P2MP tree can be instantiated for both
   SR-MPLS and SRv6 dataplanes, enabling efficient packet replication
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   within an SR domain.

## Section 2.2: point the reader to Section 4 where these matters are zoomed
into

OLD: A SR P2MP Policy is provisioned on a controller.

NEW: An SR P2MP Policy is provisioned on a controller (see Section 4).

## Section 2.3

CURRENT:
   The Root
   node selects the active Candidate Path based on the tie breaking
   rules defined in [RFC9256].
                 ^^^^^^^^^^^^

Please add the exact section to look at.

## Section 4

OLD:
   A controller is provisioned with SR P2MP Policy and it's Candidate
                                                       ^^^^^^
   Paths to compute and instantiate P2MP trees in SR domain.  Once
                                               ^^^^^^^^^^^^
   computed, the controller instantiates the Replication segments that
   compose the P2MP in the SR domain nodes using signalling protocols
   such as PCEP, BGP, NetConf etc.  The procedures for provisioning a
                      ^^^^^^^^^^^^
   controller and the instantiation Replication segments in SR domain
                                  ^^^^                   ^^^^^^^^
   are outside the scope of this document.

NEW:
   A controller is provisioned with SR P2MP Policy and its Candidate
   Paths to compute and instantiate P2MP trees in an SR domain.  Once
   computed, the controller instantiates the Replication segments that
   compose the P2MP in the SR domain nodes using signalling protocols
   such as PCEP, BGP, NETCONF, etc.  The procedures for provisioning a
   controller and the instantiation of Replication segments in an SR domain
   are outside the scope of this document.

## Section 4.2

s/ASs/ASes
s/it’s capability/its capability

## Appendix

Replication SIDs formatted as SRv6 Segment Identifier (SID). The textual
representation of those has to adhere to RFC 5952, especially this part:

   The characters "a", "b", "c", "d", "e", and "f" in an IPv6 address
   MUST be represented in lowercase.

Cheers,
Med



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