Re: [spring] draft-voyer-spring-sr-replication-segment-00 //RE: draft-voyer-spring-sr-p2mp-policy-03

Jingrong,

You must have read a completely different document.

>You confirmed “Also the SPRING WG is not really chartered nor have the expertise to define a specification creating a multicast tree”
>But the updated document seems to create a multicast tree.  As above, “stitch multiple replication segments in an SR domain” is creating a multicast tree.
>For simple comparison, mLDP is exactly such thing of “stitching multiple replication segments in a domain”.

Below is text from our draft. Please note the words "outside the scope
of this document."
"Multiple Replication segments can be stitched together to build a
tree in SR domain for Multi-point service; this is outside the scope
of this document."

>You suggested “Re-use the existing SR-policy framework as much as possible”
>But the updated document does not re-use the existing SR-policy. Instead, it “stitches multiple replication segments in an SR domain” seems going opposite to your suggestion.

Again, below is text from the draft which mentions SR policy,
"A Replication branch can also use a Segment Routing Policy
[I-D.ietf-spring-segment-routing-policy], if available, from the
Replication node to the Downstream node."

-Rishabh

On Thu, Nov 14, 2019 at 6:54 PM Xiejingrong (Jingrong)
<xiejingrong@huawei.com> wrote:
>
> Hi Bruno,
>
>
>
> I read the updated draft, draft-voyer-spring-sr-replication-segment-00,  and feel it is not your suggested direction, but the opposite one.
>
>
>
> You suggested “Re-use the existing SR-policy framework as much as possible”
>
> But the updated document does not re-use the existing SR-policy. Instead, it “stitches multiple replication segments in an SR domain” seems going opposite to your suggestion.
>
>
>
> You confirmed “Also the SPRING WG is not really chartered nor have the expertise to define a specification creating a multicast tree”
>
> But the updated document seems to create a multicast tree.  As above, “stitch multiple replication segments in an SR domain” is creating a multicast tree.
>
> For simple comparison, mLDP is exactly such thing of “stitching multiple replication segments in a domain”.
>
>
>
> You said “in particular the handling of topology changes and the avoidance of loops”
>
> But once the “stitching multiple replication segments in an SR domain” is considered/allowed/recommended by SPRING, such topology change things may have to be brought to consideration, I am afraid.
>
>
>
>
>
> Thanks
>
> Jingrong
>
>
>
> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
> Sent: Thursday, August 01, 2019 9:48 PM
> To: SPRING WG List <spring@ietf.org>
> Subject: [spring] draft-voyer-spring-sr-p2mp-policy-03
>
>
>
> Hi authors,
>
>
>
> You have requested WG adoption for draft-voyer-spring-sr-p2mp-policy
>
> https://tools.ietf.org/html/draft-voyer-spring-sr-p2mp-policy-03
>
>
>
> Reviewing the document, I’d like to propose a simplification along two directions:
>
> a)      Re-use the existing SR-policy framework as much as possible
>
> b)      Define the SR replication policy only (aka spray) and make the Tree-SID as out of scope.
>
>
>
> “a” would allow to simplify the text of the draft, enforces that the sr-policy framework is consistent, re-uses all existing behavior from SR-policy. In short, the SR replication policy may possibly be defined as replicating over N  SR-policies.
>
> “b” would remove the specification of Tree-SID. I would argue that Tree-SID is not adequately specified in this document, but rather left to the controller/PCE. Also the SPRING WG is not really chartered nor have the expertise to define a specification creating a multicast tree (in particular the handling of topology changes and the avoidance of loops). Note that you can still introduce the Tree-SID name if you want, e.g. saying can one can built one using one or multiple SR replication policies, but specifying that this is out of scope of this document.
>
>
>
> Please let me know what you think about this.
>
>
>
> On a side note, although this can be addressed after WG adoption, it would be good if the reader of the section “Security Considerations” had the impression that the security considerations have really been considered. E.g. the policies been locally configured so it seems like there is room for configuring inconsistent policies on two nodes, creating a multicast forwarding loops. (Unless may be if you provide enough restrictions in the specification of the SR-replication policy). I’m not necessarily asking for a solution, but at least mentioning the issue.
>
>
>
> Thanks,
>
> Regards,
>
> --Bruno
>
> _________________________________________________________________________________________________________________________
>
>
>
> 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.
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring