Re: [spring] SPRING - rechartering discussion
Mach Chen <mach.chen@huawei.com> Mon, 19 March 2018 06:48 UTC
Return-Path: <mach.chen@huawei.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 64FB7124207; Sun, 18 Mar 2018 23:48:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.661
X-Spam-Level:
X-Spam-Status: No, score=-3.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 BWg1tQ7f5KuD; Sun, 18 Mar 2018 23:48:16 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 17C92120721; Sun, 18 Mar 2018 23:48:16 -0700 (PDT)
Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 98D9AAAA4A8D5; Mon, 19 Mar 2018 06:48:12 +0000 (GMT)
Received: from DGGEML404-HUB.china.huawei.com (10.3.17.39) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 19 Mar 2018 06:48:13 +0000
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.73]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0361.001; Mon, 19 Mar 2018 14:48:07 +0800
From: Mach Chen <mach.chen@huawei.com>
To: "Zafar Ali (zali)" <zali@cisco.com>, Martin Horneffer <maho@nic.dtag.de>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>
CC: "spring@ietf.org" <spring@ietf.org>, "martin.vigoureux@nokia.com" <martin.vigoureux@nokia.com>, Alvaro Retana <aretana.ietf@gmail.com>
Thread-Topic: [spring] SPRING - rechartering discussion
Thread-Index: AdO0orOvGxlRX3UWT2OiQ84nIzSu/AJaPUiAAAPr5AAATLkLeA==
Date: Mon, 19 Mar 2018 06:48:07 +0000
Message-ID: F34ECF48-98EC-48DC-A400-CED69EC2CDDE
References: <10571_1520269182_5A9D777E_10571_65_1_53C29892C857584299CBF5D05346208A479BFB19@OPEXCLILM21.corporate.adroot.infra.ftgroup> <f206303c-fdfe-268a-696b-ddbe5e998503@nic.dtag.de>, <3B71EF1C-24C5-4CC4-A6F2-329B0ED87A7C@cisco.com>
In-Reply-To: <3B71EF1C-24C5-4CC4-A6F2-329B0ED87A7C@cisco.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_F34ECF4898EC48DCA400CED69EC2CDDE_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/w9JsrvyW7noNHmeb2PKjuzHQz7M>
Subject: Re: [spring] SPRING - rechartering discussion
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <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: Mon, 19 Mar 2018 06:48:19 -0000
Hi all, I completely agree with Ali and Martin here, OAM is very important tool for a technology to be deployed in a production network, we see more and more requirements in this area. I support the idea to add the OAM milestone to the new charter. Best regards, Mach 发件人:Zafar Ali (zali) 收件人:Martin Horneffer,spring-chairs@ietf.org, 抄 送:spring@ietf.org,martin.vigoureux@nokia.com,Alvaro Retana, 时间:2018-03-18 02:12:03 主 题:Re: [spring] SPRING - rechartering discussion Dear WG Chairs, I completely agree with Martin. To add, the task for "New OAM techniques" is not only explicitly mentioned in the existing charter (https://datatracker.ietf.org/doc/charter-ietf-spring/) but there is a current milestone associated with it, "Specify the OAM mechanisms needed to support SPRING." At the moment the WG has only defined basic ping, traceroute and probing tools. From the initial deployments experiences of segment routing, SPs are coming up with the new requirements for operation and management, performance monitoring, connectivity verification and traffic accounting, etc. There are numerous individual contributions in this area listed in the following (see https://datatracker.ietf.org/wg/spring/documents/ for detailed list): + draft-ali-spring-sr-traffic-accounting-00. Martin specifically mentioned the requirement for traffic accounting. We requested a presentation slot where we planned to ask for WG adaptation, but due to time constraint, it did not fit the agenda. + draft-hegde-spring-traffic-accounting-for-sr-paths-01 is also addressing requirement outlined by Martin. It was presented at the last IETF and was subject to engaging discussion on the mailing list. + draft-ali-spring-srv6-oam-00 is on Spring WG agenda Friday, and we plan to ask for WG adaptation. + draft-gandhi-spring-sr-mpls-pm-00 requested a slot, but due to time constraint, it did not fit the agenda. + draft-ali-spring-srv6-pm-02 also requested a slot, but due to time constraint, it did not make it to the agenda. + draft-ali-spring-bfd-sr-policy-00 and draft-mirsky-spring-bfd-05 are on Spring agenda for discussion on Friday. + draft-cheng-spring-mpls-path-segment-01 + draft-fioccola-spring-flow-label-alt-mark-01 + draft-li-spring-passive-pm-for-srv6-np-00 In summary, as you can see that there is a tremendous interest in the SPRING OAM area, which is in the existing charter and a current milestone. I would like to request WG chair to complete this work in the existing milestone or add a new milestone for it. Thanks Regards ... Zafar On 3/17/18, 8:19 PM, "spring on behalf of Martin Horneffer" <spring-bounces@ietf.org on behalf of maho@nic.dtag.de> wrote: Hello Bruno, Martin, Rob, and whole WG, as with many bigger protocols that actually make their way into production networks, I get the strong feeling that SPRING is not done with the conclusion of the core documents. As the technology gets closer to production use, unforeseen topics and issues appear that need to be discussed and - in many cases - standardized. I do see the need for documents of the "operators' requirements" style. Conflict resolution was one good example. Others are about traffic steering and traffic and/or performance measurement und monitoring. Probably not all networks have the same requirement as ours, but maybe there are others that feel like us: we cannot afford to transport sginificant huge amounts of traffic if we cannot measure it. Measure it in a way that is suitable to generate traffic matrices and and allows to offline simulate the whole network. Same for traffic steering: how can I actually differentiate the traffic and have the routers choose the right segment lists for every packet? While I'm having very good discussions with multiple vendors about these topics, I really think this is something that needs to be standardized. And in this case it means, in my eyes, that the charter of the SPRING wg must be enhanced in some way to allow this kind of discussion and standardization. Best regards, Martin Am 05.03.18 um 17:59 schrieb bruno.decraene@orange.com: > Hello WG, > > now that nearly all the core documents are in the hands of IESG or beyond, we think it is time to (re)discuss rechartering. > We brought up that question few meetings ago and the feedback, at that time, was that the WG at least needs to be maintained to discuss the extensions following deployment feedback. > > But we need also identify technical directions. > > In order to initiate the discussion we are proposing some high level items but we'd like to make clear a few points before: > * these are only proposals; what might end-up as the next steps for SPRING will be what the WG is willing to work on (which includes having cycles for that). > * what the WG might be rechartered to do is not necessarily limited to that; so other proposals are welcome. > > So, we thought of the following: > > * general architectural work / extensions > there are still few items on our plate and we expect that some might need to be progressed, and we should maybe allow for others to come. > > * service chaining > last meeting there were proposals discussed in SPRING to realize some form of service chaining. any work in that space would require close coordination with SFC and maybe other WG. > > * yang > we are a bit behind here and there is definitely work to do. > > > So please comment on these and propose additional items. > > We'll likely have a dedicated slot in London but we'd like to progress before that. > > Thank you, > --Martin, Rob, Bruno > > > -----Original Message----- > > From: Martin Vigoureux [mailto:martin.vigoureux@nokia.com] > > Sent: Wednesday, March 29, 2017 4:25 PM > > To: spring@ietf.org > > Cc: spring-chairs@ietf.org; Alvaro Retana (aretana) > > Subject: Next steps for SPRING? > > > > WG, > > > > in the session we have opened the discussion on the future of the WG, > > putting all options on the table (recharter/close/sleep). > > As a foreword, we still have few WG Documents that we need to -and will- > > push towards IESG (and a greater number that need to reach RFC status), > > but with those we'll have reached most if not all of our milestones, > > thus the question on what's next. > > > > So, we think we have heard during the session that closing wasn't > > desired and one reason for that is to have a home to share and discuss > > deployment considerations as the technology gets deployed. > > There are also a few individual documents knocking at the door, and some > > of them were presented during the session. > > > > To reach out to everyone, we are thus asking the question on the list. > > We would like to hear from you all what the working group should be > > focussing on. > > > > Note, the expectation is that future items should not be use-cases but > > rather be technology extensions/evolutions. > > > > Thank you > > > > Martin & 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 > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
- [spring] SPRING - rechartering discussion bruno.decraene
- Re: [spring] SPRING - rechartering discussion Paul Mattes
- Re: [spring] SPRING - rechartering discussion Zafar Ali (zali)
- Re: [spring] SPRING - rechartering discussion Rob Shakir
- Re: [spring] SPRING - rechartering discussion Rob Shakir
- Re: [spring] SPRING - rechartering discussion Voyer, Daniel
- Re: [spring] SPRING - rechartering discussion Martin Horneffer
- Re: [spring] SPRING - rechartering discussion Zafar Ali (zali)
- Re: [spring] SPRING - rechartering discussion Gaurav Dawra
- Re: [spring] SPRING - rechartering discussion Gaurav Dawra
- Re: [spring] SPRING - rechartering discussion Ketan Talaulikar (ketant)
- Re: [spring] SPRING - rechartering discussion 徐小虎(义先)
- Re: [spring] SPRING - rechartering discussion Leddy, John
- Re: [spring] SPRING - rechartering discussion Bernier, Daniel
- Re: [spring] SPRING - rechartering discussion Jeff Tantsura
- Re: [spring] [**EXTERNAL**] Re: SPRING - recharte… Shah, Himanshu
- Re: [spring] SPRING - rechartering discussion Mach Chen
- Re: [spring] SPRING - rechartering discussion Loa Andersson
- Re: [spring] SPRING - rechartering discussion Adrian Farrel
- Re: [spring] [**EXTERNAL**] Re: SPRING - recharte… Voyer, Daniel
- Re: [spring] [**EXTERNAL**] Re: SPRING - recharte… Dongjie (Jimmy)
- Re: [spring] [**EXTERNAL**] Re: SPRING - recharte… Alex Bogdanov
- Re: [spring] [**EXTERNAL**] Re: SPRING - recharte… Zafar Ali (zali)
- Re: [spring] [**EXTERNAL**] Re: SPRING - recharte… Chengli (IP Technology Research)
- Re: [spring] SPRING - rechartering discussion Ruediger.Geib
- Re: [spring] SPRING - rechartering discussion Martin Horneffer
- Re: [spring] SPRING - rechartering discussion Loa Andersson
- Re: [spring] [**EXTERNAL**] Re: SPRING - recharte… Martin Horneffer
- Re: [spring] [**EXTERNAL**] Re: SPRING - recharte… Paul Mattes
- Re: [spring] [**EXTERNAL**] Re: SPRING - recharte… Darren Dukes (ddukes)
- Re: [spring] [**EXTERNAL**] Re: SPRING - recharte… Robert Raszuk
- Re: [spring] [**EXTERNAL**] Re: SPRING - recharte… Kamran Raza (skraza)
- Re: [spring] [**EXTERNAL**] Re: SPRING - recharte… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [spring] [**EXTERNAL**] Re: SPRING - recharte… Martin Horneffer
- Re: [spring] [**EXTERNAL**] Re: SPRING - recharte… Ruediger.Geib
- Re: [spring] [**EXTERNAL**] Re: SPRING - recharte… Gaurav Dawra
- Re: [spring] [**EXTERNAL**] Re: SPRING - recharte… Leddy, John
- Re: [spring] [**EXTERNAL**] Re: SPRING - recharte… stefano previdi
- [spring] 答复: [**EXTERNAL**] Re: SPRING - recharte… Lizhenbin
- [spring] Please count the SRv6 for Mobile work [w… Satoru Matsushima
- Re: [spring] 答复: [**EXTERNAL**] Re: SPRING - rech… Tarek Saad (tsaad)
- Re: [spring] Please count the SRv6 for Mobile wor… Zafar Ali (zali)