[spring] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt

"Adrian Farrel" <adrian@olddog.co.uk> Fri, 11 August 2017 18:47 UTC

Return-Path: <adrian@olddog.co.uk>
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 581EA132655 for <spring@ietfa.amsl.com>; Fri, 11 Aug 2017 11:47:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 fnpicW8SNLb1 for <spring@ietfa.amsl.com>; Fri, 11 Aug 2017 11:47:15 -0700 (PDT)
Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 497AC1293E1 for <spring@ietf.org>; Fri, 11 Aug 2017 11:47:12 -0700 (PDT)
Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7BIl9iQ025727 for <spring@ietf.org>; Fri, 11 Aug 2017 19:47:09 +0100
Received: from 950129200 (196.252.114.87.dyn.plus.net [87.114.252.196]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7BIl9uC025715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <spring@ietf.org>; Fri, 11 Aug 2017 19:47:09 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: spring@ietf.org
References: <150247679913.24555.11731619545096839826.idtracker@ietfa.amsl.com> <e757ba5b317644d589fa4b536c724cc2@CO2PR05MB971.namprd05.prod.outlook.com>
In-Reply-To: <e757ba5b317644d589fa4b536c724cc2@CO2PR05MB971.namprd05.prod.outlook.com>
Date: Fri, 11 Aug 2017 19:47:07 +0100
Message-ID: <053c01d312d2$3c44cb90$b4ce62b0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHn/qs4BvcCTQFwrnhrRd9ZEGKw2AIdtmzDokS32NA=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23252.001
X-TM-AS-Result: No--14.445-10.0-31-10
X-imss-scan-details: No--14.445-10.0-31-10
X-TMASE-MatchedRID: rqmDq8+jU9MALfxbHOcBRlu4M/xm4KZeH8cjAOna5Kv5FE/jy9O3nbMD YIiOMuxa4plhBuwyqtHSrSKGJJTJhrkYizK5Be96ACs2C3nGlBhCn2WEjt2Yo6Gn8EOTqEDA2d8 mtRIRsUPMGlr2fNoNDJs4Q6e9f0oNL0W1btd8e57OeIV+MVeozhpXjRc0zbUqiggc5gPv8G/6hy ODqRDK2Z0EopZ3V99yTugiO6yIdoryAvqldeMqenV7tdtvoibaGbJMFqqIm9wifM7JMNHW6xvDD WnRtEZGX+uVOmHkQvCH/aIpLb3OWxxyVPzEfp5h/jkwiY2tJnL2kudi1D33EqIiUozBB8xriMD6 wB/IizIuFwNzrXciLeSU7G1VvsR9u+66Sy5jOwKHZXNSWjgdUwml5JDmKayhWltirZ/iPP6OudT hERN49oBAUdh4514r9u75WUASg3Q3KXWd30Ii3Tl/1fD/GopdyJ1gFgOMhOnmKuxMXtACKKu6xV HLhqfxrFldG3ZH+DlIGo8bxrs5obQW5W8z2t6njUhQf/WGFLTP70zAdHk7Sq8hJNN51GP5VJ7tc 98LFuo=
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/Nyjjg44SsxjkA1pcos9dmr4M-mY>
Subject: [spring] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt
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: Fri, 11 Aug 2017 18:47:17 -0000

Hi all,

SPRING didn't meet in Prague so I presented this work in MPLS. Bruno suggested
that maybe SPRING would be a better venue.

I'm not sure about that, although I do think both WGs should chat about the
ideas.

The essence of this work is nothing more that MPLS-SR encapsulated in UDP per
RFC 7510. What it achieves is a way to obtain the SR functionality that we all
know and love in an IP network.

The approach is, of course, compatible with MPLS-SR. As the draft says...

   This document makes no changes to the segment routing architecture
   and builds on existing protocol mechanisms such as the encapsulation
   of MPLS within UDP defined in RFC 7510.

   No new procedures are introduced, but existing mechanisms are
   combined to achieve the desired result.

This is not intended to be a beauty contest with SRv6. As the draft says...

   The method defined is a complementary way of running SR in an IP
   network that can be used alongside or interchangeably with that
   defined in [I-D.ietf-6man-segment-routing-header].  Implementers and
   deployers should consider the benefits and drawbacks of each method
   and select the approach most suited to their needs.

Thanks,
Adrian

> ________________________________________
> From: internet-drafts@ietf.org
> Sent: 11 August 2017 19:39:59 (UTC+00:00) Dublin, Edinburgh, Lisbon, London
> To: Stewart Bryant; John E Drake; Adrian Farrel
> Subject: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt
> 
> A new version of I-D, draft-bryant-mpls-unified-ip-sr-01.txt
> has been successfully submitted by Adrian Farrel and posted to the
> IETF repository.
> 
> Name:           draft-bryant-mpls-unified-ip-sr
> Revision:       01
> Title:          A Unified Approach to IP Segment Routing
> Document date:  2017-08-11
> Group:          Individual Submission
> Pages:          16
> URL:
https://www.ietf.org/internet-drafts/draft-bryant-mpls-unified-ip-sr-
> 01.txt
> Status:
https://datatracker.ietf.org/doc/draft-bryant-mpls-unified-ip-sr/
> Htmlized:       https://tools.ietf.org/html/draft-bryant-mpls-unified-ip-sr-01
> Htmlized:
https://datatracker.ietf.org/doc/html/draft-bryant-mpls-unified-ip-
> sr-01
> Diff:
https://www.ietf.org/rfcdiff?url2=draft-bryant-mpls-unified-ip-sr-01
> 
> Abstract:
>    Segment routing is a source routed forwarding method that allows
>    packets to be steered through a network on paths other than the
>    shortest path derived from the routing protocol.  The approach uses
>    information encoded in the packet header to partially or completely
>    specify the route the packet takes through the network, and does not
>    make use of a signaling protocol to pre-install paths in the network.
> 
>    Two different encapsulations have been defined to enable segment
>    routing in an MPLS network and in an IPv6 network.  While
>    acknowledging that there is a strong need to support segment routing
>    in both environments, this document defines a converged, unified
>    approach to segment routing that enables a single mechanism to be
>    applied in both types of network.  The resulting approach is also
>    applicable to IPv4 networks without the need for any changes to the
>    IPv4 specification.
> 
>    This document makes no changes to the segment routing architecture
>    and builds on existing protocol mechanisms such as the encapsulation
>    of MPLS within UDP defined in RFC 7510.
> 
>    No new procedures are introduced, but existing mechanisms are
>    combined to achieve the desired result.
> 
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat