Hi Bruno,

Yes, we are currently reviewing and working on simplifying the draft. We will 
submit a new draft in September.

Thanks,
Dan



From: spring <[email protected]> on behalf of Bruno Decraene 
<[email protected]>
Date: Thursday, August 1, 2019 at 9:48 AM
To: SPRING WG List <[email protected]>
Subject: [EXT][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:

  1.  Re-use the existing SR-policy framework as much as possible
  2.  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
[email protected]
https://www.ietf.org/mailman/listinfo/spring

Reply via email to