Re: [spring] Updating the SPRING WG Charter

Jeff Tantsura <jefftant.ietf@gmail.com> Fri, 01 June 2018 16:43 UTC

Return-Path: <jefftant.ietf@gmail.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 9BACA12D96B for <spring@ietfa.amsl.com>; Fri, 1 Jun 2018 09:43:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 yjOv0BiLZi7y for <spring@ietfa.amsl.com>; Fri, 1 Jun 2018 09:43:55 -0700 (PDT)
Received: from mail-pl0-x231.google.com (mail-pl0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D078912DA54 for <spring@ietf.org>; Fri, 1 Jun 2018 09:43:54 -0700 (PDT)
Received: by mail-pl0-x231.google.com with SMTP id az12-v6so15636449plb.8 for <spring@ietf.org>; Fri, 01 Jun 2018 09:43:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version; bh=P80DPYr37umgx/pRfXZXuXLca4V+PE5Q7cIOK2D3d7k=; b=oitGaTbOYr9UxTUsY25L2H/7P5tM5vOL2zsgE/x1QJ1OAH7jmOJLS1VzmgnRhfpuMw 2WvnvV3PqrW2DOHsPpTZDzcG0STj5ANkXI83IaDO+IhJ62qnMfKhNafarou1x3c1BkdJ DW07APpmNKhoipFi1deT7vEoUGY1T5inzjzU5WimL4HcKjSD84u+wHlp/fY+gL+gcOY0 y7PR7S8JYKxNxe22YFB2e5ZBZfkjTO2Q2aWfmJCkS5aEtOGdLGHv7yvQcteBF3d1Zvph UtLBTJPZ1k6pX4hdKVscONHIeOaG9tUlOJCROuMcQzSYziaec5qLVDVkOKQalaZA97d+ eqPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version; bh=P80DPYr37umgx/pRfXZXuXLca4V+PE5Q7cIOK2D3d7k=; b=XSwpZ5EPJzJgEMFqg8c0aE0JQmDmjuiWA9nvNJsoDr+1pN2JqBut71MJME76vbY0hx A/9wZg09TnL6qNwmsIa10yMdcrwvK6NKP/edcPNS/gsH3eH0K92ZcrIYGnxL5Df3K6Im /EcBgu/HzKFdw/b3+nodIFxQEu2whdYB2VspvtSJbTN3ZRBv62I9JoYq6NE1p+6IgH7F 6LSqgMvuMhD7mGAK5lUJoGGlPKEhBfvo+ulPKx3rV+aiARJHn4iWVLSJ4zf2XSBrUfrI tyeD3hV0Z4uX0Zc+6PF2ARZFZyUhbyeQ5LRo+/jtkMOenUmHrtWzZ6UMam/PwJImdQk3 PNHw==
X-Gm-Message-State: ALKqPwfP6TsJuhlt6mBzJrd+4bh9M+WgjaVTCLPw/W0kn10udEhhumBG I07qamj+70pkZCjJnamDZpuliA==
X-Google-Smtp-Source: ADUXVKJUa1YyRi1dOB4ToQYWHGW+qjApUSDHfGGUnA1dIZEyusARIZctL6t8SlRS2xDdB7vjUh6UFg==
X-Received: by 2002:a17:902:7896:: with SMTP id q22-v6mr12006361pll.243.1527871434245; Fri, 01 Jun 2018 09:43:54 -0700 (PDT)
Received: from [192.168.1.18] (c-67-180-14-36.hsd1.ca.comcast.net. [67.180.14.36]) by smtp.gmail.com with ESMTPSA id m83-v6sm5981351pfi.188.2018.06.01.09.43.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jun 2018 09:43:53 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/10.c.0.180410
Date: Fri, 01 Jun 2018 09:43:52 -0700
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: Rob Shakir <robjs=40google.com@dmarc.ietf.org>, SPRING WG List <spring@ietf.org>
Message-ID: <6395E535-C5D7-4F95-8FD8-B99B258165C9@gmail.com>
Thread-Topic: [spring] Updating the SPRING WG Charter
References: <CAHd-QWt+nmQz_R7kE2oeHa2cD88+ndSkpiv56WSFJfHH3PzxRQ@mail.gmail.com>
In-Reply-To: <CAHd-QWt+nmQz_R7kE2oeHa2cD88+ndSkpiv56WSFJfHH3PzxRQ@mail.gmail.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3610691033_338907689"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/BcVk2WB-uU-yvalYv3G1omds3T8>
Subject: Re: [spring] Updating the SPRING WG Charter
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 01 Jun 2018 16:44:04 -0000

Hi Rob,

 

Looks good, few additions, please see inline 

 

Cheers,

Jeff

From: spring <spring-bounces@ietf.org> on behalf of Rob Shakir <robjs=40google.com@dmarc.ietf.org>
Date: Friday, June 1, 2018 at 09:05
To: SPRING WG List <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).

[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.

 

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

[jeff] SR conveyed metadata perhaps? Think of BSID x-connect into another layer

 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

[jeff] in RIFT we plan to support SR as well

        * 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

[jeff] rtgwg for fast convergence related topics

 

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

 

Thanks,

Bruno & Rob

_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring