[spring] 答复: Updating the SPRING WG Charter

"Dongjie (Jimmy)" <jie.dong@huawei.com> Wed, 20 June 2018 06:40 UTC

Return-Path: <jie.dong@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 BD8FF131052 for <spring@ietfa.amsl.com>; Tue, 19 Jun 2018 23:40:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 LaE99j36cbfp for <spring@ietfa.amsl.com>; Tue, 19 Jun 2018 23:40:20 -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 A2135131053 for <spring@ietf.org>; Tue, 19 Jun 2018 23:40:19 -0700 (PDT)
Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 99C9EDEE8D0E6; Wed, 20 Jun 2018 07:40:15 +0100 (IST)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 20 Jun 2018 07:40:16 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0382.000; Wed, 20 Jun 2018 14:40:10 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de>
CC: "spring@ietf.org" <spring@ietf.org>
Thread-Topic: [spring] Updating the SPRING WG Charter
Thread-Index: AQHT+cJyb2WE4BtuQ0iRzbs6VN00gqRcLZCAgAApXICAAdH0gIAAE33wgAqKtKA=
Date: Wed, 20 Jun 2018 06:40:09 +0000
Message-ID: <76CD132C3ADEF848BD84D028D243C927A6D36374@NKGEML515-MBX.china.huawei.com>
References: <CAHd-QWt+nmQz_R7kE2oeHa2cD88+ndSkpiv56WSFJfHH3PzxRQ@mail.gmail.com> <9309CB81-A1E6-48E0-B6E0-D5F72966DC39@cisco.com> <24129_1528820000_5B1FF120_24129_264_1_53C29892C857584299CBF5D05346208A47A85715@OPEXCLILM21.corporate.adroot.infra.ftgroup> <76CD132C3ADEF848BD84D028D243C927A6D2368C@NKGEML515-MBX.china.huawei.com> <FRAPR01MB074015767051A69805E8761B9C7E0@FRAPR01MB0740.DEUPRD01.PROD.OUTLOOK.DE>
In-Reply-To: <FRAPR01MB074015767051A69805E8761B9C7E0@FRAPR01MB0740.DEUPRD01.PROD.OUTLOOK.DE>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.148.21.252]
Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C927A6D36374NKGEML515MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/877r1k1YyEnEkfeOwDKS-iTSxPw>
Subject: [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: Wed, 20 Jun 2018 06:40:24 -0000

Hi Ruediger,

Sorry for the late reply, I missed your below mail and just find it when doing some mail filtering today.

SR aims to remove the per-path state from the core of the network. Per-segment state is still needed by all routers in the SR domain. You are correct that “Using SR as the mechanism to identify sets of resources” may introduce additional per-segment state, but no per-path state will be introduced. In my understanding this aligns with the SR paradigm thus can be part of the SPRING charter.

Best regards,
Jie

发件人: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de]
发送时间: 2018年6月13日 21:17
收件人: Dongjie (Jimmy) <jie.dong@huawei.com>
抄送: spring@ietf.org
主题: AW: [spring] Updating the SPRING WG Charter

Dear Ji,

you’ve written „Although SR can rely on the network controller for global traffic optimization and placement, there is no mechanism to provide resource guarantee and service separation in the data plane.”

If this is linked to maintenance of per segment (or per segment range) state on other parts of the SR domain than the SR edge router, it is not within charter of the SR WG, I think.

Regards,

Ruediger



Von: spring [mailto:spring-bounces@ietf.org] Im Auftrag von Dongjie (Jimmy)
Gesendet: Mittwoch, 13. Juni 2018 14:19
An: bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>; Zafar Ali (zali) <zali=40cisco.com@dmarc.ietf.org<mailto:zali=40cisco.com@dmarc.ietf.org>>
Cc: SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>; Zafar Ali (zali) <zali@cisco.com<mailto:zali@cisco.com>>; Rob Shakir <robjs=40google.com@dmarc.ietf.org<mailto:robjs=40google.com@dmarc.ietf.org>>
Betreff: Re: [spring] Updating the SPRING WG Charter

Dear Zafar,

As Bruno and Sasha have pointed out, the enhanced VPN drafts are relevant to this work item.

As mentioned in one of my previous email (the pointer is also provided in Bruno’s mail), currently SR is mainly designed for source routing based path steering, comparing to RSVP-TE, it does not provide the functionality of allocating and identifying different set of resources on particular network segments. Although SR can rely on the network controller for global traffic optimization and placement, there is no mechanism to provide resource guarantee and service separation in the data plane. Some customers have expressed their concerns about SR’s lack of this kind of capability, thus we believe this work item should be included in the updated charter.

Best regards,
Jie

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>
Sent: Wednesday, June 13, 2018 12:13 AM
To: Zafar Ali (zali) <zali=40cisco.com@dmarc.ietf.org<mailto:zali=40cisco.com@dmarc.ietf.org>>
Cc: SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>; Zafar Ali (zali) <zali@cisco.com<mailto:zali@cisco.com>>; Rob Shakir <robjs=40google.com@dmarc.ietf.org<mailto:robjs=40google.com@dmarc.ietf.org>>
Subject: Re: [spring] Updating the SPRING WG Charter

Dear Zafar,

Please see inline [Bruno]

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: Tuesday, June 12, 2018 3:45 PM
To: Rob Shakir; SPRING WG List
Cc: Zafar Ali (zali)
Subject: Re: [spring] Updating the SPRING WG Charter

Dear Rob, Bruno,

I have a question on the specifics of the following milestone:


  *   Using SR as the mechanism to identify sets of resources in networks with SR-MPLS and SRv6 dataplanes.

I do not know of any specific use-case, requirement or an individual draft associated with this milestone beyond what is already covered by other milestones (e.g., by “Segment Routing policies and the associated steering and traffic engineering mechanisms”). What specific deliverable you have in mind? Is there an individual(s) draft against this milestone? Please advise.

[Bruno] Would the following pointers provide enough context?
https://mailarchive.ietf.org/arch/msg/spring/canXoxLZCwRZ_yFcV3U7RXRwfpM
https://tools.ietf.org/html/draft-bryant-rtgwg-enhanced-vpn-02#section-4.3.6
https://tools.ietf.org/html/draft-dong-spring-sr-for-enhanced-vpn-00#section-2

Regards,
--Bruno

Thanks

Regards … Zafar

From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> on behalf of Rob Shakir <robjs=40google.com@dmarc.ietf.org<mailto:robjs=40google.com@dmarc.ietf.org>>
Date: Friday, June 1, 2018 at 12:07 PM
To: SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>
Subject: [spring] Updating the SPRING WG Charter

Hi SPRING,

After the discussions on the list and in London relating to the charter, Bruno and I have been working to propose a new charter for the WG with Martin, and the other routing ADs. The text for this suggested charter is below. We would like to solicit WG feedback on the charter text prior to Martin taking to the IESG. We'd like to try and get the charter agreed prior to IETF 102 in Montréal.

The Source Packet Routing in NetworkinG (SPRING) Working Group is the home of
Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6). SPRING WG serves as
a forum to discuss SPRING networks operations, define new applications, and
specify extensions of Segment Routing technologies.

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.
Full explicit control (through loose or strict path specification) can be
achieved in a network comprising only SPRING nodes, however SPRING nodes must
inter-operate through loose routing in existing networks and may find it
advantageous to use loose routing for other network applications.

The scope of the SPRING WG work includes both single Autonomous System (AS) and
multi-AS environments. Segment Routing operates within a trusted domain; as
described in the architecture, a node imposing a segment list is assumed to be
allowed to do so. Nonetheless, the SPRING WG must strive to identify and
address security considerations brought up by the technologies it defines.  The
technologies SPRING WG defines may be applicable to both centralised and
distributed path computation.

SPRING WG should avoid modification to existing data planes that would make
them incompatible with existing deployments. Where possible, existing control
and management plane protocols must be used within existing architectures to
implement the SPRING function. Any modification of - or extension to - existing
architectures, data planes, or control or management plane protocols should be
carried out in the WGs responsible for the architecture, data plane, or control
or management plane protocol being modified and in coordination with the SPRING
WG, but may be done in SPRING WG after agreement with all the relevant WG
chairs and responsible Area Directors.


The SPRING WG will manage its specific work items by milestones agreed with the
responsible Area Director.

The work-items of the SPRING WG include functional specifications for:

o Segment Routing policies and the associated steering and traffic engineering
  mechanisms.

o Source-routed stateless service chaining using SR-MPLS and SRv6 dataplanes.

o SRv6 network programming for the underlay networks and overlay services, and
  including data plane behavior and functions associated with SIDs

o Operation, Administration and Management (OAM), and traffic accounting in
  networks with SR-MPLS and SRv6 data planes in the case where SR introduces
  specificities compared to MPLS or IPv6 technologies.

o Performance Management (PM) and monitoring in networks with SR-MPLS and SRv6
  data planes in the case where SR introduces specificities compared to MPLS or
  IPv6 technologies.

o The inter-working between SRv6 and SR-MPLS.

o Using SR as the mechanism to identify sets of resources in networks with
  SR-MPLS and SRv6 dataplanes.

Any of the above may require architectural extensions.

The work-items of SPRING WG also include:

o Specification of management models (YANG) for Segment Routing applications,
  services and networks with SR-MPLS and SRv6 dataplanes.

The SPRING WG will coordinate and collaborate with other WGs as needed. Specific
expected interactions include (but may not be limited to):

* mpls on the MPLS dataplane and OAM extensions,
* 6man on the IPv6 dataplane for SR and associated OAM extensions
* lsr on OSPF and IS-IS extensions to flood SPRING-related information
        * idr for BGP extensions
* bess for VPN control plane
* pce on extensions to communicate with an external entity to compute and program SPRING paths
* teas on generic traffic engineering architecture

Please comment on the contents of the charter text on the list.

Thanks,
Bruno & Rob

_________________________________________________________________________________________________________________________



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.