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

<bruno.decraene@orange.com> Thu, 01 August 2019 13:48 UTC

Return-Path: <bruno.decraene@orange.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F06512015A for <spring@ietfa.amsl.com>; Thu, 1 Aug 2019 06:48:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArYCCFnFaJJK for <spring@ietfa.amsl.com>; Thu, 1 Aug 2019 06:48:04 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07C5512008B for <spring@ietf.org>; Thu, 1 Aug 2019 06:48:04 -0700 (PDT)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 45zs7Q2Ldqz8t23 for <spring@ietf.org>; Thu, 1 Aug 2019 15:48:02 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.32]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 45zs7Q1GdJz1xqC for <spring@ietf.org>; Thu, 1 Aug 2019 15:48:02 +0200 (CEST)
Received: from OPEXCAUBM43.corporate.adroot.infra.ftgroup ([fe80::b846:2467:1591:5d9d]) by OPEXCAUBM7C.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Thu, 1 Aug 2019 15:48:02 +0200
From: bruno.decraene@orange.com
To: SPRING WG List <spring@ietf.org>
Thread-Topic: draft-voyer-spring-sr-p2mp-policy-03
Thread-Index: AdVIaRtBY/cci0nYTvuyVv7gUAAM/A==
Date: Thu, 01 Aug 2019 13:48:01 +0000
Message-ID: <20837_1564667282_5D42ED92_20837_34_4_53C29892C857584299CBF5D05346208A48BCF7E1@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A48BCF7E1OPEXCAUBM43corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/JRdMABOp2_EMA3vRYr5pfSPK_hw>
Subject: [spring] draft-voyer-spring-sr-p2mp-policy-03
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Aug 2019 13:48:07 -0000

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.