[spring] msg to SPRING to promote SR -SD WAN draft RE: Updating the SPRING WG Charter

Linda Dunbar <linda.dunbar@huawei.com> Mon, 18 June 2018 19:59 UTC

Return-Path: <linda.dunbar@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 8DFAE130E3C for <spring@ietfa.amsl.com>; Mon, 18 Jun 2018 12:59:02 -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 GyNLsMcvK89Y for <spring@ietfa.amsl.com>; Mon, 18 Jun 2018 12:58:48 -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 F3B77130F17 for <spring@ietf.org>; Mon, 18 Jun 2018 12:58:46 -0700 (PDT)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 0E244657D9076 for <spring@ietf.org>; Mon, 18 Jun 2018 20:58:43 +0100 (IST)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 18 Jun 2018 20:58:44 +0100
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.90]) by SJCEML701-CHM.china.huawei.com ([169.254.3.24]) with mapi id 14.03.0382.000; Mon, 18 Jun 2018 12:58:36 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: Linda Dunbar <linda.dunbar@huawei.com>
CC: Jeff Tantsura <jefftant.ietf@gmail.com>, SPRING WG List <spring@ietf.org>
Thread-Topic: msg to SPRING to promote SR -SD WAN draft RE: [spring] Updating the SPRING WG Charter
Thread-Index: AdQHPr0KIlX/toHSQ/6nLuyYpapk3Q==
Date: Mon, 18 Jun 2018 19:58:35 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B070E21@sjceml521-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.192.11.89]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F66B070E21sjceml521mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/EYR5nyLfEgmAMNs1riYdRbDlRRM>
Subject: [spring] msg to SPRING to promote SR -SD WAN draft RE: 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: Mon, 18 Jun 2018 19:59:12 -0000

robjs> You can imagine the SR-TE policy work breaks down this way: we discuss the "application" which is steering traffic onto sets of SR paths, and define a functional specification document for how that works. If that is realised in BGP (as it is being today), IDR owns the protocol specification, if it's in PCEP, then it's done in that WG.


From: Rob Shakir [mailto:robjs@google.com]
Sent: Sunday, June 03, 2018 4:32 PM
To: Linda Dunbar <linda.dunbar@huawei.com>
Cc: Jeff Tantsura <jefftant.ietf@gmail.com>; SPRING WG List <spring@ietf.org>
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Linda,

On Fri, Jun 1, 2018 at 12:35 PM Linda Dunbar <linda.dunbar@huawei.com<mailto:linda.dunbar@huawei.com>> wrote:

The Source Packet Routing in NetworkinG (SPRING) Working Group is the home of
Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6).
[jeff] I’d add “dataplanes”
SPRING WG serves as
a forum to discuss SPRING networks operations, define new applications, and
specify extensions of Segment Routing technologies.
[Linda] Does the “new applications” in the sentence above refer to the “Use cases” for SPRING?
Is the “Extensions” being discussed in SPRING also include the “extensions” to other protocols?

robjs> The aim here is to define that SPRING is where we discuss new things that are done with SR. I don't think we want to constrain things to say that only use-case work is done in SPRING (actually, we've had little success with a number of the use case documents). The extensions referred to are extensions to SR technologies. Per the later wording in the charter, the intention here is to clarify that functional specifications for those extensions can be done in SPRING, but the actual extension work is owned by the WG that owns that technology.

robjs> You can imagine the SR-TE policy work breaks down this way: we discuss the "application" which is steering traffic onto sets of SR paths, and define a functional specification document for how that works. If that is realised in BGP (as it is being today), IDR owns the protocol specification, if it's in PCEP, then it's done in that WG.

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

[Linda] o Source-routed stateless SD-WAN paths traversing through SR domain (i.e. SR as part of SD-WAN’s underlay network)

robjs> Our focus here is to provide a constrained set of areas where there is a need for work within SPRING. The discussions that we had in the working group in London were focused around capturing the set of technologies that have strong support and folks to work on. If we have new proposals around this work, then we can always consider working on them if they need extensions to the SR architecture. At the moment, the preference is to keep this list constrained such that we can focus the working group.

 *snip*

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

[Linda] o The inter-working between SR and legacy networks (which is far more likely than SRv6 & SR-MPLS interworking)

robjs> The LDP interop draft is something that is going to the IESG at the moment. There is existing work in TEAS (in WGLC) that covers co-existence of RSVP-TE and SR. Are there specific areas that we have gaps? The reason that we call out SRv6/SR-MPLS interop is that there has been some discussion of this, and we have not got an answer for this yet.

Thanks for the comments.

Kind regards,
r.