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

From: <[email-masked]>
Date: Wed, 8 Jul 2020 15:07:40 +0000

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.

---

From: Rishabh Parekh <[email-masked]>
Date: Wed, 8 Jul 2020 16:28:10 -0700

Bruno,
Replies inline

> (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.

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

> 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.…

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

>    [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.

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

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

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

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.

---

From: <[email-masked]>
Date: Wed, 15 Jul 2020 18:02:20 +0000

Rishabh,

Thanks for answers and new -04
Please see inline [Bruno]

Still speaking as an individual WG member.

> -----Original Message-----
> From: spring [mailto:[email-masked]] On Behalf Of Rishabh Parekh
> Sent: Thursday, July 9, 2020 1:28 AM
> To: DECRAENE Bruno TGI/OLN <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: [spring] draft-voyer-spring-sr-replication-segment-03
> 
> Bruno,
> Replies inline
> 
> > ---
> >

[Bruno] Agreed, in this specific case, you don't need the SID on the _packet_. 
- Still the PCE/configuration CLI/YANG need a way to identify this interface and it could be via a SID (e.g. both local adjacency SID and global nodes SID (assuming PHP) seems to work, depending on needs)
- It seems to me that SR Policy draft is in the same situation, and they still call this an SR Policy.
But that's a detail.
 
[...]
 
> > 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..
> >
> >

"CONTINUE: the active segment is not completed; hence, it remains
   active.  In SR-MPLS, the CONTINUE operation is implemented as a SWAP
   of the top label [RFC3031].  In SRv6, this is the plain IPv6
   forwarding action of a regular IPv6 packet according to its
   destination address."
https://tools.ietf.org/html/rfc8402#section-2

1) SR terminology
Given that I think that we agreed that the replication segment is a local segment (i.e. local to one node), I don't see how it could continue once used. As we used it on the single node which understand it, it needs to be terminated (NEXT).

2) Data plane
2.a) SR-MPLS
I don't see a label swap. I see a pop of the BSID/replication SID and a push of the list of SID in the SR-policy. As described in  https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-08#section-8.3
"Let us assume that headend H has a valid SR Policy P of Segment-List
   <S1, S2, S3> and BSID B.

   When H receives a packet K with label stack <B, L2, L3>, H pops B and
   pushes <S1, S2, S3> and forwards the resulting packet according to
   SID S1."

2.b) SRv6
Quoting RFC 8402 (above): "In SRv6, this is the plain IPv6
   forwarding action of a regular IPv6 packet according to its
   destination address"
I don't see how this can translate in a specific SR action (here "replication" on the replication node. ) But since there is no SRv6 specific text in the draft, it's hard to guess.

Note that my understanding seems to match your new text/illustration in appendix: there is no CONTINUE operation on a replication SID. Only NEXT operation:
" R2, as Leaf, performs NEXT operation, pops R-SID2 label and delivers the payload."
"R6, as Leaf, performs NEXT operation, pops R-SID1 label and delivers the payload." 
"R7, as Leaf, performs NEXT operation, pops R-SID7 label and delivers the payload."

BTW, there may be two typos in the draft:
"R6, as Leaf, performs NEXT operation, pops R-SID1 label and delivers the payload."
:s/R-SID1/R-SID6

OLD:    Replication State:
                R2: <R-SID1->L12>"

NEW:    Replication State:
                R2: <R-SID2, L12>"
 
Thanks,
Regards,
--Bruno

---

From: Rishabh Parekh <[email-masked]>
Date: Wed, 15 Jul 2020 14:04:49 -0700

Bruno,
Replies inline @ [RP]

> - Still the PCE/configuration CLI/YANG need a way to identify this
> interface and it could be via a SID (e.g. both local adjacency SID and
> global nodes SID (assuming PHP) seems to work, depending on needs)
> [RP] We are on the same page. An explicit interface can be identified in
different ways.

> Given that I think that we agreed that the replication segment is a local
> segment (i.e. local to one node), I don't see how it could continue once
> used. As we used it on the single node which understand it, it needs to be
> terminated (NEXT).
>
> 2) Data plane
> 2.a) SR-MPLS
> I don't see a label swap. I see a pop of the BSID/replication SID and a
> push of the list of SID in the SR-policy. As described in
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-08#section-8.3
> I don't see how this can translate in a specific SR action (here
> "replication" on the replication node. ) But since there is no SRv6
> specific text in the draft, it's hard to guess.
>

>
> Note that my understanding seems to match your new text/illustration in
> appendix: there is no CONTINUE operation on a replication SID. Only NEXT
> operation:
[RP] I see you point. We shall re-word the text around this area in a
future WG document (probably in rev 01).

> "R6, as Leaf, performs NEXT operation, pops R-SID1 label and delivers the
[RP] Thanks for catching these. We will fix them in rev 00 of WG document.

> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: Rishabh Parekh <[email-masked]>
Date: Wed, 15 Jul 2020 14:28:05 -0700

Bruno,
One clarification:

> "R6, as Leaf, performs NEXT operation, pops R-SID1 label and delivers the
We did not want L12 to be mistaken as a SID and hence the "<R-SID2->L12>"
convention (indicating push R-SID2 and send on interface L12) as compared
to
"<N-SID6, R-SID6>" where both elements are SIDs.

-Rishabh