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://tools.ietf.org/html/rfc8402>? [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. 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.. 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. 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. 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://datatracker.ietf.org/doc/draft-voyer-pim-sr-p2mp-policy/> draft where PCE instantiates Replication segments. 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 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://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 protected]> Sent: Tuesday, October 15, 2019 6:31 AM To: [email protected]; Clarence Filsfils (cfilsfil) <[email protected]>; Rishabh Parekh (riparekh) <[email protected]>; [email protected]; [email protected] Cc: [email protected] Subject: Some questions regarding Replication SID 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 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. ___________________________________________________________________________
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
