Subject: Re: [spring] Understanding the replication draft

From: Rishabh Parekh <[email-masked]>
Date: Wed, 1 Jul 2020 09:06:46 -0700

Joel,
Your request was not "lost", but it fell between the cracks :)

Anyway, responses inline.

On Mon, Jun 29, 2020 at 3:17 PM Joel M. Halpern <[email-masked]> wrote:
>
> I asked the authors a version of this question, but apparently my
> request got lost.
>
> For now, this is speaking as an individual.  And I sincerely hope that I
> am merely missing something obvious.
>
> I can not figure out from the current draft how the replication segment
> works in a SID (or label) stack.
> Is there an unstated requirement that the segment must be the last one
> in the stack?
> If not, how is a global SID after teh replication SID understood?

[RP] Replication SID does not need to be the last segment in the
stack. Although Section 2 of draft does not state this explicitly, If
there are other non-replication SIDs following the Replication SID,
the NEXT operation at a downstream node of the segment should process
those SIDs as normal.

> Or is a replication SID implicitly also a binding SID, replacing the
> rest of the stack no matter where it is in the stack?
>     In which case it is implicitly effectively last?

[RP] At a root or a Replication SID, when the active segment is a
Replication SID, it does act like a Binding SID in that it steers the
packet into the Replication segment towards downstream nodes. Note
that additional SIDs might be added on top of the Replication SID to
steer the packet from Root to a given downstream node. The Replication
SID will be at bottom of any such SIDs added to steer the packet, but
again it does not have to be the bottom most SID in the stack.

> Given taht a replication segment is qualified to a node, what happens if
> there is more than one in a stack?  Is it ignored when it hits a node it
> does not apply to?

[RP] On a given node, if an active SID in the stack is a Replication
SID that the node does not understand, it cannot process the packet.
This would be similar to any other kind of SID for which a node does
not have any state.
>
> Do I believe this can be made to work?  Yes.
> But I can not understand how the WG could adopt the work with its
> current lack of clarity.
> And this appears to me to be fundamental enough stuff that it can't be
> left to documents in other WGs.  It seems central to the definition and
> processing of replication SIDs.
>

[RP] Section 2 does specify behavior associated with Replication SID
at different nodes in terms of PUSH, CONTINUE or NEXT operations. If
it is not clear, we can enhance the text.
>
> Yours,
> Joel - speaking as a participant
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 1 Jul 2020 12:23:57 -0400

I am not sure I understand the answer.  I do see that the local 
processing is described in the draft.  But that is not what I am asking.

I am going to try to simplify the conventions to ask the question.  I 
will list SIDs in the order they will be visited.  And mark G-SID-X for 
a global SID, and R-SID-X for a replication SID.

Suppose the stack looks like

G-SID-1
R-SID-1
G-SID-2
G-SID-3
R-SID-2
G-SID-4

So the packet gets delivered to the node identified by G-SID-1.  Great. 
That node sees an R-SID which it understands.  So presumably it 
replicates the packet, and sends the packet (possibly with some 
prepended labels, presumably different prepended labels for different 
destination, controlled by policy.  No problem with that part.)

Now each of the packets geet to the end of the prepended labels, and 
each copy sees G-SID-2.  At which point all of these various nodes that 
have received copies of the packet all send it to the node identified by 
G-SID-2.  Huh?  We just bombarded a node with useless and potentially 
harmful copies of the packet.  then all those copies go to G-SID-3, 
which then processes R-SID-2, and replicates each and every copy to some 
set of destinations.  Which then eventually bombard the node identified 
by G-SID-4.

If the document said that the replication SID when it appears in the 
stack must be the last SID in the stack, and was either terminal for SID 
processing or was a binding SID, the above problem would be avoided. 
But the draft does not say that.  Nor does your reply.

Is there some other way this explosion is avoided?  This seems to need 
to be described in the SPRING draft in order for any of us to understand 
if the approach is what we want as a starting point.  just the idea of 
replication segments is not, in my personal view, enough clarity or 
value to be adopted as a working group document.

Yours,
Joel

---

From: Rishabh Parekh <[email-masked]>
Date: Wed, 1 Jul 2020 11:51:31 -0700

Joel,
I now understand the question better with the example you provided.

The draft states that replication SID must be still part of the stack
so that downstream node can process it appropriately. In your example,
if replication SID is the same at all nodes, R-SID-1 will be in the
label stack and will be the active SID when the packet reaches a given
downstream node. In the use cases we describe, either the replication
SID is the last SID in the stack and performs either a NEXT operation
to process the payload, or a CONTINUE operation to stitch the packet
to another replication segment as described in PIM WG draft, or both
NEXT and CONTINUE. But the draft does not preclude NEXT operation of
R-SID1 with the label stack in your example. Of course, care must be
taken to avoid the "explosion" as you describe it. G-SID-2 has to map
to a unique node; for example, it may be an Anycast-SID that takes
packet to distinct nodes from each of the downstream node, or the
downstream nodes can be border nodes connecting to other segment
routing domains where G-SID-2 resolves to distinct nodes in each
domain.

Although the use cases are not intended to cover the scenario you
describe, maybe we can document this "explosion" in security
considerations of the draft.

-Rishabh

---

From: Rishabh Parekh <[email-masked]>
Date: Wed, 1 Jul 2020 12:01:41 -0700

Sasha,
As I explained in my reply to Joel's e-mail, use cases in draft only
cover scenarios where R-SID-1 is the last segment in stack for either
NEXT or CONTINUE operation, but stack Joel described is not excluded
as long as G-SID-2 resolves to a unique node. How the node that
imposes this stack determines the value of G-SID-2, or other segments
in the stack after R-SID-1 is outside scope of the draft.

-Rishabh

On Wed, Jul 1, 2020 at 9:42 AM Alexander Vainshtein
<[email-masked]> wrote:
>
> Joel, Rishabh and all,
> I think that in the case of SR-MPLS the problems with Joel's example begin much earlier.
>
> The node that sends the packet using the list of SIDs must encode each SID as a label in the label stack.
>
> It knows how to do so for G-SID-1 which is represented as an index -- nothing new with that
> It probably knows how to do so for R-SID-1.
>
> But encoding G-SID-2 (also known as an index) becomes outright impossible if the Downstream nodes of the Replication segment have different SRGB base.
>
> What, if anything, did I miss?
> Is usage of Replication segment limited to the case when all the nodes in the SR-MPLS domain have the same SRGB base?
>
> And, BTW, how is R-SID-1 encoded in the SRH in the case of SRv6?
>
> My 2c,
> Sasha
>
>
>
>
>
> Get Outlook for Android
>
> ________________________________
> From: spring <[email-masked]> on behalf of Joel Halpern Direct <[email-masked]>
> Sent: Wednesday, July 1, 2020, 19:24
> To: Rishabh Parekh
> Cc: [email-masked]
> Subject: Re: [spring] Understanding the replication draft
>
> >> https://clicktime.symantec.com/3RziqzXxh1X11kornov4J3B6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
> >
> > https://clicktime.symantec.com/3RziqzXxh1X11kornov4J3B6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
> >
>
> https://clicktime.symantec.com/3RziqzXxh1X11kornov4J3B6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>
>
>
> ________________________________
> Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
> ________________________________

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 1 Jul 2020 21:27:33 +0200

Hi Rishabh,

 > Of course, care must be

I think you are stretching it too thin.

See even if G-SID-2 is anycast SID you have zero assurance that physical
nodes packets will land on would be at all diverse.

Likewise crossing domains yet providing identical global SID now to be a
different node in each such domain to me is not a realistic example.

I think we have two options:

A) Firmly state that replication SID MUST be the last one on the stack

B) Instead of real SID after the replication SID provide a binding SID
which locally will be mapped to a different SID list imposed to
each replicated flow.

What is currently in the draft seems to be very counterintuitive and IMHO
will result in operational difficulties.

Thx a lot,
R.

---

From: Rishabh Parekh <[email-masked]>
Date: Wed, 1 Jul 2020 12:39:47 -0700

Robert,

>B) Instead of real SID after the replication SID provide a binding SID which locally will be mapped to a different SID list imposed to each replicated flow.

We would be fine with A), but we don't want to exclude possibility of
something like what you describe in B.

-Rishabh

On Wed, Jul 1, 2020 at 12:27 PM Robert Raszuk <[email-masked]> wrote:
> See even if G-SID-2 is anycast SID you have zero assurance that physical nodes packets will land on would be at all diverse.
>
> Likewise crossing domains yet providing identical global SID now to be a different node in each such domain to me is not a realistic example.
>
> B) Instead of real SID after the replication SID provide a binding SID which locally will be mapped to a different SID list imposed to each replicated flow.
>
> What is currently in the draft seems to be very counterintuitive and IMHO will result in operational difficulties.
>
> Thx a lot,
> R.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 1 Jul 2020 15:42:36 -0400

Any SID behavior needs to be defined in a SPRING draft as far as I can 
tell.  PIM defines how those behaviors are triggered / associated.  At 
least, that is how I have understood all the other behavioral and 
routing protocol handling.  It is, for example, why the network 
programming draft was a SPRING draft and not an IDR or LSR draft.
So if "continue" is a new behavior, it needs to be defined here, not in 
a PIM draft.

And from everything you describe, this draft should require that the 
replication segment be the last element in the SID stack (label stack, 
...) as it appears in the packet at the time of reception and processing 
of the replication segment identifier.  That can result in local 
processing of the underlying packet, gatewaying of the packet to other 
multicast, replication of the packet with new SID stacks on the 
different replicas, etc.  But having a stack after the replication 
segment sure sounds like a recipe for disaster.

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 1 Jul 2020 15:44:37 -0400

I don't even bind if the binding SID behavior is part of the replication 
SID (with different binding results in different directions).  Which 
would seem to allow multi-stage replication even with requirement A.

Allowing a binding SID after the replication SID seems to require that 
the explicit binding SID, t the replicating node, have different 
meanings for different directions.  Or something??

Yours,
Joel

On 7/1/2020 3:42 PM, Alexander Vainshtein wrote:
> Robert, Rishabh and all,
> I concur with Robert but would like to add that Option A woild 
> effectively eliminate the possibility of building MDTs with more than 
> one level using Replication Segments.
> 
> Which is probably not the intent of the draft.
> 
> My 2c.
> 
> Get Outlook for Android <https://aka.ms/ghei36>
> 
> ------------------------------------------------------------------------
> *From:* spring <[email-masked]> on behalf of Robert Raszuk 
> <[email-masked]>
> *Sent:* Wednesday, July 1, 2020, 22:27
> *To:* Rishabh Parekh
> *Cc:* Joel Halpern Direct; [email-masked]
> *Subject:* Re: [spring] Understanding the replication draft
> 
> Hi Rishabh,
> 
>   > Of course, care must be
> What is currently in the draft seems to be very counterintuitive and 
> IMHO will result in operational difficulties.
> 
> Thx a lot,
> R.
> 
> 
> 
> ------------------------------------------------------------------------
> Notice: This e-mail together with any attachments may contain 
> information of Ribbon Communications Inc. that is confidential and/or 
> proprietary for the sole use of the intended recipient. Any review, 
> disclosure, reliance or distribution by others or forwarding without 
> express permission is strictly prohibited. If you are not the intended 
> recipient, please notify the sender immediately and then delete all 
> copies, including any attachments.
> ------------------------------------------------------------------------

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 1 Jul 2020 23:56:43 +0200

Hi Alexander,

Do we really know how to build MDTs as source routed chains ?

If that is the goal here IMHO it deserves a whole separate document ....

In general when we replicate we take a packet and copy it to interfaces A,
B ... Z. That's a local rule I presume executed for flows containing
R-SID-n. But we just can't send the packet with identical list of SIDs from
that point on any outgoing interface as results will be rather poor.

We need custom list for each outbound interface and that is something I am
not seeing in the draft. Till this is explained I would keep thinking that
building MDTs should be more of as control plane task.

Thx.
R.

On Wed, Jul 1, 2020 at 9:42 PM Alexander Vainshtein <
[email-masked]> wrote:

> Robert, Rishabh and all,
> I concur with Robert but would like to add that Option A woild effectively
> eliminate the possibility of building MDTs with more than one level using
> Replication Segments.
>
> ------------------------------
> *From:* spring <[email-masked]> on behalf of Robert Raszuk <
> [email-masked]>
> ------------------------------
> Notice: This e-mail together with any attachments may contain information
> of Ribbon Communications Inc. that is confidential and/or proprietary for
> the sole use of the intended recipient. Any review, disclosure, reliance or
> distribution by others or forwarding without express permission is strictly
> prohibited. If you are not the intended recipient, please notify the sender
> immediately and then delete all copies, including any attachments.
> ------------------------------
>

---

From: Rishabh Parekh <[email-masked]>
Date: Wed, 1 Jul 2020 15:55:29 -0700

Sasha,
I agree with Robert. Building MDTs for services is covered in a
separate draft in BESS:
https://datatracker.ietf.org/doc/draft-parekh-bess-mvpn-evpn-sr-p2mp/

-Rishabh

On Wed, Jul 1, 2020 at 2:56 PM Robert Raszuk <[email-masked]> wrote:
> In general when we replicate we take a packet and copy it to interfaces A, B ... Z. That's a local rule I presume executed for flows containing R-SID-n. But we just can't send the packet with identical list of SIDs from that point on any outgoing interface as results will be rather poor.
>
> We need custom list for each outbound interface and that is something I am not seeing in the draft. Till this is explained I would keep thinking that building MDTs should be more of as control plane task.
>
> Thx.
> R.
>
> On Wed, Jul 1, 2020 at 9:42 PM Alexander Vainshtein <[email-masked]> wrote:
>>
>> Robert, Rishabh and all,
>> I concur with Robert but would like to add that Option A woild effectively eliminate the possibility of building MDTs with more than one level using Replication Segments.
>>
>> From: spring <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
>> Sent: Wednesday, July 1, 2020, 22:27
>> To: Rishabh Parekh
>> Cc: Joel Halpern Direct; [email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 1 Jul 2020 19:10:51 -0400

What I think this draft could use is a description of what the legal and 
illegal ways of constructing the tools are, so that other drafts can 
then properly use the tools.

Yours,
Joel

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 1 Jul 2020 17:49:48 -0700

Rishabh,

Transport SID with a service on top can’t be a BoS label, there’s s service label below, since a service is associated with a particular node, there would be at least a N-SID associated with the service node.
It seems like B-SID behavior is the correct one, when R-SID is looked up and popped, it would yield: replication  (as programmed by a controller, since there’s no state) + new label stack associated with the new, post replication/branching path that is imposed on top of existing label stack, so service label ( + optionally more transport labels) are preserved.

Cheers,
Jeff

---

From: Rishabh Parekh <[email-masked]>
Date: Wed, 1 Jul 2020 23:34:45 -0700

Jeff,
Your explanation of distinct Transport SIDs and service labels (which
appear at BoS) applies to Point-to-Point services. Same model can be
applied when a Point-to-Multipoint service is realized by one
end-to-end replication segment; "Downstream Replication SID" as
specified in draft is effectively the service label at a specific
downstream node of a Replication segment with Transport SIDs imposed
on top to take replicated packet to that node.

However, when a Point-to-Multipoint service is over replication
segments stitched together to form a P2MP tree, as described in PIM WG
draft, this model no longer holds since all service egress nodes would
have to agree on one common service label. So  P2MP services
implicitly map the P2MP transport label (Replication SID at BoS in
this case) to the P2MP service. Of course, this implies one-to-one
association between a P2MP service and a P2MP transport. There are
techniques to share one P2MP transport across different P2MP services
using either upstream assigned label or a global context from
"Domain-wide Common Block"
(draft-ietf-bess-mvpn-evpn-aggregation-label). These and other gory
details are described in Section 2 of PIM WG draft and to some extent
in BESS MVPN-EVPN draft.

-Rishabh

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 6 Jul 2020 21:17:08 +0530

Hi WG,

Reading the I-D and based on the discussion on this thread I believe
more description is required. As Joel pointed out, clarity on what is
legal/illegal (or out of scope for now) is needed.

I have no strong opinion if that needs to be done before or after adoption!

I do not follow PIM closely and just realized that the SR P2MP Policy
in the PIM I-D [1] is adopted by the PIM WG, but not yet posted [2].
I wanted to make sure that it has been decided that PIM is the right
place to define SR P2MP policy (discussed either in the WG and/or
between chairs/AD)?

Thanks!
Dhruv

[1] https://datatracker.ietf.org/doc/draft-voyer-pim-sr-p2mp-policy/
[2] https://mailarchive.ietf.org/arch/msg/pim/YyF7I02aaRtpZngf7uTno69IB90/

---

From: <[email-masked]>
Date: Tue, 7 Jul 2020 09:42:07 +0000

Hi Dhruv,

> -----Original Message-----
> From: spring [mailto:[email-masked]] On Behalf Of Dhruv Dhody

I leave this for the authors to reply.
 
> place to define SR P2MP policy (discussed either in the WG and/or

draft-voyer-pim-sr-p2mp-policy-00 is to be worked in the PIM WG.
The PIM WG is waiting for the SPRING WG to adopt draft-voyer-spring-sr-replication-segment, since the -pim- document has a dependency on the -spring- document.

Quoting the PIM chairs: "We have solid support to adopt this draft. [...] We are waiting to hear back from the spring chairs as to the wg status of the local replication draft of which your draft is dependent. So please hold off on submitting the new draft-ietf-pim-sr-p2mp-policy until they give us the green light."

Does this answer your question?

--Bruno
 
> [2]
> https://mailarchive.ietf.org/arch/msg/pim/YyF7I02aaRtpZngf7uTno69IB90/
> 
> 
> 
> > > Transport SID with a service on top can’t be a BoS label, there’s s service
> label below, since a service is associated with a particular node, there would
> be at least a N-SID associated with the service node.
> > > It seems like B-SID behavior is the correct one, when R-SID is looked up
> and popped, it would yield: replication  (as programmed by a controller, since
> there’s no state) + new label stack associated with the new, post
> replication/branching path that is imposed on top of existing label stack, so
> service label ( + optionally more transport labels) are preserved.
> > >
> > > Cheers,
> > > Jeff
> > > B) Instead of real SID after the replication SID provide a binding SID which
> locally will be mapped to a different SID list imposed to each replicated flow.
> > >
> > >
> > > B) Instead of real SID after the replication SID provide a binding SID which
> locally will be mapped to a different SID list imposed to each replicated flow.
> > >

_________________________________________________________________________________________________________________________

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: Dhruv Dhody <[email-masked]>
Date: Tue, 7 Jul 2020 15:31:38 +0530

Hi Bruno,

Yes, thanks! I was just making sure that we have an agreement that PIM
is the right place to define SR P2MP Policy.

What is missing in the spring I-D is some very high level discussion
in terms of architecture on how replication segment and SR P2MP policy
come together. The current I-D tries to define a replication segment
as an independent entity that could be used on its own but it makes it
difficult to visualize without some high level text or an example.

Thanks!
Dhruv

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 7 Jul 2020 13:45:28 +0000

Dhruv, Bruno and all,
Regarding the statement " What is missing in the spring I-D is some very high level discussion in terms of architecture on how replication segment and SR P2MP policy come together" - I cannot agree more.

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Dhruv Dhody
Sent: Tuesday, July 7, 2020 1:02 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [spring] Understanding the replication draft

Hi Bruno,

Yes, thanks! I was just making sure that we have an agreement that PIM is the right place to define SR P2MP Policy.

What is missing in the spring I-D is some very high level discussion in terms of architecture on how replication segment and SR P2MP policy come together. The current I-D tries to define a replication segment as an independent entity that could be used on its own but it makes it difficult to visualize without some high level text or an example.

Thanks!
Dhruv

On Tue, Jul 7, 2020 at 3:12 PM <[email-masked]> wrote:
> > more description is required. As Joel pointed out, clarity on what 
> > is legal/illegal (or out of scope for now) is needed.
>
> > I do not follow PIM closely and just realized that the SR P2MP 
> > Policy in the PIM I-D [1] is adopted by the PIM WG, but not yet posted [2].
> > [1] 
> > https://clicktime.symantec.com/36sxrNPFssiaB8jE9mzzZDd6H2?u=https%3A
> > %2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-voyer-pim-sr-p2mp-policy%2F
> > [2]
> > https://clicktime.symantec.com/3LtBxbxRK3NkuKYc3FC7rr46H2?u=https%3A
> > %2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fpim%2FYyF7I02aaRtpZngf7uTn
> > o69IB90%2F
> >
> >
> >
> > > Your explanation of distinct Transport SIDs and service labels 
> > > (which appear at BoS) applies to Point-to-Point services. Same 
> > > model can be applied when a Point-to-Multipoint service is 
> > > realized by one end-to-end replication segment; "Downstream 
> > > Replication SID" as specified in draft is effectively the service 
> > > label at a specific downstream node of a Replication segment with 
> > > Transport SIDs imposed on top to take replicated packet to that node.
> > >
> > > segments stitched together to form a P2MP tree, as described in 
> > > PIM WG draft, this model no longer holds since all service egress 
> > > nodes would have to agree on one common service label. So  P2MP 
> > > services implicitly map the P2MP transport label (Replication SID 
> > > at BoS in this case) to the P2MP service. Of course, this implies 
> > > one-to-one association between a P2MP service and a P2MP 
> > > transport. There are techniques to share one P2MP transport across 
> > > different P2MP services using either upstream assigned label or a 
> > > global context from "Domain-wide Common Block"
> > > (draft-ietf-bess-mvpn-evpn-aggregation-label). These and other 
> > > gory details are described in Section 2 of PIM WG draft and to 
> > > some extent in BESS MVPN-EVPN draft.
> > >
> > > -Rishabh
> > >
> > > On Wed, Jul 1, 2020 at 5:50 PM Jeff Tantsura 
> > > <[email-masked]>
> > wrote:
> > > >
> > > > Rishabh,
> > > >
> > label below, since a service is associated with a particular node, 
> > there would be at least a N-SID associated with the service node.
> > and popped, it would yield: replication  (as programmed by a 
> > controller, since there’s no state) + new label stack associated 
> > with the new, post replication/branching path that is imposed on top 
> > of existing label stack, so service label ( + optionally more transport labels) are preserved.
> > > >
> > > > Cheers,
> > > > Jeff
> > > > On Jul 1, 2020, 12:40 PM -0700, Rishabh Parekh 
> > > > <[email-masked]>,
> > wrote:
> > > >
> > > > Robert,
> > > >
> > > > We would be fine with A), but we don't want to exclude 
> > > > possibility of something like what you describe in B.
> > > >
> > > > -Rishabh
> > > >
> > > > On Wed, Jul 1, 2020 at 12:27 PM Robert Raszuk 
> > > > <[email-masked]>
> > wrote:
> > > >
> > > >
> > > > Hi Rishabh,
> > > >
> > > > Of course, care must be
> > > > taken to avoid the "explosion" as you describe it. G-SID-2 has 
> > > > to map to a unique node; for example, it may be an Anycast-SID 
> > > > that takes packet to distinct nodes from each of the downstream 
> > > > node, or the downstream nodes can be border nodes connecting to 
> > > > other segment routing domains where G-SID-2 resolves to distinct 
> > > > nodes in each domain.
> > > >
> > > >
> > > > https://clicktime.symantec.com/3U9X5zkPbKst7T8373JWnS6H2?u=https
> > > > %3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
> > >
> > > https://clicktime.symantec.com/3U9X5zkPbKst7T8373JWnS6H2?u=https%3
> > > A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
> >
> > https://clicktime.symantec.com/3U9X5zkPbKst7T8373JWnS6H2?u=https%3A%
> > 2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>
> ______________________________________________________________________
> ___________________________________________________
>
> 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.

_______________________________________________
spring mailing list
[email-masked]
https://clicktime.symantec.com/3U9X5zkPbKst7T8373JWnS6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

-----------------------------------------------------------------------------------------------------------------------
Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. that
is confidential and/or proprietary for the sole use of the intended recipient.  Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly prohibited.  If you are not the intended
recipient, please notify the sender immediately and then delete all copies, including any attachments.
-----------------------------------------------------------------------------------------------------------------------

---

From: Rishabh Parekh <[email-masked]>
Date: Tue, 7 Jul 2020 08:42:17 -0700

>I leave this for the authors to reply.

We are working onthe  next revision of the draft that will clarify
some text and illustrate and example. We shall post it soon.

-Rishabh

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 7 Jul 2020 14:15:49 -0700

Thanks Rishabh!
+1 to the above comments and looking forward to the updated draft.

Cheers,
Jeff
On Jul 7, 2020, 7:35 AM -0700, Alexander Vainshtein <[email-masked]>, wrote:
> > > On Thu, Jul 2, 2020 at 12:05 PM Rishabh Parekh <rishabhp@gmail..com>
> > > wrote:
> > > >
> > > > Jeff,
> Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. _______________________________________________
> spring mailing list
> [email-masked]

---

From: Rishabh Parekh <[email-masked]>
Date: Fri, 10 Jul 2020 13:45:41 -0700

All,
We have posted revision 04
<https://tools.ietf.org/html/draft-voyer-spring-sr-replication-segment-04>
of the draft. This addresses comments on this thread and adds an example
illustrating replication segment. Diff from rev 03:
https://tinyurl.com/y96ueb9h

Some WG  members also wanted to understand how Replication segments are
stitched together to form a P2MP tree based on SR P2MP policy in the PIM
draft. We have posted revision 02
<https://tools.ietf.org/html/draft-voyer-pim-sr-p2mp-policy-02> of PIM P2MP
policy draft that adds examples of how these things tie together. I hope
that helps clarify the relationship. Diff from rev 01:
https://tinyurl.com/yban2jp6

Please review,
-Rishabh

On Tue, Jul 7, 2020 at 2:16 PM Jeff Tantsura <[email-masked]>
wrote:

> Regarding the statement " What is missing in the spring I-D is some very
> high level discussion in terms of architecture on how replication segment
> and SR P2MP policy come together" - I cannot agree more.
>
> My 2c,
> Sasha
>
> Office: +972-39266302
> Cell: +972-549266302
> Yes, thanks! I was just making sure that we have an agreement that PIM is
> the right place to define SR P2MP Policy.
>
> What is missing in the spring I-D is some very high level discussion in
> terms of architecture on how replication segment and SR P2MP policy come
> together. The current I-D tries to define a replication segment as an
> independent entity that could be used on its own but it makes it difficult
> to visualize without some high level text or an example.
>
> Thanks!
> Dhruv
>
> > The PIM WG is waiting for the SPRING WG to adopt
> draft-voyer-spring-sr-replication-segment, since the -pim- document has a
> dependency on the -spring- document.
> >
> > Quoting the PIM chairs: "We have solid support to adopt this draft..
> [...] We are waiting to hear back from the spring chairs as to the wg
> status of the local replication draft of which your draft is dependent.. So
> please hold off on submitting the new draft-ietf-pim-sr-p2mp-policy until
> they give us the green light."
> >
> > > > > taken to avoid the "explosion" as you describe it.. G-SID-2 has
> > > > > https://clicktime..symantec.com/3U9X5zkPbKst7T8373JWnS6H2?u=https
> <https://clicktime.symantec.com/3U9X5zkPbKst7T8373JWnS6H2?u=https>
> > 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.
> >
> > privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Tue, 14 Jul 2020 11:55:07 +0000

Hi

The rev-04 says “The Replication SID MUST be the last SID (at the bottom of stack for SR-MPLS) in a packet that is steered out from a Replication node of a Replication Segment.”.

I feel a little hard to understand ……

My question is: Can an “MPLS packet” be carried over the P2MP policy ? say a packet like this: { Replication SID, (VPN Label, IPv4/IPv6 C-multicast packet) } ?

In my understanding, with an imagined topology comprising of Replication Node R1/R2/R3/R4, the picture is like this:

The Replication Node R2 receives such a packet (from R1), sees the Replication SID<R2> on the “Top” of the label stack,  performs the corresponding action of “replication”,  replicates the packet to downstream Replication Nodes R3 and R4, SWAPs the Replication SID<R2> to Replication SID<R3> and Replication SID<R4> respectively.

The Replication Node R3 receives the packet { Replication SID<R3>, (VPN Label, IPv4/IPv6 C-multicast packet) }.

The Replication Node R4 receives the packet { Replication SID<R4>, (VPN Label, IPv4/IPv6 C-multicast packet) }.

Thanks
Jingrong

From: spring [mailto:[email-masked]] On Behalf Of Rishabh Parekh
Sent: Saturday, July 11, 2020 4:46 AM
To: Jeff Tantsura <[email-masked]>
Cc: Dhruv Dhody <[email-masked]>; [email-masked]; [email-masked]; Alexander Vainshtein <[email-masked]>
Subject: Re: [spring] Understanding the replication draft

All,
We have posted revision 04<https://tools.ietf.org/html/draft-voyer-spring-sr-replication-segment-04> of the draft. This addresses comments on this thread and adds an example illustrating replication segment. Diff from rev 03:  https://tinyurl.com/y96ueb9h

Some WG  members also wanted to understand how Replication segments are stitched together to form a P2MP tree based on SR P2MP policy in the PIM draft. We have posted revision 02<https://tools.ietf.org/html/draft-voyer-pim-sr-p2mp-policy-02> of PIM P2MP policy draft that adds examples of how these things tie together. I hope that helps clarify the relationship. Diff from rev 01: https://tinyurl.com/yban2jp6

Please review,
-Rishabh

On Tue, Jul 7, 2020 at 2:16 PM Jeff Tantsura <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Rishabh!
+1 to the above comments and looking forward to the updated draft.

Cheers,
Jeff
On Jul 7, 2020, 7:35 AM -0700, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>, wrote:

Dhruv, Bruno and all,

My 2c,
Sasha

Office: +972-39266302
Cell: +972-549266302
Email: [email-masked]<mailto:[email-masked]>

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Dhruv Dhody
Sent: Tuesday, July 7, 2020 1:02 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Understanding the replication draft

Hi Bruno,

Thanks!
Dhruv

On Tue, Jul 7, 2020 at 3:12 PM <[email-masked]<mailto:[email-masked]>> wrote:
> > From: spring [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Dhruv
> > Dhody
> Quoting the PIM chairs: "We have solid support to adopt this draft.. [...] We are waiting to hear back from the spring chairs as to the wg status of the local replication draft of which your draft is dependent.. So please hold off on submitting the new draft-ietf-pim-sr-p2mp-policy until they give us the green light."
>
> > %2F%2Fdatatracker.ietf.org<http://2Fdatatracker.ietf.org>%2Fdoc%2Fdraft-voyer-pim-sr-p2mp-policy%2F
> > [2]
> > %2F%2Fmailarchive.ietf.org<http://2Fmailarchive.ietf.org>%2Farch%2Fmsg%2Fpim%2FYyF7I02aaRtpZngf7uTn
> > o69IB90%2F
> >
> >
> >
> > On Thu, Jul 2, 2020 at 12:05 PM Rishabh Parekh <rishabhp@gmail...com<mailto:rishabhp@gmail...com>>
> > wrote:
> > >
> > > Jeff,
> > > <[email-masked]<mailto:[email-masked]>>
> > wrote:
> > > >
> > > > Rishabh,
> > > >
> > > > <[email-masked]<mailto:[email-masked]>>,
> > wrote:
> > > >
> > > > Robert,
> > > >
> > > > <[email-masked]<mailto:[email-masked]>>
> > wrote:
> > > >
> > > >
> > > > Hi Rishabh,
> > > >
> > > > Of course, care must be
> > > > [email-masked]<mailto:[email-masked]>
> > > > https://clicktime..symantec.com/3U9X5zkPbKst7T8373JWnS6H2?u=https<https://clicktime.symantec.com/3U9X5zkPbKst7T8373JWnS6H2?u=https>
> > > > %3A%2F%2Fwww.ietf.org<http://2Fwww.ietf.org>%2Fmailman%2Flistinfo%2Fspring
> > >
> > > [email-masked]<mailto:[email-masked]>
> > > https://clicktime.symantec.com/3U9X5zkPbKst7T8373JWnS6H2?u=https%3<https://clicktime.symantec.com/3U9X5zkPbKst7T8373JWnS6H2?u=https%253>
> > > A%2F%2Fwww.ietf.org<http://2Fwww.ietf.org>%2Fmailman%2Flistinfo%2Fspring
> >
> > [email-masked]<mailto:[email-masked]>
> > https://clicktime.symantec.com/3U9X5zkPbKst7T8373JWnS6H2?u=https%3A%<https://clicktime.symantec.com/3U9X5zkPbKst7T8373JWnS6H2?u=https%3A%25>
> > 2F%2Fwww.ietf..org<http://2Fwww.ietf.org>%2Fmailman%2Flistinfo%2Fspring
>

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://clicktime.symantec.com/3U9X5zkPbKst7T8373JWnS6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

________________________________
Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc.. that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
________________________________
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: Rishabh Parekh <[email-masked]>
Date: Tue, 14 Jul 2020 13:25:01 -0700

Jingrong,
As I had explained to Jeff Tantsura earlier in the thread, with P2MP
services realized by P2MP trees, VPN label is NOT part of the label stack
since egress (leaf nodes of P2MP trees) of the P2MP service MAY have
different VPN labels for same context. For P2MP services, it is normal to
use the top transport label (Replication SID in this case) as implicit
context for the service. Of course, this implies one-to-one association
between P2MP transport and service.

There are techniques, using upstream label allocation or DCB (domain wide
context blocks), where the same VPN label can be assigned to the service on
all the egress nodes. In this case, the P2MP transports can be shared
across P2MP services (at a set of egress nodes) and the VPN label can
appear after the Replication SID as we have indicated in the PIM WG draft.
But, the VPN label is not a SID and, IMO, the statement "Replication SID
must be last SID...." still holds but it is not at the bottom of the stack.
We can clarify this when we publish the WG document.

-Rishabh

On Tue, Jul 14, 2020 at 4:55 AM Xiejingrong (Jingrong) <
[email-masked]> wrote:

> Hi
>
>
>
> The rev-04 says “The Replication SID MUST be the last SID (at the bottom
> of stack for SR-MPLS) in a packet that is steered out from a Replication
> node of a Replication Segment.”.
>
>
>
> My question is: Can an “MPLS packet” be carried over the P2MP policy ? say
> a packet like this: { Replication SID, (VPN Label, IPv4/IPv6 C-multicast
> packet) } ?
>
>
>
> In my understanding, with an imagined topology comprising of Replication
> Node R1/R2/R3/R4, the picture is like this:
>
>
>
> The Replication Node R2 receives such a packet (from R1), sees the
> Replication SID<R2> on the “Top” of the label stack,  performs the
> corresponding action of “replication”,  replicates the packet to downstream
> Replication Nodes R3 and R4, SWAPs the Replication SID<R2> to Replication
> SID<R3> and Replication SID<R4> respectively.
>
>
>
> *From:* spring [mailto:[email-masked]] *On Behalf Of *Rishabh
> Parekh
> *Sent:* Saturday, July 11, 2020 4:46 AM
> *To:* Jeff Tantsura <[email-masked]>
> *Cc:* Dhruv Dhody <[email-masked]>; [email-masked];
> [email-masked]; Alexander Vainshtein <[email-masked]>
> <https://tools.ietf.org/html/draft-voyer-pim-sr-p2mp-policy-02> of PIM
> P2MP policy draft that adds examples of how these things tie together. I
> hope that helps clarify the relationship. Diff from rev 01:
> > > On Thu, Jul 2, 2020 at 12:05 PM Rishabh Parekh <rishabhp@gmail...com>
> > > wrote:
> > > >
> > > > Jeff,
> <https://clicktime.symantec.com/3U9X5zkPbKst7T8373JWnS6H2?u=https%3A%25>
> > > 2F%2Fwww.ietf..org <http://2Fwww.ietf.org>
> %2Fmailman%2Flistinfo%2Fspring
> >
> of Ribbon Communications Inc.. that is confidential and/or proprietary for

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Wed, 15 Jul 2020 04:38:58 +0000

Hi Rishabh,

Thank you very much for the reply.
The words you used like P2MP service/P2MP transport, upstream label/DCB, last SID/BoS  and their distinctions all match my dictionary, so it’s now very clear to me. Sincerely appreciate!

I have some further comments in detail:

1)       About the distinction of Replication-ID and Replication-SID, and their usage.
If there is an SID block specially reserved for the P2MP Transport on each of the Replication Node, and such SID block (on each Replication Node) is advertised through west-east protocol like IGP/BGP,
and then the north-south controller (like PCE) can use the “Replication-ID” and “Node-ID” only, but don’t need to use “Replication-SID” when populating the “Tree” information to each “Replication Node” ?
In that way, the Controller doesn’t need to allocate (and manage) each of the Replication-SID (Say 1000 Replication-SID)  for  each Replication Node (Say 100 nodes).

2)       About the Replication Segment illustration.
The rev-04 add a section “Illustration of a Replication Segment” in appendix, it is very clear and useful.
To me, the “Replication State” is more like a “forwarding state”, and I think it will be helpful to understand the whole solution if:
a) there is a description/Illustration about the building procedure of the “forwarding state” ---- What’s the information each Replication Node receives from the controller, and how each node builds its own forwarding state.
b) there is a description/Illustration about the processing of multicast packet on the whole path of the P2MP tree.

3)       About the applicability of SR-MPLS and SRv6.
The rev-04 says “Replication segments apply equally to both SR-MPLS and SRv6 instantiations of Segment Routing.”.
I am not sure if this document will cover SRv6 as well, but if it does, then I would like to see the same level of consideration as SR-MPLS.

Thanks,
Jingrong

From: Rishabh Parekh [mailto:[email-masked]]
Sent: Wednesday, July 15, 2020 4:25 AM
To: Xiejingrong (Jingrong) <[email-masked]>
Cc: Jeff Tantsura <[email-masked]>; Dhruv Dhody <[email-masked]>; [email-masked]; [email-masked]; Alexander Vainshtein <[email-masked]>
Subject: Re: [spring] Understanding the replication draft

Jingrong,
As I had explained to Jeff Tantsura earlier in the thread, with P2MP services realized by P2MP trees, VPN label is NOT part of the label stack since egress (leaf nodes of P2MP trees) of the P2MP service MAY have different VPN labels for same context. For P2MP services, it is normal to use the top transport label (Replication SID in this case) as implicit context for the service. Of course, this implies one-to-one association between P2MP transport and service.

There are techniques, using upstream label allocation or DCB (domain wide context blocks), where the same VPN label can be assigned to the service on all the egress nodes. In this case, the P2MP transports can be shared across P2MP services (at a set of egress nodes) and the VPN label can appear after the Replication SID as we have indicated in the PIM WG draft. But, the VPN label is not a SID and, IMO, the statement "Replication SID must be last SID...." still holds but it is not at the bottom of the stack. We can clarify this when we publish the WG document.

-Rishabh

On Tue, Jul 14, 2020 at 4:55 AM Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>> wrote:
Hi

Thanks
Jingrong

From: spring [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Rishabh Parekh
Sent: Saturday, July 11, 2020 4:46 AM
To: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>
Cc: Dhruv Dhody <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Understanding the replication draft

All,

Please review,
-Rishabh

Cheers,
Jeff

My 2c,
Sasha

Office: +972-39266302
Cell: +972-549266302

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Dhruv Dhody
Sent: Tuesday, July 7, 2020 1:02 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Understanding the replication draft

Hi Bruno,

Thanks!
Dhruv

---

From: Rishabh Parekh <[email-masked]>
Date: Wed, 15 Jul 2020 13:46:17 -0700

Jingrong,

Replies inline.

1)       About the distinction of Replication-ID and Replication-SID, and
> their usage.
>
> If there is an SID block specially reserved for the P2MP Transport on each
> of the Replication Node, and such SID block (on each Replication Node) is
> advertised through west-east protocol like IGP/BGP,
>
> and then the north-south controller (like PCE) can use the
> “Replication-ID” and “Node-ID” only, but don’t need to use
> “Replication-SID” when populating the “Tree” information to each
> “Replication Node” ?
>
> In that way, the Controller doesn’t need to allocate (and manage) each of
> the Replication-SID (Say 1000 Replication-SID)  for  each Replication Node
> (Say 100 nodes).
>
>
As we try to make the distinction clear in the draft, Replication segment
is a logical segment that needs to be explicitly instantiated on the node
either by PCE or by some other mechanism (maybe local config?). The
Replication SID has to be assigned when the Replication segment (with a
Replication-ID) is created on the node. Note Replication Segments can be
created and deleted over time. and So, there is no pre-allocated block of
Replication SIDs that can be announced in IGP or BGP. Effectively, the
entity managing Replication segments has to manage the Replication SIDs.

> To me, the “Replication State” is more like a “forwarding state”, and I
> think it will be helpful to understand the whole solution if:
>
> a) there is a description/Illustration about the building procedure of the
> “forwarding state” ---- What’s the information each Replication Node
> receives from the controller, and how each node builds its own forwarding
> state.
>
> b) there is a description/Illustration about the processing of multicast
> packet on the whole path of the P2MP tree.
>
>
Illustrations of how packets and handed on a P2MP tree built by stitching
Replication segments have been added in latest revision 02 of PIM WG draft:
https://datatracker.ietf.org/doc/draft-voyer-pim-sr-p2mp-policy/
We have drafts on PCEP and BGP protocol extensions to instantiate
Replication segments.

> The rev-04 says “Replication segments apply equally to both SR-MPLS and
> SRv6 instantiations of Segment Routing.”.
>
> I am not sure if this document will cover SRv6 as well, but if it does,
> then I would like to see the same level of consideration as SR-MPLS.
>
>
>

 Yes, we will have the same level of details for SRv6 Replication too.

-Rishabh

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Thu, 16 Jul 2020 10:45:06 +0000

(Though it is in a PIM WG draft (cc’ed), but the terminologies in RFC8402 are used and are the key to understand, so I would  expect points from the SPRING WG).

Hi Rishabh,

Thanks for your response!

Let me try to understand the applicability of SRv6 first, and move to the other points afterwards.

I read the appendix A.1 in <draft-voyer-pim-sr-p2mp-policy-02>, and still have difficulty to understand the processing of multicast packet.

   o  R2, as Leaf, performs NEXT operation, pops T-SID1 label and
      delivers the payload.  For replication to R6, R2 performs a PUSH
      operation of N-SID6, to send <N-SID6,T-SID1> label stack to R3.
      R3 is the penultimate hop for N-SID6; it performs penultimate hop
      popping, which corresponds to the NEXT operation and the packet is
      then sent to R6 with <T-SID1> in the label stack.  For replication
      to R7, R2 performs a PUSH operation of N-SID7, to send
      <N-SID7,T-SID1> label stack to R4, one of IGP ECMP nexthops
      towards R7.  R4 is the penultimate hop for N-SID6; it performs
      penultimate hop popping, which corresponds to the NEXT operation
      and the packet is then sent to R7 with <T-SID1> in the label
      stack.

When considering SRv6, The “PUSH operation of N-SID6” and the “PUSH operation of N-SID7” are not clear to me.

Seems that <N-SID6,T-SID1> and <N-SID7,T-SID1> are only for SR-MPLS, where T-SID1 is locally meaningful, and N-SID is globally reachable.

I try to understand what’s the shape of each packet – pkt12, pkt23, pkt36, pkt25, pkt47 in this example when using SRv6.

                    R3----(pkt36)----R6
                    /
                 (pkt23)
                  /
R1----(pkt12)----R2----(pkt24)----R4----(pkt47)----R7

And this is my assumption:
Pkt12: (SA=R1, DA=R2_RepSID) (C-multicast pkt)
Pkt23/Pkt36: (SA=R1, DA=R6_RepSID) (C-multicast pkt)
Pkt24/Pkt47: (SA=R1, DA=R7_RepSID) (C-multicast pkt)

Is that correct ?

Thanks
Jingrong

Sent: Thursday, July 16, 2020 4:46 AM

Jingrong,

Replies inline.

As we try to make the distinction clear in the draft, Replication segment is a logical segment that needs to be explicitly instantiated on the node either by PCE or by some other mechanism (maybe local config?). The Replication SID has to be assigned when the Replication segment (with a Replication-ID) is created on the node. Note Replication Segments can be created and deleted over time. and So, there is no pre-allocated block of Replication SIDs that can be announced in IGP or BGP. Effectively, the entity managing Replication segments has to manage the Replication SIDs.

Illustrations of how packets and handed on a P2MP tree built by stitching Replication segments have been added in latest revision 02 of PIM WG draft: https://datatracker.ietf.org/doc/draft-voyer-pim-sr-p2mp-policy/
We have drafts on PCEP and BGP protocol extensions to instantiate Replication segments.

-Rishabh

---

From: Rishabh Parekh <[email-masked]>
Date: Thu, 16 Jul 2020 09:41:31 -0700

Jingrong,
Your understanding is essentially correct. Think of a Replication function
at a node represented by the function portion of SRV6 SID with Replication
context either in arg or in the function itself. In the simplest case,as
you illustrated, replication to a downstream node is just constructing a
SRv6 SID with downstream locator + downstream replication function +
replication context (optional) and putting it in the DA of IPv6 packet. If
the downstream node is remote and the packet has to take a specific path
(not the IGP shortest path) to the node, the downstream replication SID
will be somewhere in SRH.

-Rishabh

On Thu, Jul 16, 2020 at 3:45 AM Xiejingrong (Jingrong) <
[email-masked]> wrote:

> (Though it is in a PIM WG draft (cc’ed), but the terminologies in RFC8402
> are used and are the key to understand, so I would  expect points from the
> SPRING WG).
>
>
>
> Hi Rishabh,
>
>
>
> I read the appendix A.1 in <draft-voyer-pim-sr-p2mp-policy-02>, and still
> have difficulty to understand the processing of multicast packet.
>
>
>
> When considering SRv6, The “PUSH operation of N-SID6” and the “PUSH
> operation of N-SID7” are not clear to me.
>
>
>
> Seems that <N-SID6,T-SID1> and <N-SID7,T-SID1> are only for SR-MPLS, where
> T-SID1 is locally meaningful, and N-SID is globally reachable.
>
>
>
> I try to understand what’s the shape of each packet – pkt12, pkt23, pkt36,
> pkt25, pkt47 in this example when using SRv6.
>
>
>
>                     R3----(pkt36)----R6
>
>                     /
>
>                  (pkt23)
>
>                   /
>
> *From:* Rishabh Parekh [mailto:[email-masked]]
> *Sent:* Thursday, July 16, 2020 4:46 AM
> *To:* Xiejingrong (Jingrong) <[email-masked]>
> *Cc:* Jeff Tantsura <[email-masked]>; Dhruv Dhody <
> [email-masked]>; [email-masked]; [email-masked];
> Alexander Vainshtein <[email-masked]>

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Fri, 17 Jul 2020 09:27:51 +0000

Hi Rishabh,

Thanks a lot for your confirmation!
Hopefully these clarifications could be reflected in the upcoming update (when they will be WG documents in SPRING and PIM, and congratulations!).
I look forward to further discussions after that.

Thanks
Jingrong

From: Rishabh Parekh [mailto:[email-masked]]
Sent: Friday, July 17, 2020 12:42 AM
To: Xiejingrong (Jingrong) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [spring] Understanding the replication draft

Jingrong,
Your understanding is essentially correct. Think of a Replication function at a node represented by the function portion of SRV6 SID with Replication context either in arg or in the function itself. In the simplest case,as you illustrated, replication to a downstream node is just constructing a SRv6 SID with downstream locator + downstream replication function + replication context (optional) and putting it in the DA of IPv6 packet. If the downstream node is remote and the packet has to take a specific path (not the IGP shortest path) to the node, the downstream replication SID will be somewhere in SRH.

-Rishabh

On Thu, Jul 16, 2020 at 3:45 AM Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>> wrote:
(Though it is in a PIM WG draft (cc’ed), but the terminologies in RFC8402 are used and are the key to understand, so I would  expect points from the SPRING WG).

Hi Rishabh,

                    R3----(pkt36)----R6
                    /
                 (pkt23)
                  /

Is that correct ?

Thanks
Jingrong

From: Rishabh Parekh [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, July 16, 2020 4:46 AM
To: Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>>
Cc: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>; Dhruv Dhody <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Understanding the replication draft

Jingrong,

Replies inline.

-Rishabh