[spring] draft-voyer-spring-sr-replication-segment-03

[[e-mail]]

Hi,

As an individual contributor, please find below some proposed comments.

Thanks,
Regards,
Bruno

---
"A SR Replication segment allows a packet to be replicated from a replication node to downstream nodes."
May be adding "Each downstream node is reached by using a unicast segment or SR policy."
(otherwise, the building of a multicast tree seem possibly within the scope)

-----
"a Replication segment is a logical segment"
- I'm not sure what you mean by "logical".
- My understanding is that the replication is a local segment as per RFC8402. i.e. it is instantiated on one single node. Can you make this clear in the document?

-----

"A Downstream Node could be
   represented by the node's Node SID (i.e. it does not matter how
   traffic gets to the Downstream Node, whether it's directly connected
   or not), or in case of a directly connected node it could be
   represented by the Adjacency SID (for the interface connecting to the
   directly connected Leaf Node).  Alternatively, a Downstream Node
   could be represented by a SID-list or a Segment Routing Policy
   [I-D.ietf-spring-segment-routing-policy] that partially/fully
   specifies the explicit path from the Replication Node to the
   Downstream Node, or even represented by another Replication segment."

This definition uses only "could", "alternatively", "or even".
Would it be possible to phrase it to describe what _it is_ ?
On the list, Andrew proposed the following text "downstreamIngressReplicationSid and SID Path". Which may be could be phrased as: a unicast SR policy, (possibly) followed by a replication segment. And if you extend the SR-Policy to include the use of a Replication segment, may be specification of a branch could simply be 'one SR policy'.

-----
"  For the root of a Multi-point service, the Replication SID
   SHOULD be considered to be the equivalent of Binding SID
   [I-D.ietf-spring-segment-routing-policy] of a Segment Routing Policy.
   At a downstream node of the Multi-point service, the Replication SID
   MAY be used to identify that portion of the Multi-point service."

>From this text, it's not clear whether the replication SID/segment is a local segment, or a global segment, or something new to be defined.
Why not replacing the above text with
" the Replication SID
   SHOULD be considered to be the equivalent of Binding SID
   [I-D.ietf-spring-segment-routing-policy] of a Segment Routing Policy."

-------
" o  When the Active Segment [RFC8402] is the Replication SID.  In this
      case, the operation for a replicated copy is CONTINUE."

"CONTINUE" would mean that the segment is not a local segment.
So the document really needs to clarify whether the replication SID/segment is a local segment, or a global segment, or something new to be defined.

-----
"  o  On the root of a Multi-point service, based on local policy-based
      routing.  In this case, the operation for a replicated copy is
      PUSH."

Introduction states that the building of a tree (hence the root) is out of scope of this document.

Could the section 2 "Replication Segment" of this document be focused on the definition and specification of this local replication segment?

-----
"  If a Downstream Node is an egress (aka leaf) of the Multi-point
   service, i.e. no further replication is needed, then that leaf node's
   Replication segment will not have any Replication State and the
   operation is NEXT.  Notice that the segment on the leaf node is still
   referred to as a Replication segment for the purpose of
   generalization.

   A node can be a bud node, i.e. it is a replication node and a leaf
   node of a Multi-point service at the same time
   [I-D.voyer-pim-sr-p2mp-policy].  In this case, the Replication
   segment's Replication State includes a branch with the Downstream
   Node being itself and the operation for the replicated copy is NEXT."

same comment: Could the section 2 "Replication Segment" of this document be focused on the definition and specification of this local replication segment?

----
"Replication segments apply equally to both SR-MPLS and SRv6 instantiations of Segment Routing."

May be, but there are differences between both data planes and the draft does not talk about those differences.
e.g. for SR-MPLS, labels are local to a node (including labels of global segments). Hence it's not crystal clear to me if/how a segment/label can follow a replication segment. Because that label would be received by N nodes, which may understand it differently (different FEC). How is this handled? In essence, the situation is similar to the use of anycast SID. So this seems possible to handle it, but may be not trivial up to the point of not mentioning it. (some options are using upstream allocated labels with context forwarding tables, enforcing that all receivers use the same FEC for the label. cf the spring anycast draft)


e.g. for SRv6, the use of binding SID implies the use of new (another) IPv6 encapsulation [1]. So if N consecutive replication segments are used along the path, N IPv6 encapsulation are performed. I'm not seen a provision for performing the N de-encapsulations. How is this handled, on which node(s)?

[1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-16#section-5

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.