Re: [mpls] Opsdir last call review of draft-ietf-mpls-sr-over-ip-02

"Adrian Farrel" <> Sun, 17 February 2019 11:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C92AA127AC2; Sun, 17 Feb 2019 03:19:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JMQeJbzdsQe0; Sun, 17 Feb 2019 03:19:17 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F19CE128B01; Sun, 17 Feb 2019 03:19:13 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id x1HBJ7uP021004; Sun, 17 Feb 2019 11:19:07 GMT
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 5D4882203B; Sun, 17 Feb 2019 11:19:07 +0000 (GMT)
Received: from (unknown []) by (Postfix) with ESMTPS id 46B822203A; Sun, 17 Feb 2019 11:19:07 +0000 (GMT)
Received: from LAPTOPK7AS653V ([]) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id x1HBJ1Pd025578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 17 Feb 2019 11:19:05 GMT
From: Adrian Farrel <>
To: 'Al Morton' <>,
References: <>
In-Reply-To: <>
Date: Sun, 17 Feb 2019 11:18:59 -0000
Organization: Old Dog Consulting
Message-ID: <00ef01d4c6b2$98102420$c8306c60$>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGBGQl8mGC2K5R3NLNQWApPimb6ZKaLMFcA
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--11.092-10.0-31-10
X-imss-scan-details: No--11.092-10.0-31-10
X-TMASE-Result: 10--11.092100-10.000000
X-TMASE-MatchedRID: fE0JoqABJp3xIbpQ8BhdbOYAh37ZsBDCC/ExpXrHizzlJZht6cF9xFM1 EzrOOwvWQkIpLU6y2ndal/o0mVdrU054kNlzd6J3cFEiuPxHjsUICu6i14k6HPgnJH5vm2+gFhM gncTYqyS0JGeVHQ04WopMlj66NgD77Hz728uiamCcnm0v4tsY4ziAbW+oEE345VavBrAV4wUNqg 8odlnkKKaBafyu8kavPvqiJzbDmiyrSqv5DWrMSh47EGkpGeA9OkDbNlgmO/UN+H+9vY7EAGVYY C40jpLGTupBKcY88KK4VxGFQBNJeNUMAwTDOBnsbuFuYBIpyuk38FNTll9lEuedK36PXYKWmi3F G4ndT6WEjbv1/pAnVVb+d1W2AA/qhPc4FTJN6V5I9rD1ir7Z9L8+q17GFLKRmyiLZetSf8my5/t FZu9S3AV1uwb6J5fHC24oEZ6SpSkj80Za3RRg8B5g4ELUg4CGm+Yg55upS4XCkIkNXnqRGLbSWE lXgokXEze1V/T0TyU=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [mpls] Opsdir last call review of draft-ietf-mpls-sr-over-ip-02
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, 17 Feb 2019 11:19:20 -0000

Hi Al,

Thanks very much for reviewing.

Responses in line.

> Thanks for preparing this draft.
> Providing transition methods is very welcome to
> Operations.

We aim to please 😊

> There seem to be a few more opportunities to employ
> Requirements Language in this draft (currently only
> 3 MUSTs and 2 MAYs), to improve the consistency of 
> implementations and subsequent adoption in operations.

You are right.
The original vision for this document was Informational (telling you how to use existing tools), so the Requirements language only crept in as we moved to Standards Track, and we should probably have more of it.

> For example:
> Section 2:
>   o  Incremental deployment of the SR-MPLS technology may be
>      facilitated by tunneling SR-MPLS packets across parts of a network
>      that are not SR-MPLS enabled using an IP tunneling mechanism such
>      as MPLS-in-UDP [RFC7510].  The tunnel destination address is the
>	                                                           ^^^^
>      address of the next SR-MPLS capable node along the path (i.e., the
>      egress of the active node segment).  This is shown in Figure 1.
> Setting the Dst address correctly seems to be a requirement,
> because this material in Section 2 is referenced later, in 3.2.3.
> This seems a reasonable spot for s/is/SHOULD be/ at least.

Well, in this specific case I'm going to agree with you, but for a different reason. You don't set a destination address, you pick a tunnel that has an end point.

So we should probably write...
      The tunnel destination address is the
      address of the next SR-MPLS capable node along the path (i.e., the
      egress of the active node segment).
      The tunnel selected MUST have its remote end point (destination)
      Address equal to the address of the next SR-MPLS capable node 
      along the path (i.e., the egress of the active node segment).

> Section 3.1 FIB construction relies on about 5 drafts: 
> much work in progress, just noting dependencies (no action)

Yes, it is sad for me that the SR work still lingers in the pipe.

> SRGB - ?? spell-out at first use

Good catch.
Segment Routing Global Block

> Section 3.2.3. Additional Forwarding Procedures
>      IP Header Fields:  When encapsulating an MPLS packet in UDP, the
>      resulting packet is further encapsulated in IP for transmission.
>      IPv4 or IPv6 may be used according to the capabilities of the
>      network.  The address fields are set as described in Section 2.
>	                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>      The other IP header fields (such as DSCP code point, or IPv6 Flow
>      Label) on each UDP-encapsulated segment can be set according to
>	                                          ^^^^^^^^^^
>      the operator's policy:
> s/can be set/SHOULD be configurable/