Subject: [spring] Some questions regarding Replication SID

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 15 Oct 2019 13:30:49 +0000

Dear colleagues,
I have read the Replication SID draft<https://tools.ietf.org/html/draft-voyer-spring-sr-replication-segment-00>, and I have a few questions dealing with possible instantiation of the Replication SOD in SR-MPLS<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-22>.

1.       The draft says that "each branch is abstracted to a <Downstream Node, Downstream Replication-SID>".  Does that mean that the Downstream Replication-SID is one of the SIDs defined in Sections 3, 4 and 5  of RFC8402<https://tools.ietf.org/html/rfc8402>?

2.       The draft also says that "A Replication branch to a particular Downstream Node could be represented by the node's Node SID".  Does this mean that the Replication Node sends the packets it receives with the Replication SID as the active segment with the labels representing the downstream Node SID as the active segment across such a replication branch?

3.       The draft also says that "Replication segment is instantiated at Downstream nodes and at the Replication node".  Does that mean that the list of SIDs associated with the specific replication Branch is pushed by the Replication Node on top of the label representing the Replication SID in the Downstream node of this branch?

4. Are the labels that represent the Replication SID at the Downstream nodes downstream-allocated by these nodes or upstream-allocated by the replication node?

5.       The draft also says that  "A Replication segment can be either provisioned locally on a node or programmed by a PCE". These two options look exactly the same to me from the POV of the node on which the Replication segment is programmed - what, if anything, did I miss?

6.       Did you consider a possibility of advertising the Replication Segment from the Downstream nodes to the Replication one using some multicast routing protocol (e.g., creating a SR-MPLS replacement for mLDP)? Or is such a possibility strictly precluded?

Any details regarding instantiation of the Replication Segment in SR-MPLS would be highly appreciated.

Regards, and lots of thanks in advance,
Sasha

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

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 15 Oct 2019 14:34:45 +0000

Dear colleagues,
More of the same...
Pleade note that if the anser to #3 in my original message is positive, then the statement in the draft that say the Replication Segment is similar to the Binding segment srems to be inaccurate.

My 2c.

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Alexander Vainshtein <[email-masked]>
Sent: Tuesday, October 15, 2019, 16:30
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Some questions regarding Replication SID

Dear colleagues,

1.       The draft says that “each branch is abstracted to a <Downstream Node, Downstream Replication-SID>”.  Does that mean that the Downstream Replication-SID is one of the SIDs defined in Sections 3, 4 and 5  of RFC8402<https://tools.ietf.org/html/rfc8402>?

2.       The draft also says that “A Replication branch to a particular Downstream Node could be represented by the node's Node SID”.  Does this mean that the Replication Node sends the packets it receives with the Replication SID as the active segment with the labels representing the downstream Node SID as the active segment across such a replication branch?

3.       The draft also says that “Replication segment is instantiated at Downstream nodes and at the Replication node”.  Does that mean that the list of SIDs associated with the specific replication Branch is pushed by the Replication Node on top of the label representing the Replication SID in the Downstream node of this branch?

5.       The draft also says that  “A Replication segment can be either provisioned locally on a node or programmed by a PCE”. These two options look exactly the same to me from the POV of the node on which the Replication segment is programmed - what, if anything, did I miss?

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

---

From: "Rishabh Parekh (riparekh)" <[email-masked]>
Date: Wed, 16 Oct 2019 22:23:57 +0000

Alexander,
Responses to your queries are prefaced with [RP].

[RP] No, Replication SID not a topological SID as defined the sections you point to in RFC 8402. Instead, it is a separate SID (label in SR-MPLS) that represents the Replication segment in data plane.

[RP] No, Replication SID relevant at a downstream node would be the bottom label with other SIDs stacked on top which would guide the packet to the downstream node. Of course, if the Downstream node is adjacent to the Replication node, only the Replication SID would be present in the outgoing packet.

[RP] Yes. See response to 2 above.

[RP] Since the Replication SID is locally relevant at a node, the Replication SID would be downstream-allocated. However, it may also be allocated by PCE; see response to 5, 6 below.

[RP] You are right in that it does not matter how Replication segment is instantiated at a node. The use of PCE is relevant for SR P2MP Policy<https://datatracker.ietf.org/doc/draft-voyer-pim-sr-p2mp-policy/> draft where PCE instantiates Replication segments.

[RP] . We do not strictly preclude any protocol , but one of the goals of SR is to simplify. The idea is same here - use replication segments to realize P2MP trees computed by PCE (without need of multicast protocols) as specified in SR P2MP draft

[RP]SR P2MP policy draft lists different protocols (PCEP, BGP, etc.) that can be used to instantiate Replication segments. SR P2MP PCEP<https://tools.ietf.org/html/draft-dhs-spring-pce-sr-p2mp-policy-00> would be updated; other drafts will be published in future.

More of the same...
Pleade note that if the anser to #3 in my original message is positive, then the statement in the draft that say the Replication Segment is similar to the Binding segment srems to be inaccurate.
[RP] Since Replication SID is local to a Node, the Replication SID of the Replication segment at Root (or Headend) node can be used as a (constant) Binding SID to steer traffic into the segment.

-Rishabh

From: Alexander Vainshtein <[email-masked]>
Sent: Tuesday, October 15, 2019 6:31 AM
To: [email-masked]; Clarence Filsfils (cfilsfil) <[email-masked]>; Rishabh Parekh (riparekh) <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Some questions regarding Replication SID

Dear colleagues,

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 17 Oct 2019 05:24:48 +0000

Rishabh,
Lots of thanks for a prompt and detailed response.

Please see more inline below.

Regards,
Sasha

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

From: Rishabh Parekh (riparekh) <[email-masked]>
Sent: Thursday, October 17, 2019 1:24 AM
To: Alexander Vainshtein <[email-masked]>; [email-masked]; Clarence Filsfils (cfilsfil) <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Some questions regarding Replication SID

Alexander,

1. The draft says that "each branch is abstracted to a <Downstream Node, Downstream Replication-SID>".  Does that mean that the Downstream Replication-SID is one of the SIDs defined in Sections 3, 4 and 5  of RFC8402<https://clicktime.symantec.com/3XUuhGHPMpikj1KmCoXg6zn6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8402>?

[[Sasha]] Oops! This question got mangled in the process of writing. Actually I wanted to ask whether the SIDs in the list that represent a specific Replication Branch are the SIDs defined in RFC 8204. The text I see in the SR P2MP Policy<https://tools.ietf.org/html/draft-voyer-pim-sr-p2mp-policy-00> draft seems to suggest that it is not necessarily so  because a Tree-SID is considered also as the Replication SID. This looks inconsistent to me because a Replication SID as defined in this draft is instantiated both in the Replication node and in the Downstream nodes while the Tree-SID does not require instantiation in the Leaf nodes (this is optional).

[RP] No, Replication SID relevant at a downstream node would be the bottom label with other SIDs stacked on top which would guide the packet to the downstream node. Of course, if the Downstream node is adjacent to the Replication node, only the Replication SID would be present in the outgoing packet.[[Sasha]] OK, thanks.

[RP] Yes. See response to 2 above.[[Sasha]] OK, thanks again.

[RP] Since the Replication SID is locally relevant at a node, the Replication SID would be downstream-allocated. However, it may also be allocated by PCE; see response to 5, 6 below.[[Sasha]] OK, thanks.

[RP] You are right in that it does not matter how Replication segment is instantiated at a node. The use of PCE is relevant for SR P2MP Policy<https://clicktime.symantec.com/3BarcmSMhmQoNnLWirtL2F6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-voyer-pim-sr-p2mp-policy%2F> draft where PCE instantiates Replication segments.[[Sasha]] OK, I will  look up the second draft. BTW, it does not appear as a reference in this one - is it intentional?

[RP] . We do not strictly preclude any protocol , but one of the goals of SR is to simplify. The idea is same here - use replication segments to realize P2MP trees computed by PCE (without need of multicast protocols) as specified in SR P2MP draft[[Sasha]] One of the well-known aspects that make multicast different is that the traffic in the Service Provider domain is driven by the dynamic customer requests. Handling these requests via a PCE looks problematic to me.

[RP]SR P2MP policy draft lists different protocols (PCEP, BGP, etc.) that can be used to instantiate Replication segments. SR P2MP PCEP<https://clicktime.symantec.com/3JuFtE8qkd9Viz4Z8BMaLWb6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-dhs-spring-pce-sr-p2mp-policy-00> would be updated; other drafts will be published in future.

More of the same...
Pleade note that if the anser to #3 in my original message is positive, then the statement in the draft that say the Replication Segment is similar to the Binding segment srems to be inaccurate.
[RP] Since Replication SID is local to a Node, the Replication SID of the Replication segment at Root (or Headend) node can be used as a (constant) Binding SID to steer traffic into the segment.
[[Sasha]] The difference between the Binding SID as defined in 8204 and the Replication SID as defined here is that the former is instantiated just locally while the Replication SID is instantiated both in the Replication node and in the Downstream nodes.

-Rishabh

From: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, October 15, 2019 6:31 AM
To: [email-masked]<mailto:[email-masked]>; Clarence Filsfils (cfilsfil) <[email-masked]<mailto:[email-masked]>>; Rishabh Parekh (riparekh) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Some questions regarding Replication SID

Dear colleagues,
I have read the Replication SID draft<https://clicktime.symantec.com/3G11JyktvUDpkKaz5dfYE9E6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-voyer-spring-sr-replication-segment-00>, and I have a few questions dealing with possible instantiation of the Replication SOD in SR-MPLS<https://clicktime.symantec.com/3Hq42mK61kxvw5A1kBS8D1g6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-mpls-22>.

1. The draft says that "each branch is abstracted to a <Downstream Node, Downstream Replication-SID>".  Does that mean that the Downstream Replication-SID is one of the SIDs defined in Sections 3, 4 and 5  of RFC8402<https://clicktime.symantec.com/3XUuhGHPMpikj1KmCoXg6zn6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8402>?

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 17 Oct 2019 05:25:34 +0000

Re-sending with corrected To and CC lists...

Regards,
Sasha

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

From: Alexander Vainshtein
Sent: Thursday, October 17, 2019 8:25 AM
To: [email-masked]
Cc: [email-masked]; Rishabh Parekh (riparekh) <[email-masked]>; Clarence Filsfils (cfilsfil) <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: Some questions regarding Replication SID

Rishabh,

Regards,
Sasha

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

From: Rishabh Parekh (riparekh) <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, October 17, 2019 1:24 AM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Clarence Filsfils (cfilsfil) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: Some questions regarding Replication SID

Alexander,

More of the same...

-Rishabh

Dear colleagues,

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

---

From: "Rishabh Parekh (riparekh)" <[email-masked]>
Date: Thu, 17 Oct 2019 18:37:35 +0000

Sasha,

[RP]I am not sure I completely understand your questions above. Let's break them down and see if my responses clarify them:
Actually I wanted to ask whether the SIDs in the list that represent a specific Replication Branch are the SIDs defined in RFC 8204
[RP] I think my responses to questions 2 and 3 in your original e-mail should make this clear. Let me know if it is not.

The text I see in the SR P2MP Policy<https://tools.ietf.org/html/draft-voyer-pim-sr-p2mp-policy-00> draft seems to suggest that it is not necessarily so  because a Tree-SID is considered also as the Replication SID.
[RP]SR P2MP Policy draft specifies a way to create P2MP trees by stitching Replication Segments together. The Replication SID of the Replication segment at root of a tree is called Tree-SID since this SID allows packets to be replicated across the tree.

This looks inconsistent to me because a Replication SID as defined in this draft is instantiated both in the Replication node and in the Downstream nodes while the Tree-SID does not require instantiation in the Leaf nodes (this is optional).
[RP]Replication segment draft describes how a *single* Replication segment can be used for a Multi-point service. In that case, the Replication SID at downstream nodes (which are the Leaf nodes of the service) is used to derive service context. The P2MP policy draft  makes Replication segments at Leaf nodes OPTIONAL when it is possible to derive service context from some other information in the packet. Thinking more about this, even for the single Replication segment, it might be possible to avoid instantiation at Downstream nodes when service context can be derived from some other information in the packet. We might consider this for next revision.

[RP] You are right in that it does not matter how Replication segment is instantiated at a node. The use of PCE is relevant for SR P2MP Policy<https://clicktime.symantec.com/3BarcmSMhmQoNnLWirtL2F6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-voyer-pim-sr-p2mp-policy%2F> draft where PCE instantiates Replication segments.[[Sasha]] OK, I will  look up the second draft. BTW, it does not appear as a reference in this one - is it intentional?
[RP]The P2MP policy draft uses Replication segment draft as a base, but it is not the other way around. We can add a Informative reference in next revision if you think it will help.

1. Did you consider a possibility of advertising the Replication Segment from the Downstream nodes to the Replication one using some multicast routing protocol (e.g., creating a SR-MPLS replacement for mLDP)? Or is such a possibility strictly precluded?

[RP] . We do not strictly preclude any protocol , but one of the goals of SR is to simplify. The idea is same here - use replication segments to realize P2MP trees computed by PCE (without need of multicast protocols) as specified in SR P2MP draft[[Sasha]] One of the well-known aspects that make multicast different is that the traffic in the Service Provider domain is driven by the dynamic customer requests. Handling these requests via a PCE looks problematic to me.
[RP]SR P2MP MVPN<https://datatracker.ietf.org/doc/draft-parekh-bess-mvpn-sr-p2mp/> draft,  which will be updated soon, specifies procedures for dynamic updates SR P2MP trees using BGP MVPN; this includes dampening procedures to control interaction between PCC (root of tree) and PCE.

Pleade note that if the anser to #3 in my original message is positive, then the statement in the draft that say the Replication Segment is similar to the Binding segment srems to be inaccurate.
[RP] Since Replication SID is local to a Node, the Replication SID of the Replication segment at Root (or Headend) node can be used as a (constant) Binding SID to steer traffic into the segment.
[[Sasha]] The difference between the Binding SID as defined in 8204 and the Replication SID as defined here is that the former is instantiated just locally while the Replication SID is instantiated both in the Replication node and in the Downstream nodes.
[RP]Here we use "Binding SID" to denote that fact that Replication SID (or Tree-SID for P2MP trees) at the Root MAY be used as a constant SID that allows packets to be steered into a Replication segment or a P2MP tree. Note the drafts do not exclude the possibility that Replication SIDs at downstream nodes or non-Root Replication segments can change.

-Rishabh

From: Alexander Vainshtein <[email-masked]>
Sent: Wednesday, October 16, 2019 10:26 PM
To: Rishabh Parekh (riparekh) <[email-masked]>
Cc: [email-masked]; Clarence Filsfils (cfilsfil) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Some questions regarding Replication SID

Regards,
Sasha

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

From: Alexander Vainshtein
Sent: Thursday, October 17, 2019 8:25 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Rishabh Parekh (riparekh) <[email-masked]<mailto:[email-masked]>>; Clarence Filsfils (cfilsfil) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Some questions regarding Replication SID

Rishabh,

Regards,
Sasha

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

Alexander,

More of the same...

-Rishabh

Dear colleagues,

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 22 Oct 2019 14:30:09 +0000

Rishabh,
Lots of thanks for a prompt response and apologies for the delays.

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

From: Rishabh Parekh (riparekh) <[email-masked]>
Sent: Thursday, October 17, 2019 9:38 PM
To: Alexander Vainshtein <[email-masked]>
Cc: [email-masked]; Clarence Filsfils (cfilsfil) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Some questions regarding Replication SID

Sasha,

[[Sasha]] Oops! This question got mangled in the process of writing. Actually I wanted to ask whether the SIDs in the list that represent a specific Replication Branch are the SIDs defined in RFC 8204. The text I see in the SR P2MP Policy<https://clicktime.symantec.com/3KYcTh6w8kroEVd6FFNtXYc6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-voyer-pim-sr-p2mp-policy-00> draft seems to suggest that it is not necessarily so  because a Tree-SID is considered also as the Replication SID. This looks inconsistent to me because a Replication SID as defined in this draft is instantiated both in the Replication node and in the Downstream nodes while the Tree-SID does not require instantiation in the Leaf nodes (this is optional).

The text I see in the SR P2MP Policy<https://clicktime.symantec.com/3KYcTh6w8kroEVd6FFNtXYc6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-voyer-pim-sr-p2mp-policy-00> draft seems to suggest that it is not necessarily so  because a Tree-SID is considered also as the Replication SID.
[RP]SR P2MP Policy draft specifies a way to create P2MP trees by stitching Replication Segments together. The Replication SID of the Replication segment at root of a tree is called Tree-SID since this SID allows packets to be replicated across the tree.

This looks inconsistent to me because a Replication SID as defined in this draft is instantiated both in the Replication node and in the Downstream nodes while the Tree-SID does not require instantiation in the Leaf nodes (this is optional).
[RP]Replication segment draft describes how a *single* Replication segment can be used for a Multi-point service. In that case, the Replication SID at downstream nodes (which are the Leaf nodes of the service) is used to derive service context. The P2MP policy draft  makes Replication segments at Leaf nodes OPTIONAL when it is possible to derive service context from some other information in the packet. Thinking more about this, even for the single Replication segment, it might be possible to avoid instantiation at Downstream nodes when service context can be derived from some other information in the packet. We might consider this for next revision.
[[Sasha]] I am confused now. From my POV either the Replication SID MUST be represented both in the Replication node and in all Downstream nodes, or it MUST be local for the Replication Node only. In the first case its handling effectively is CONTINUE in each Replication Branch, in the second case it is NEXT in each Replication Branch. I do not see how you can have two different kinds of handling for the same type of SID.

[RP] You are right in that it does not matter how Replication segment is instantiated at a node. The use of PCE is relevant for SR P2MP Policy<https://clicktime.symantec.com/3BarcmSMhmQoNnLWirtL2F6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-voyer-pim-sr-p2mp-policy%2F> draft where PCE instantiates Replication segments.[[Sasha]] OK, I will  look up the second draft. BTW, it does not appear as a reference in this one - is it intentional?
[RP]The P2MP policy draft uses Replication segment draft as a base, but it is not the other way around. We can add a Informative reference in next revision if you think it will help.[[Sasha]] It would help IMHO.

[RP] . We do not strictly preclude any protocol , but one of the goals of SR is to simplify. The idea is same here - use replication segments to realize P2MP trees computed by PCE (without need of multicast protocols) as specified in SR P2MP draft[[Sasha]] One of the well-known aspects that make multicast different is that the traffic in the Service Provider domain is driven by the dynamic customer requests. Handling these requests via a PCE looks problematic to me.
[RP]SR P2MP MVPN<https://clicktime.symantec.com/329erDXYCoUNudUpd4NoApR6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-parekh-bess-mvpn-sr-p2mp%2F> draft,  which will be updated soon, specifies procedures for dynamic updates SR P2MP trees using BGP MVPN; this includes dampening procedures to control interaction between PCC (root of tree) and PCE.
[[Sasha]] I will look up this draft as well.

Pleade note that if the anser to #3 in my original message is positive, then the statement in the draft that say the Replication Segment is similar to the Binding segment srems to be inaccurate.
[RP] Since Replication SID is local to a Node, the Replication SID of the Replication segment at Root (or Headend) node can be used as a (constant) Binding SID to steer traffic into the segment.
[[Sasha]] The difference between the Binding SID as defined in 8204 and the Replication SID as defined here is that the former is instantiated just locally while the Replication SID is instantiated both in the Replication node and in the Downstream nodes.
[RP]Here we use "Binding SID" to denote that fact that Replication SID (or Tree-SID for P2MP trees) at the Root MAY be used as a constant SID that allows packets to be steered into a Replication segment or a P2MP tree. Note the drafts do not exclude the possibility that Replication SIDs at downstream nodes or non-Root Replication segments can change.[[Sasha]] Please see above.

-Rishabh

From: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, October 16, 2019 10:26 PM
To: Rishabh Parekh (riparekh) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Clarence Filsfils (cfilsfil) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Some questions regarding Replication SID

Regards,
Sasha

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

Rishabh,

Regards,
Sasha

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

Alexander,

[[Sasha]] Oops! This question got mangled in the process of writing. Actually I wanted to ask whether the SIDs in the list that represent a specific Replication Branch are the SIDs defined in RFC 8204. The text I see in the SR P2MP Policy<https://clicktime.symantec.com/3KYcTh6w8kroEVd6FFNtXYc6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-voyer-pim-sr-p2mp-policy-00> draft seems to suggest that it is not necessarily so  because a Tree-SID is considered also as the Replication SID. This looks inconsistent to me because a Replication SID as defined in this draft is instantiated both in the Replication node and in the Downstream nodes while the Tree-SID does not require instantiation in the Leaf nodes (this is optional).

More of the same...

-Rishabh

Dear colleagues,

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

---

From: "Rishabh Parekh (riparekh)" <[email-masked]>
Date: Tue, 22 Oct 2019 17:25:09 +0000

Sasha,

I definitely did not intend to confuse you! Sometimes such discussion can get quite esoteric and written word (as compared to say whiteboard diagram) is not the best medium, but let me try to clarify. If you wish, we can schedule a conference call to discuss further.

Typically, for any multicast transport, it is not possible to carry a downstream assigned service context (VPN label) in the label stack (since it is difficult to orchestrate all the Leaf nodes to assign same value for the context). So, the transport label (Replication SID) is used to derive the service context. This requires Replication SID to be instantiated on the Leaf nodes and as you say, the Replication node performs CONTINUE operation. However, if the service context can be assigned globally (for e.g. DCB from https://tools.ietf.org/html/draft-ietf-bess-mvpn-evpn-aggregation-label-02), then Replication SID is not strictly required at Leaf nodes and therefore Replication node can perform NEXT operation. Some of these details are covered in Section 2.1 of the P2MP policy draft.

-Rishabh

Sent: Tuesday, October 22, 2019 7:30 AM

Rishabh,

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

To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>

Sasha,

-Rishabh

Regards,
Sasha

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

Rishabh,

Regards,
Sasha

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

Alexander,

More of the same...

-Rishabh

Dear colleagues,

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 24 Oct 2019 08:05:38 +0000

Rishabh,
Again lots of thanks for a prompt and very informative response.

My problem with this response that, from my POV, you implicitly define two different flavors of the Replication SID:

-          One of these flavors MUST be instantiated both in the Replication Node and in the Downstream nodes, so that it CONTINUEs in each specific Replication Branch

-          The other flavor MUST NOT be instantiated in the Replication Node bot MUST NOT be instantiated in the Downstream nodes so that the Replication Node treats it as NEXT in each Replication branch.

I understand why each of these flavors may be useful,. However, with the difference being implicit, this is apt to raise some issues, e.g.: can the same Replication SID be treated by the Replication Bode as CONTINUE in some of its Replication Branches and as NEXT - in some other ones? Unless I have missed something, nothing in the current text of the draft prevents such a mix. Is this indeed your intention?

BTW, the MVPN Aggregation Label draft<https://tools.ietf.org/html/draft-ietf-bess-mvpn-evpn-aggregation-label-02> that you have mentioned has expired. Do you happen know if the authors intend to revive it?

Regards,
Sasha

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

Sent: Tuesday, October 22, 2019 8:25 PM

Sasha,

Typically, for any multicast transport, it is not possible to carry a downstream assigned service context (VPN label) in the label stack (since it is difficult to orchestrate all the Leaf nodes to assign same value for the context). So, the transport label (Replication SID) is used to derive the service context. This requires Replication SID to be instantiated on the Leaf nodes and as you say, the Replication node performs CONTINUE operation. However, if the service context can be assigned globally (for e.g. DCB from https://tools.ietf.org/html/draft-ietf-bess-mvpn-evpn-aggregation-label-02<https://clicktime.symantec.com/32QsG9Cr65bx26TTfRS6U876H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-bess-mvpn-evpn-aggregation-label-02>), then Replication SID is not strictly required at Leaf nodes and therefore Replication node can perform NEXT operation. Some of these details are covered in Section 2.1 of the P2MP policy draft.

-Rishabh

Rishabh,

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

Sasha,

-Rishabh

Regards,
Sasha

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

Rishabh,

Regards,
Sasha

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

Alexander,

More of the same...

-Rishabh

Dear colleagues,

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 24 Oct 2019 09:40:09 +0000

Rishabh,
FYI, the MVPN Aggregation Label draft has been updated just now.

Regards,
Sasha

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

Sent: Thursday, October 24, 2019 11:06 AM

Rishabh,

Regards,
Sasha

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

Sasha,

-Rishabh

Rishabh,

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

Sasha,

-Rishabh

Regards,
Sasha

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

Rishabh,

Regards,
Sasha

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

Alexander,

More of the same...

-Rishabh

Dear colleagues,

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

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 24 Oct 2019 09:46:18 +0000

Yes – thanks for the reminder that it expired 😊

If I understand your questions correctly, a replication SID can have the CONTINUE/NEXT semantic at the same time. A node could be a “bud node” – a leaf and a replication node at the same time. This is unique to multicast.

Jeffrey

From: Alexander Vainshtein <[email-masked]>
Sent: Thursday, October 24, 2019 5:40 AM
To: Rishabh Parekh (riparekh) <[email-masked]>
Cc: [email-masked]; Clarence Filsfils (cfilsfil) <[email-masked]>; [email-masked]; Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]
Subject: RE: Some questions regarding Replication SID

Rishabh,

Regards,
Sasha

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

Rishabh,

  *   One of these flavors MUST be instantiated both in the Replication Node and in the Downstream nodes, so that it CONTINUEs in each specific Replication Branch
  *   The other flavor MUST NOT be instantiated in the Replication Node bot MUST NOT be instantiated in the Downstream nodes so that the Replication Node treats it as NEXT in each Replication branch.

I understand why each of these flavors may be useful,. However, with the difference being implicit, this is apt to raise some issues, e.g.: can the same Replication SID be treated by the Replication Bode as CONTINUE in some of its Replication Branches and as NEXT – in some other ones? Unless I have missed something, nothing in the current text of the draft prevents such a mix. Is this indeed your intention?

BTW, the MVPN Aggregation Label draft<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-bess-mvpn-evpn-aggregation-label-02__;!8WoA6RjC81c!WpedzHsJqbe9wRgtWVjDi4NPIFrQvUGCPyh_HgCLAzMbVnmKwxr4OfwekrtnkM6B$> that you have mentioned has expired. Do you happen know if the authors intend to revive it?

Regards,
Sasha

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

Sasha,

Typically, for any multicast transport, it is not possible to carry a downstream assigned service context (VPN label) in the label stack (since it is difficult to orchestrate all the Leaf nodes to assign same value for the context). So, the transport label (Replication SID) is used to derive the service context. This requires Replication SID to be instantiated on the Leaf nodes and as you say, the Replication node performs CONTINUE operation. However, if the service context can be assigned globally (for e.g. DCB from https://tools.ietf.org/html/draft-ietf-bess-mvpn-evpn-aggregation-label-02<https://urldefense.com/v3/__https:/clicktime.symantec.com/32QsG9Cr65bx26TTfRS6U876H2?u=https*3A*2F*2Ftools.ietf.org*2Fhtml*2Fdraft-ietf-bess-mvpn-evpn-aggregation-label-02__;JSUlJSU!8WoA6RjC81c!WpedzHsJqbe9wRgtWVjDi4NPIFrQvUGCPyh_HgCLAzMbVnmKwxr4OfwekkITvVvq$>), then Replication SID is not strictly required at Leaf nodes and therefore Replication node can perform NEXT operation. Some of these details are covered in Section 2.1 of the P2MP policy draft.

-Rishabh

Rishabh,

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

Sasha,

1. The draft says that “each branch is abstracted to a <Downstream Node, Downstream Replication-SID>”.  Does that mean that the Downstream Replication-SID is one of the SIDs defined in Sections 3, 4 and 5  of RFC8402<https://urldefense.com/v3/__https:/clicktime.symantec.com/3XUuhGHPMpikj1KmCoXg6zn6H2?u=https*3A*2F*2Ftools.ietf.org*2Fhtml*2Frfc8402__;JSUlJSU!8WoA6RjC81c!WpedzHsJqbe9wRgtWVjDi4NPIFrQvUGCPyh_HgCLAzMbVnmKwxr4OfwekhtXHv9o$>?

[[Sasha]] Oops! This question got mangled in the process of writing. Actually I wanted to ask whether the SIDs in the list that represent a specific Replication Branch are the SIDs defined in RFC 8204. The text I see in the SR P2MP Policy<https://urldefense.com/v3/__https:/clicktime.symantec.com/3KYcTh6w8kroEVd6FFNtXYc6H2?u=https*3A*2F*2Ftools.ietf.org*2Fhtml*2Fdraft-voyer-pim-sr-p2mp-policy-00__;JSUlJSU!8WoA6RjC81c!WpedzHsJqbe9wRgtWVjDi4NPIFrQvUGCPyh_HgCLAzMbVnmKwxr4OfweklEVfFzb$> draft seems to suggest that it is not necessarily so  because a Tree-SID is considered also as the Replication SID. This looks inconsistent to me because a Replication SID as defined in this draft is instantiated both in the Replication node and in the Downstream nodes while the Tree-SID does not require instantiation in the Leaf nodes (this is optional).

[RP]I am not sure I completely understand your questions above. Let’s break them down and see if my responses clarify them:
Actually I wanted to ask whether the SIDs in the list that represent a specific Replication Branch are the SIDs defined in RFC 8204
[RP] I think my responses to questions 2 and 3 in your original e-mail should make this clear. Let me know if it is not.

The text I see in the SR P2MP Policy<https://urldefense.com/v3/__https:/clicktime.symantec.com/3KYcTh6w8kroEVd6FFNtXYc6H2?u=https*3A*2F*2Ftools.ietf.org*2Fhtml*2Fdraft-voyer-pim-sr-p2mp-policy-00__;JSUlJSU!8WoA6RjC81c!WpedzHsJqbe9wRgtWVjDi4NPIFrQvUGCPyh_HgCLAzMbVnmKwxr4OfweklEVfFzb$> draft seems to suggest that it is not necessarily so  because a Tree-SID is considered also as the Replication SID.
[RP]SR P2MP Policy draft specifies a way to create P2MP trees by stitching Replication Segments together. The Replication SID of the Replication segment at root of a tree is called Tree-SID since this SID allows packets to be replicated across the tree.

[RP] You are right in that it does not matter how Replication segment is instantiated at a node. The use of PCE is relevant for SR P2MP Policy<https://urldefense.com/v3/__https:/clicktime.symantec.com/3BarcmSMhmQoNnLWirtL2F6H2?u=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-voyer-pim-sr-p2mp-policy*2F__;JSUlJSUl!8WoA6RjC81c!WpedzHsJqbe9wRgtWVjDi4NPIFrQvUGCPyh_HgCLAzMbVnmKwxr4Ofweksb7Ia-s$> draft where PCE instantiates Replication segments.[[Sasha]] OK, I will  look up the second draft. BTW, it does not appear as a reference in this one – is it intentional?
[RP]The P2MP policy draft uses Replication segment draft as a base, but it is not the other way around. We can add a Informative reference in next revision if you think it will help.[[Sasha]] It would help IMHO.

[RP] . We do not strictly preclude any protocol , but one of the goals of SR is to simplify. The idea is same here - use replication segments to realize P2MP trees computed by PCE (without need of multicast protocols) as specified in SR P2MP draft[[Sasha]] One of the well-known aspects that make multicast different is that the traffic in the Service Provider domain is driven by the dynamic customer requests. Handling these requests via a PCE looks problematic to me.
[RP]SR P2MP MVPN<https://urldefense.com/v3/__https:/clicktime.symantec.com/329erDXYCoUNudUpd4NoApR6H2?u=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-parekh-bess-mvpn-sr-p2mp*2F__;JSUlJSUl!8WoA6RjC81c!WpedzHsJqbe9wRgtWVjDi4NPIFrQvUGCPyh_HgCLAzMbVnmKwxr4Ofweks4fpBTQ$> draft,  which will be updated soon, specifies procedures for dynamic updates SR P2MP trees using BGP MVPN; this includes dampening procedures to control interaction between PCC (root of tree) and PCE.
[[Sasha]] I will look up this draft as well.

Pleade note that if the anser to #3 in my original message is positive, then the statement in the draft that say the Replication Segment is similar to the Binding segment srems to be inaccurate.
[RP] Since Replication SID is local to a Node, the Replication SID of the Replication segment at Root (or Headend) node can be used as a (constant) Binding SID to steer traffic into the segment.
[[Sasha]] The difference between the Binding SID as defined in 8204 and the Replication SID as defined here is that the former is instantiated just locally while the Replication SID is instantiated both in the Replication node and in the Downstream nodes.
[RP]Here we use “Binding SID” to denote that fact that Replication SID (or Tree-SID for P2MP trees) at the Root MAY be used as a constant SID that allows packets to be steered into a Replication segment or a P2MP tree. Note the drafts do not exclude the possibility that Replication SIDs at downstream nodes or non-Root Replication segments can change.[[Sasha]] Please see above.

-Rishabh

Regards,
Sasha

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

Rishabh,

Regards,
Sasha

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

Alexander,

1. The draft says that “each branch is abstracted to a <Downstream Node, Downstream Replication-SID>”.  Does that mean that the Downstream Replication-SID is one of the SIDs defined in Sections 3, 4 and 5  of RFC8402<https://urldefense.com/v3/__https:/clicktime.symantec.com/3XUuhGHPMpikj1KmCoXg6zn6H2?u=https*3A*2F*2Ftools.ietf.org*2Fhtml*2Frfc8402__;JSUlJSU!8WoA6RjC81c!WpedzHsJqbe9wRgtWVjDi4NPIFrQvUGCPyh_HgCLAzMbVnmKwxr4OfwekhtXHv9o$>?

[[Sasha]] Oops! This question got mangled in the process of writing. Actually I wanted to ask whether the SIDs in the list that represent a specific Replication Branch are the SIDs defined in RFC 8204. The text I see in the SR P2MP Policy<https://urldefense.com/v3/__https:/clicktime.symantec.com/3KYcTh6w8kroEVd6FFNtXYc6H2?u=https*3A*2F*2Ftools.ietf.org*2Fhtml*2Fdraft-voyer-pim-sr-p2mp-policy-00__;JSUlJSU!8WoA6RjC81c!WpedzHsJqbe9wRgtWVjDi4NPIFrQvUGCPyh_HgCLAzMbVnmKwxr4OfweklEVfFzb$> draft seems to suggest that it is not necessarily so  because a Tree-SID is considered also as the Replication SID. This looks inconsistent to me because a Replication SID as defined in this draft is instantiated both in the Replication node and in the Downstream nodes while the Tree-SID does not require instantiation in the Leaf nodes (this is optional).

[RP] You are right in that it does not matter how Replication segment is instantiated at a node. The use of PCE is relevant for SR P2MP Policy<https://urldefense.com/v3/__https:/clicktime.symantec.com/3BarcmSMhmQoNnLWirtL2F6H2?u=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-voyer-pim-sr-p2mp-policy*2F__;JSUlJSUl!8WoA6RjC81c!WpedzHsJqbe9wRgtWVjDi4NPIFrQvUGCPyh_HgCLAzMbVnmKwxr4Ofweksb7Ia-s$> draft where PCE instantiates Replication segments.[[Sasha]] OK, I will  look up the second draft. BTW, it does not appear as a reference in this one – is it intentional?

[RP]SR P2MP policy draft lists different protocols (PCEP, BGP, etc.) that can be used to instantiate Replication segments. SR P2MP PCEP<https://urldefense.com/v3/__https:/clicktime.symantec.com/3JuFtE8qkd9Viz4Z8BMaLWb6H2?u=https*3A*2F*2Ftools.ietf.org*2Fhtml*2Fdraft-dhs-spring-pce-sr-p2mp-policy-00__;JSUlJSU!8WoA6RjC81c!WpedzHsJqbe9wRgtWVjDi4NPIFrQvUGCPyh_HgCLAzMbVnmKwxr4OfwekgqDgKyL$> would be updated; other drafts will be published in future.

More of the same...

-Rishabh

Dear colleagues,
I have read the Replication SID draft<https://urldefense.com/v3/__https:/clicktime.symantec.com/3G11JyktvUDpkKaz5dfYE9E6H2?u=https*3A*2F*2Ftools.ietf.org*2Fhtml*2Fdraft-voyer-spring-sr-replication-segment-00__;JSUlJSU!8WoA6RjC81c!WpedzHsJqbe9wRgtWVjDi4NPIFrQvUGCPyh_HgCLAzMbVnmKwxr4Ofwekhycn3Th$>, and I have a few questions dealing with possible instantiation of the Replication SOD in SR-MPLS<https://urldefense.com/v3/__https:/clicktime.symantec.com/3Hq42mK61kxvw5A1kBS8D1g6H2?u=https*3A*2F*2Ftools.ietf.org*2Fhtml*2Fdraft-ietf-spring-segment-routing-mpls-22__;JSUlJSU!8WoA6RjC81c!WpedzHsJqbe9wRgtWVjDi4NPIFrQvUGCPyh_HgCLAzMbVnmKwxr4OfwekiItVBoo$>.

1. The draft says that “each branch is abstracted to a <Downstream Node, Downstream Replication-SID>”.  Does that mean that the Downstream Replication-SID is one of the SIDs defined in Sections 3, 4 and 5  of RFC8402<https://urldefense.com/v3/__https:/clicktime.symantec.com/3XUuhGHPMpikj1KmCoXg6zn6H2?u=https*3A*2F*2Ftools.ietf.org*2Fhtml*2Frfc8402__;JSUlJSU!8WoA6RjC81c!WpedzHsJqbe9wRgtWVjDi4NPIFrQvUGCPyh_HgCLAzMbVnmKwxr4OfwekhtXHv9o$>?

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

---

From: "Rishabh Parekh (riparekh)" <[email-masked]>
Date: Thu, 24 Oct 2019 17:59:02 +0000

Sasha,

Certainly, we did not intend to implicitly mix different types of Replication segments. Replication segment as defined and used in the SPRING draft needs instantiation on Replication node and downstream nodes.

In SR P2MP policy draft, Replication segments can be omitted at Leaf nodes P2MP trees when global contexts, like DCB, are in use or when Replication segments are shared across P2MP trees. As described in the draft, PCE constructs trees by stitching and instantiating Replication segments at Replication nodes. Assuming PCE is aware of pre requisites (like DCB), it can program a Replication with NEXT or CONTINUE as appropriate. And as Jeffrey pointed out, at Bud-Nodes, a Replication segment has to effectively perform NEXT + CONTINUE operation.

-Rishabh

From: Jeffrey (Zhaohui) Zhang <[email-masked]>
Sent: Thursday, October 24, 2019 2:46 AM
To: Alexander Vainshtein <[email-masked]>; Rishabh Parekh (riparekh) <[email-masked]>
Cc: [email-masked]; Clarence Filsfils (cfilsfil) <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: Some questions regarding Replication SID

Jeffrey

Cc: [email-masked]<mailto:[email-masked]>; Clarence Filsfils (cfilsfil) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Rishabh,

Regards,
Sasha

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

Rishabh,

Regards,
Sasha

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

Sasha,

-Rishabh

Rishabh,

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

Sasha,

-Rishabh

Regards,
Sasha

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

Rishabh,

Regards,
Sasha

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

Alexander,

More of the same...

-Rishabh

Dear colleagues,

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