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

[Rishabh Parekh <[e-mail]>]

Bruno,
Replies inline

> ---
>
> "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)
>
>
If the downstream node is directly connected, we don't need a unicast
segment or SR policy to reach that node, just an interface to that
node is sufficient.

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

By "logical" we mean the Replication segment is not a topological
construct (like a node or a link).  I am proposing the following text
to clarify that it is a local segment instantiated at the Replication
and Downstream nodes.

"In a Segment Routing Domain, a Replication segment is a logical
construct which connects a Replication Node to a set of Downstream
Nodes. A Replication segment is a local segment instantiated at the
Replication node and and MAY be instantiated at Downstream nodes. It
can be either provisioned locally on a node or programmed by a PCE. "


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

As you suggest, we will try to simplify this in the next revision.
Below is proposed text (that also incorporates the response to first
comment):

"A Downstream Node is represented by a SID-list or a Segment Routing
Policy that specifies the explicit path from the Replication Node to
the Downstream Node, or even represented by another Replication
segment. The SID-list MAY just have one SID. If a downstream node is
adjacent to a Replication node, it MAY also be represented by an
interface."


>
> -----
>
> "  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."
>
>
We are proposing this text:

"At a Replication node, the Replication SID SHOULD be considered to be
the equivalent of Binding SID of a Segment Routing Policy.". The text
about "Downstream Node" has been to another paragraph in same section
where we describe NEXT operation.


>
> -------
>
> " 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..
>
>
The CONTINUE operation just captures the label swap for each
replication, with just the Downstream Replication SID in the simplest
case.

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

The description of PUSH, CONTINUE and NEXT operation was introduced in
version 02 as a result of discussions with Sasha and other WG members
in this thread:
https://mailarchive.ietf.org/arch/browse/spring/?q=The%20SPRING%20WG%20has%20placed%20draft-voyer-spring-sr-replication-segment%20in%20state%20.
IMO, the processing of a packet as it traverses a Replication Segment
is specified by these operations and should be part of the draft.



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

We do have an approach for SRv6 Replication. After adoption, we were
going to poll the WG to see if SRv6 content can be incorporated in
this draft or in a separate document. However, we do want to retain
minimal text about SRv6 in the draft since this Replication construct
applies to SRv6 also.