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

Please see more inline below.
Regards,
Sasha

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

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

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://clicktime.symantec.com/3XUuhGHPMpikj1KmCoXg6zn6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8402>?

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

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

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


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://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 protected]<mailto:[email protected]>>
Sent: Wednesday, October 16, 2019 10:26 PM
To: Rishabh Parekh (riparekh) <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; Clarence Filsfils (cfilsfil) 
<[email protected]<mailto:[email protected]>>; 
[email protected]<mailto:[email protected]>; 
[email protected]<mailto:[email protected]>; 
[email protected]<mailto:[email protected]>
Subject: RE: Some questions regarding Replication SID

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

Regards,
Sasha

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

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

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

Please see more inline below.

Regards,
Sasha

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

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

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


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

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

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



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?

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



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?

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



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?

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



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?

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



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?

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



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

[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 protected]<mailto:[email protected]>>
Sent: Tuesday, October 15, 2019 6:31 AM
To: [email protected]<mailto:[email protected]>; Clarence Filsfils 
(cfilsfil) <[email protected]<mailto:[email protected]>>; Rishabh Parekh 
(riparekh) <[email protected]<mailto:[email protected]>>; 
[email protected]<mailto:[email protected]>; 
[email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>
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>?

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 protected]<mailto:[email protected]>


___________________________________________________________________________

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

___________________________________________________________________________

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

___________________________________________________________________________

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.
___________________________________________________________________________
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring

Reply via email to