Re: [spring] Updating the SPRING WG Charter

<bruno.decraene@orange.com> Tue, 19 June 2018 12:38 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 239B9130EF7 for <spring@ietfa.amsl.com>; Tue, 19 Jun 2018 05:38:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level:
X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001] autolearn=unavailable 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 JE2IJzoLFTHS for <spring@ietfa.amsl.com>; Tue, 19 Jun 2018 05:38:24 -0700 (PDT)
Received: from orange.com (mta241.mail.business.static.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 56E03130EEE for <spring@ietf.org>; Tue, 19 Jun 2018 05:38:24 -0700 (PDT)
Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 4196vL3xqFz2yqP; Tue, 19 Jun 2018 14:38:22 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 65EBE180072; Tue, 19 Jun 2018 14:38:22 +0200 (CEST)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0399.000; Tue, 19 Jun 2018 14:38:22 +0200
From: bruno.decraene@orange.com
To: Stewart Bryant <stewart.bryant@gmail.com>
CC: Rob Shakir <robjs=40google.com@dmarc.ietf.org>, SPRING WG List <spring@ietf.org>
Thread-Topic: [spring] Updating the SPRING WG Charter
Thread-Index: AQHUB79whKYFtTEYPkCdFk1Vb7W6zaRnfpwA
Date: Tue, 19 Jun 2018 12:38:21 +0000
Message-ID: <26239_1529411902_5B28F93E_26239_344_4_53C29892C857584299CBF5D05346208A47AA5A6B@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <CAHd-QWt+nmQz_R7kE2oeHa2cD88+ndSkpiv56WSFJfHH3PzxRQ@mail.gmail.com> <bac92e67-ef32-8a4a-1f55-a0d43d5004ae@gmail.com>
In-Reply-To: <bac92e67-ef32-8a4a-1f55-a0d43d5004ae@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.2]
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A47AA5A6BOPEXCLILM21corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/M8WlLrHIT6NZZ3yuwZiBYZaUf2Q>
Subject: Re: [spring] Updating the SPRING WG Charter
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.26
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: Tue, 19 Jun 2018 12:38:28 -0000

Hi Stewart,

Speaking as individual contributor, please see inline [Bruno]

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Tuesday, June 19, 2018 1:19 PM





On 01/06/2018 17:05, Rob Shakir wrote:
The SPRING WG defines procedures that allow a node to steer a packet through an
SR Policy instantiated as an ordered list of instructions called segments and
without the need for per-path state information to be held at transit nodes.

I am not sure where the line gets drawn with the per-path state statement. If I introduce a
binding-SID to allow the creation of a path, have I introduced per-path state or not? In practise
a management entity will choose between the infinity of possible binding-SIDs by considering
the need to create specific paths and I would imagine that many will be instantiated just-in-time.

I think that the key point is that the ingress creates the path by using SIDs to create
a concatenation of paths, policies and resources.
[Bruno] Agreed. And it can be argued that this creates a state on the ingress. An “outgoing” state, very roughly comparable to Next Hop Label Forwarding Entry (NHLFE))
However it could be argued that
as soon as we introduced Binding SIDs we introduced per-path state.
[Bruno] Adding a Binding SID to this SR policy introduces an “incoming” state, very roughly comparable to Incoming Label Map (ILM). But this gets additional benefit as it allows others SR nodes to use this state/SR policy.
I’m not sure that in such high level text, we need to make such distinction.
I think we might
be best served by deleting the text I have highlighted.


[Bruno] This text is mostly a copy/past from existing charter so is not really new:

 “allow a node to steer a packet along an explicit
  route using information attached to the packet and
  without the need for per-path state information to be
  held at transit nodes. ”

At high level, I believe that this is a key distinction of spring/segment routing hence worth keeping in the high level introduction of the WG.
Now do we need to add text about more specific details, such as BSID? I’d rather not, as I don’t see what this would bring. I also don’t think that this sentence prohibits the creation of states when required/useful.
--Bruno

- Stewart





_________________________________________________________________________________________________________________________

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.