Re: [spring] draft-voyer-spring-sr-p2mp-policy-03

[Xiejingrong <[e-mail]>]

Completely agree with Bruno.
I have raised similar comments on the list 3 weeks ago.


(1)     To let an SR Replication policy be a variant of an SR policy, SR-policy framework should be inherited as much as possible.

(2)     Building of a tree is really outside the scope of the group.

(3)     If one want to have many names,  SR-P2MP, Tree-SID for the same thing "SR Replication Policy", I have no objection too.

(4)     But if the TreeSID means "Tree building" and bound to an SID, then it goes to (2).


Thanks
Jingrong

From: spring [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Thursday, August 01, 2019 9:48 PM
To: SPRING WG List <[e-mail]>
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.