Re: [spring] Updating the SPRING WG Charter

David Allan I <david.i.allan@ericsson.com> Tue, 19 June 2018 15:53 UTC

Return-Path: <david.i.allan@ericsson.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 4ADF5130DEC for <spring@ietfa.amsl.com>; Tue, 19 Jun 2018 08:53:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=ASwB2z/m; dkim=pass (1024-bit key) header.d=ericsson.com header.b=cDYTJaN+
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 wML-x3LZxQuc for <spring@ietfa.amsl.com>; Tue, 19 Jun 2018 08:53:09 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCC00130DE8 for <spring@ietf.org>; Tue, 19 Jun 2018 08:53:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1529423587; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=eqY6AZ/tC7ojN2dVMRmGcbh3hC0eHfsLGpwp1FL5zcE=; b=ASwB2z/m90ogbNMv74lpk76n2rXEZrwmqc1/pTAz9GlRCFnZ7zq5qc4asUxfyI9h EUgG8pc+DxDwH0dzMN8DAWPclgcJCk6XR2AzRH2lVujtJpP75YvHRUYunxBtmWsD +RCkCc2NJKGk78hxDgESOBduAaK24Uk4CiG+jfQ8cEY=;
X-AuditID: c1b4fb25-59dff70000007b3f-45-5b2926e3476c
Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 34.29.31551.3E6292B5; Tue, 19 Jun 2018 17:53:07 +0200 (CEST)
Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 19 Jun 2018 17:53:07 +0200
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 19 Jun 2018 17:53:06 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eqY6AZ/tC7ojN2dVMRmGcbh3hC0eHfsLGpwp1FL5zcE=; b=cDYTJaN+5x0zf0Yre5DUGWmFvFmFFlh9zdhAJIuLbuMHqyu77D7oZsF/AGY4uE+gZ+FpRXE8bsG36A3wLm3Ei4k1KLLWJo2wRw1PFYYjBxqCCBSixHCSHhdUilewRDTU/sdCHNmTTFplKJs4OyQ7Qkj157aBxBDmHnLEkAlK+qg=
Received: from CY1PR15MB0874.namprd15.prod.outlook.com (10.169.22.140) by CY1PR15MB0476.namprd15.prod.outlook.com (10.163.235.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.19; Tue, 19 Jun 2018 15:53:03 +0000
Received: from CY1PR15MB0874.namprd15.prod.outlook.com ([fe80::d0bf:1d2d:cc85:d384]) by CY1PR15MB0874.namprd15.prod.outlook.com ([fe80::d0bf:1d2d:cc85:d384%3]) with mapi id 15.20.0863.016; Tue, 19 Jun 2018 15:53:03 +0000
From: David Allan I <david.i.allan@ericsson.com>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, "bruno.decraene@orange.com" <bruno.decraene@orange.com>, Stewart Bryant <stewart.bryant@gmail.com>
CC: SPRING WG List <spring@ietf.org>, Rob Shakir <robjs=40google.com@dmarc.ietf.org>
Thread-Topic: [spring] Updating the SPRING WG Charter
Thread-Index: AQHT+cJ3A9n9vmSmI0OHY+JQTfmEh6RnixuAgAAWMICAABCTgIAAFrsg
Date: Tue, 19 Jun 2018 15:53:03 +0000
Message-ID: <CY1PR15MB0874997DACCDD446AE17DD34D0700@CY1PR15MB0874.namprd15.prod.outlook.com>
References: <CAHd-QWt+nmQz_R7kE2oeHa2cD88+ndSkpiv56WSFJfHH3PzxRQ@mail.gmail.com> <bac92e67-ef32-8a4a-1f55-a0d43d5004ae@gmail.com> <26239_1529411902_5B28F93E_26239_344_4_53C29892C857584299CBF5D05346208A47AA5A6B@OPEXCLILM21.corporate.adroot.infra.ftgroup> <DB5PR0301MB1909BBE9EBF3D0F14F9302259D700@DB5PR0301MB1909.eurprd03.prod.outlook.com>
In-Reply-To: <DB5PR0301MB1909BBE9EBF3D0F14F9302259D700@DB5PR0301MB1909.eurprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.i.allan@ericsson.com;
x-originating-ip: [2601:646:8084:458:61dd:cb61:60bc:1934]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY1PR15MB0476; 7:IHgd1X5NbOcNS5nOXFPiz3A3KcFJ+Bk+2pEauXWHwg7hNzU6PvUNPZMrWInAUXCr8jJ99uBVuqaasT1I6CRSoLpmFwjudBMoRZML/WHker87ypURxR9gL2NbeS9sSikjf9zrcdkETNUqZjdrSKum2Er+yaWhqk4Wwgvzfv2fS/OO+BT202fDD98BaBDlBiZR5gY8mmHgOLb0aAVhlvhEJ6OJ/pUVy2S53/zYGo7CYwbMeMR9L6L/yWb6+AD3UfST
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: b0287425-04a1-4152-3fd4-08d5d5fcbde8
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:CY1PR15MB0476;
x-ms-traffictypediagnostic: CY1PR15MB0476:
x-microsoft-antispam-prvs: <CY1PR15MB0476E017929752B8F7F86D84D0700@CY1PR15MB0476.namprd15.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(85827821059158)(18271650672692)(21748063052155)(279101305709854);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231254)(944501410)(52105095)(93006095)(93001095)(3002001)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:CY1PR15MB0476; BCL:0; PCL:0; RULEID:; SRVR:CY1PR15MB0476;
x-forefront-prvs: 07083FF734
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(376002)(39860400002)(346002)(396003)(366004)(57704003)(199004)(189003)(51444003)(252514010)(53546011)(33656002)(2906002)(3280700002)(59450400001)(102836004)(8676002)(478600001)(6436002)(97736004)(55016002)(81166006)(81156014)(3660700001)(93886005)(8936002)(54906003)(68736007)(6506007)(14454004)(2900100001)(7696005)(76176011)(4326008)(110136005)(229853002)(9326002)(105586002)(86362001)(46003)(54896002)(106356001)(6306002)(606006)(790700001)(6116002)(476003)(316002)(11346002)(486006)(53936002)(25786009)(5250100002)(446003)(9686003)(236005)(186003)(5890100001)(2501003)(7736002)(39060400002)(5660300001)(6246003)(99286004)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR15MB0476; H:CY1PR15MB0874.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: cEzvIC4fdWI1F89L4W4zrVbM1J+m5NK6bK/3O5swusqhnNxi9KlwLdndZOQIuUW0tEa+LHKixzQsCF7PsmPBiDK4/KlVGzhMWjnFK8bIrOlZEPKLtjPMKX5MmkjUk5pixV3kvBhs7KGnXu8z+UUYAfyqQ1jXk4mOTfm/Mvaby4HYDSgLKu9TIhS9oZeVA6QsVzUaZOwJQ6+/TLv1bMP1Yg30hphdaRxY7yLZnyabqvzGTHyCJ8zuNWt3IfmuXNLWdpw1FDMdnv7gPBr6+kOEv1aNkyJ3vS0USv1vt8YuvW/F2/qB3FiVAEajc9+9oUKKTIdBIu9G7cGwPXr8qAWJxA==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR15MB0874997DACCDD446AE17DD34D0700CY1PR15MB0874namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b0287425-04a1-4152-3fd4-08d5d5fcbde8
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2018 15:53:03.6051 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR15MB0476
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTYRTHe97L9joavk1tB6OggaGGl1yXCWX1odiHBPWDhFo29U3FOXWv SWofRimGEhlecMt04HRq6dLmpfI6W6YhRvZBjcpbI0nJyEuhzdzeBX77nfP/P+d/DjwULhom valUVTajVimUEp6A0F7uyg+YP+IXG1xjJGUVHSu47Hd3NS4bMillw+82kWx0RnGOlL9p+EDK 2+3DSP5c94kvNxj+YPIC2wgvgowRnE5ilKk5jDoo7JogpWpgncy83Y/drO8w8jRoshMrRm4U 0MfB9HARL0YCSkRbEdw3fOdzxTqCxlYb4goDBvqht86CoEtx+GuZxjilDIOptiLcMUxEzyEY 75Q6mEcHQ8/2KnKwJ123M7gqxME4HQ011m1nuMdO+NOujzjnOQFro3qC44tgKFl2MkH7QHnv htMjpOPAPtXqWmkSg2XdJM8huNEK6O2fc5oQvR82Rp9gXJgYphdqXZfSYOgZxzn2gsV5O8n5 r8CcVcPj+qHQvNbB5/ggvK8tcYYBbcbA3FJIckIArFRUuAaFw5e7GpIz9SH41TDvEvzh1bdV 14M0aLFbCY7zoXtsxsWHoPneLFGKgnW7ltUhaoczoK7RX+c8eh+MaBcIru0HphdBnPswlJfM 8jn2hcLqR/zdfT3iNyMvlmET0pNDpIGMOjWRZTNUgSomux3tfK9B86ZPN5pYOm9BNIUke4VG sV+siFTksLnpFgQULvEU7hn1jRUJkxS5eYw6I159Q8mwFnSAIiRi4eypZzEiOlmRzaQxTCaj /q9ilJu3Bj2Q1kYal4u2LkTZkiLCtKatO9KmroWy5erIscSeQc3E14Hcgb56N2vyy2mPqyax j5ftZL624LF7qDHDvUkfEBf7syF+7jqqs8Ww4VlHP9dW+0fn/WiTGiYEMzZsrTfLLO7vjJMu WDwv+S0lnBWcIeL05ii4tVopeS3ur5yUSAg2RXHMH1ezin/D7CBKWgMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/V9Em3HUltLn14WtWMYvGRpEwlz8>
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 15:53:15 -0000

Hi

I do not quite get the same warm and fuzzy from the definition when thinking about multicast…..

The mapping of the binding SID to local policy is still IMO per path state. For a simple p2p path it is pretty straightforward as the mapping can be to a common policy abstraction at every node (send to ‘x’) .

In the case of multicast, the mapping would be unique at every node that had state for the binding SID (send copy to ‘a’ and ‘b’, send copy to ‘m’ and ‘q’ etc.) .  So some means of disseminating the mappings is required, and correlating them with the SID.  So the difference between a binding SID and a global SID for multicast IMO is choice of terminology.

So you have to decide if the whole “avoiding per path state” discussion is simply a desirable goal, or a strict admonition.  A bulk overprovisioning model to eliminate per path state will not work for multicast.

Cheers
Dave

From: spring <spring-bounces@ietf.org> On Behalf Of Alexander Vainshtein
Sent: Tuesday, June 19, 2018 6:38 AM
To: bruno.decraene@orange.com; Stewart Bryant <stewart.bryant@gmail.com>
Cc: SPRING WG List <spring@ietf.org>rg>; Rob Shakir <robjs=40google.com@dmarc.ietf.org>
Subject: Re: [spring] Updating the SPRING WG Charter

Bruno, Stewart and all,
I have looked up Section 5 “Binding Segment” of the Segment Routing Architecture<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15> draft, and it says:

   In order to provide greater scalability, network opacity, and service
   independence, SR utilizes a Binding SID (BSID).  The BSID is bound to
   an SR policy, instantiation of which may involve a list of SIDs.  Any
   packets received with active segment = BSID are steered onto the
   bound SR Policy.

   A BSID may either be a local or a global SID.  If local, a BSID
   SHOULD be allocated from the SRLB.  If global, a BSID MUST be
   allocated from the SRGB.

   Use of a BSID allows the instantiation of the policy (the SID list)
   to be stored only on the node(s) which need to impose the policy.
   Direction of traffic to a node supporting the policy then only
   requires imposition of the BSID.  If the policy changes, this also
   means that only the nodes imposing the policy need to be updated.
   Users of the policy are not impacted.

From my POV this definition is fully aligned both with the Bruno’s last email and with my earlier argument why a BSID does not add a per-path state in the transit nodes.


Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>
Sent: Tuesday, June 19, 2018 3:38 PM
To: Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>>
Cc: SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>; Rob Shakir <robjs=40google.com@dmarc.ietf.org<mailto:robjs=40google.com@dmarc.ietf.org>>
Subject: Re: [spring] Updating the SPRING WG Charter

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.

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________