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

"Adrian Farrel" <> Thu, 17 August 2017 04:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A6C661321F6; Wed, 16 Aug 2017 21:49:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zekNmWctKKNb; Wed, 16 Aug 2017 21:49:12 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5489512009C; Wed, 16 Aug 2017 21:49:11 -0700 (PDT)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id v7H4n9KI021160; Thu, 17 Aug 2017 05:49:09 +0100
Received: from 950129200 ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id v7H4n7ie021136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Aug 2017 05:49:08 +0100
From: Adrian Farrel <>
To: 'Robert Raszuk' <>
References: <> <> <053e01d312d3$1dcba0c0$5962e240$> <> <>
In-Reply-To: <>
Date: Thu, 17 Aug 2017 05:49:05 +0100
Message-ID: <059e01d31714$27fb1ef0$77f15cd0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_059F_01D3171C.89C41AD0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHn/qs4BvcCTQFwrnhrRd9ZEGKw2AIdtmzDAWjbfWQBJH04OgGKdeMzoixuy5A=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--26.374-10.0-31-10
X-imss-scan-details: No--26.374-10.0-31-10
X-TMASE-MatchedRID: Z/tjqhsgM6dbJCKOm3VRCaj5v7I4/SgYq8k2QEqE4yUTyaVf7UjgsT3R Dhsyc984sznIV04I19FLEb8jQyOYXkOaNQ+STGGWOdl/GMFVBFszBHKsDHLon/yQkqwxgq4lu1H fushj2IMlr4UAbUFME1t3XMydUaMXAC8ufaKZ2BzfUZT83lbkEPTYLJi/AavY3MZ/LCP5vw03QQ KH+h23K9jTzYyhzXBG9UVHiwLx0/L2v20RxLDyN3yryS1js33QPrMcTVgfnXCAQFHYeOdeK5sZX bChjvKtImxAt97SdonTzWmGCXkX+SEdaywSZvzOsa7wMXMLrhak0xCU9zGy2eXA1O4kk7XxqEJt GIW6dQGiPXhbv/v9rie1T5r1VA3InS9YM7PCHZiCTJUvpDBm3Dl1BSviCTbCKADgxIx6VkhzYNa liAyMvYxYkErIAqjRW7gz/Gbgpl4jkrgJ37RqjyImYHvg8xhoBUz2Q+xpjHgUBgz2TpDbYVe/mD hUGtdRVatb/Qtg459NCH0Dib0S0enyXFanZ6WWWcNQC7Waq82Trr+C1WNmxeBmZBH3ZVRSZfPmK JtMluYCsjHNBKjIyv45MImNrSZy9pLnYtQ99xKiIlKMwQfMa4jA+sAfyIsyLJf50D62mqhcvoSy YffYE9qoygGFfC1GTVa+L3Zgqc70IWUUTIPdhFmmz7LVVfOp7fKxaM2xqkBh6R1V/b2StVvKLnw iAiVRqqrD2rq6EGCA6qv+vR34LFF5adRR2Ej1zO86RLKahv8nwf3kfmsrQzba6gSbbjl+gVo1o+ 4QhtKqDvek35mqXJ3bt4XlQMWjD+LwVja9M4GbKItl61J/yZUdXE/WGn0FxbYCTleOUf4Hd2pRm IqqGSIWyOG3VFHj6KOPt1yh+6CHHQtvygWztIUNRfoOduqwMj/+V4GlIPEgUJd9uKRYtT7qFUTu O1RWdydBcHzvVOQ=
Archived-At: <>
Subject: Re: [mpls] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Aug 2017 04:49:15 -0000

Thanks for the thoughtful comments.
You're right, MPLS-SR is not SRv6 and this is not the document to run a comparison or beauty contest. Nor is this the right document to use to consider making changes or additions to MPLS-SR to make it more like SRv6.
We should focus this document on describing how to carry MPLS-SR over UDP and the use cases for that.
I think your question about MTU discovery is a good one. We should look into that and reference RFC 4023.
From: [] On Behalf Of Robert Raszuk
Sent: 11 August 2017 20:23
To: Adrian Farrel
Subject: Re: [mpls] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt
Sorry but forgot one more really useful advantage which your proposal is lacking ... 
In SRv6 when you traverse SR node you move the pointer from one SID to the next one. This allows you to maintain in the packet the entire history of functions executed on a given packet. Something which to the best of my knowledge we never had in the IP networks. Now how could you accomplish the same or even close to that with SR-MPLS analogy ? 
On Fri, Aug 11, 2017 at 9:11 PM, Robert Raszuk <> wrote:
Hi Adrian,
I see few so to say "challenges" with the proposal 
SRv6 SID is 128 bits where first 64 is the locator and remaining 64 is the function. So to "emulate" this directly with SR-MPLS you need for 1 SRv6 SID stack of 8 labels ! And some use cases of SRv6 already talk about using few SRv6 SIDs. Please show me the today's hardware which can consume in single pass and make sense of stack of say 32 mpls labels ... so here goes your "interchangeability". 
One of serious concerns with SRH insertion in transit as expressed by 6man was MTU. How does this proposal solves this at all if what you are doing here is taking nicely MTU discovered and negotiated IPv6 packet and adding mpls stack or tower + UDP + IPv/v6 encap to it ? How would end hosts now will get any awareness about this ?
One of the very nice applications for SRv6 is spray function with full multicast address transparency. Please kindly elaborate how are you going to map IPv4 or IPv6 multicast addresses into MPLS labels ?
- - - 
I think while it looks great on slides that now we will have two different ways to do SR on IP networks if you really focus to specific applications you will find a lot of them which are not going to be compatible with your proposal. So maybe instead trying to squeeze the balloon to fit the bottle we better collectively focus on making the balloon fly ? 
Kind regards,
On Fri, Aug 11, 2017 at 8:53 PM, Adrian Farrel <> wrote:

The presentation of this draft in Prague seemed to be well received and we got
some comments that we have stated to act on in this revision.

One, non-technical request was to share the work with the SPRING working group,
and I have just done that.

At the meeting I noted that...
> The authors think this is in charter for MPLS
> But polish and discussion is needed before we ask for adoption

As this polish continues, I'd like to ask the list what they think of this work.
Is it going in the right direction? Is it work that you support?


> ________________________________________
> From:
> 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:
> 01.txt
> Status:
> Htmlized:
> Htmlized:
> sr-01
> Diff:
> 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
> The IETF Secretariat

mpls mailing list