Re: [mpls] Éric Vyncke's No Objection on draft-ietf-mpls-sr-over-ip-06: (with COMMENT)

"Adrian Farrel" <> Sun, 02 June 2019 13:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8B954120043; Sun, 2 Jun 2019 06:51:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q6G2tTnnT_Xs; Sun, 2 Jun 2019 06:51:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DCDAF120072; Sun, 2 Jun 2019 06:51:27 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id x52Apr2x013395; Sun, 2 Jun 2019 11:51:53 +0100
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id EE93422044; Sun, 2 Jun 2019 11:51:52 +0100 (BST)
Received: from (unknown []) by (Postfix) with ESMTPS id D966F22042; Sun, 2 Jun 2019 11:51:52 +0100 (BST)
Received: from LAPTOPK7AS653V ([]) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id x52AplWV002106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 2 Jun 2019 11:51:51 +0100
From: Adrian Farrel <>
To: 'Éric Vyncke' <>, 'The IESG' <>
Cc:, 'Loa Andersson' <>,,
References: <>
In-Reply-To: <>
Date: Sun, 02 Jun 2019 11:51:46 +0100
Organization: Old Dog Consulting
Message-ID: <000601d51931$2fef1ff0$8fcd5fd0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJiGtPM7benCz3ctrT6SB1h66WRXKVuKUcw
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--3.845-10.0-31-10
X-imss-scan-details: No--3.845-10.0-31-10
X-TMASE-Result: 10--3.844600-10.000000
X-TMASE-MatchedRID: X4bcv0S75KnxIbpQ8BhdbPVY7U3NX8JgPXu1L28jSnFyV1kxWhGLIYP+ YDa/Dhu91722RZIbhfyToDNbPXi00fr7uaNX5h+5PU/y+iiZLgQX2zxRNhh61SBVkB/ybnTYrTe rBIjuhr5XPwbBzYPCRWeMTFC6wAJPUNX2wOo5Bj+zdV9T3JcQSB51tOwMToE/X1Ahz57P/j5hn7 T+c//ExqngrkDOAdEO23L/7SQRo2JCeO9z35rMgzLRY601LrakLozI+rhNYbkKfrbmG+DbUNkbV xyiYfRTnk6YOJZUyNU7HCCXss+6hfUWuHlgOr4bvOAv94sAIMRPEvlTYRZqWxLf1vz7ecPH1jbV dYnx1Yb5afVp5Xd6vPaozBUyH/uMZh5AF9YXOnqeAiCmPx4NwFkMvWAuahr8i2QFaYS1v20qtq5 d3cxkNZtXyp5XL4L/NyBK+06gt6NBk8MbAYAktOilQYN96FHKaz/V9WI5Bsk/fZ9Mes4pKvPtWE uoG0ZhfzalErchOFJqpInhlKl75+xxaF/gNBFyp8i26iGCN+fD/c2Y8mxrik1Z+dSdugwvVNdRf R1NB08=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [mpls] Éric Vyncke's No Objection on draft-ietf-mpls-sr-over-ip-06: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 02 Jun 2019 13:51:32 -0000

Hi Eric,

Thanks for squeezing in the extra review: much appreciated.

> == COMMENTS ==
> Generic question of mine: is there a way to leverage SRv6 in
> the underlay ?

Depends what you mean by "leverage" :-)

The full-blown leveraging is to use SRv6 and move on. There are many who would say that that should be the principal focus.

Here we are looking at how to move ahead with limited SR capabilities and run over an existing network. That underlay network could certainly be IPv6 (or IPv4 or MPLS), and one of the reasons we use UDP as an encapsulation is because it is agnostic about the underlay technology. (There are, of course, other reasons for choosing UDP.)

> -- Section 3.2.3 --
> About the IP encapsulation, is the hop limit / TTL simply copied from the
> 'payload packet header'? What is the procedure at the exit of the tunnel wrt
> hop limit / TTL of the 'payload packet header' ?

There is a bit of chain of dependencies to follow here. We have tried to not change the core MPLS-in-UDP rules set in RFC 7510, so I could just point you there. But you would find that 7510 hands the baton to 4023 (MPLS-in-IP and MPLS-in-GRE), and section 5.2 is the place to look to see how to set the TTL in the encapsulating packet.

At transit points on the tunnel, the TTL is (of course?) handled as normal for the encapsulating layer. 

At the end point of the tunnel there are two tasks:
1. Process the packet according to the encapsulating layer, just as we would for any other packet destined to a local address. No change there.
2. Process the payload packet. Once the encapsulation has been stripped, the TTL of the payload must be processed. Per 4023, the remaining encapsulation TTL may be copied into the payload if (and only if) doing so does not increase the payload TTL value. 

In all these three places on the path, we are not altering 7510 and 4023 behavior.