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. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
