Re: [mpls] Alvaro Retana's Comments on draft-ietf-mpls-sr-over-ip-03:

"Adrian Farrel" <> Sat, 13 April 2019 17:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 693111202E5; Sat, 13 Apr 2019 10:29:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ufObBo8obtAo; Sat, 13 Apr 2019 10:29:41 -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 63585120072; Sat, 13 Apr 2019 10:29:41 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id x3DHTb6I006317; Sat, 13 Apr 2019 18:29:37 +0100
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 880432203B; Sat, 13 Apr 2019 18:29:37 +0100 (BST)
Received: from (unknown []) by (Postfix) with ESMTPS id 720DE2203A; Sat, 13 Apr 2019 18:29:37 +0100 (BST)
Received: from LAPTOPK7AS653V ([]) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id x3DHTaOp009344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 13 Apr 2019 18:29:36 +0100
Reply-To: <>
From: "Adrian Farrel" <>
To: "'Alvaro Retana'" <>, "'The IESG'" <>
Cc: <>, "'Loa Andersson'" <>, <>, <>
Date: Sat, 13 Apr 2019 18:29:35 +0100
Organization: Old Dog Consulting
Message-ID: <07cb01d4f21e$77887800$66996800$>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AdTyHlm4BhpszzzJTAyRz6KjfvYBgQ==
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--15.629-10.0-31-10
X-imss-scan-details: No--15.629-10.0-31-10
X-TMASE-Result: 10--15.629100-10.000000
X-TMASE-MatchedRID: 8+bhjh9TQnHxIbpQ8BhdbJmug812qIbzC/ExpXrHizwzFWOYrWw6A7y+ AbgLgbEp1ZwcxAra+aa65eNqioKhhBSZwLQuUqmCM8ORI7N4NZZMkOX0UoduuRmy1DfGOok3ZVh gLjSOksYBEAo173VscTWls7ybKDg4otcND2Gb6hRH4a2iJdV4MYnsgRUxNfnHnNgWxWMgxzLIP2 ZkzYGAidLoqdbfb7hikrvm8EJ4+WexpgqXoiq0QaSkqjfmd3aeOhJ9m53n4aCVvypVes2MRYMdL BQl5wHaIou7tFEkkkcGMk4xUJf2CjurH0qx1kBY7TLIvnWov9HyVbjbSjLWDGsxtqQk3w55A5He 1kDS+OLnzlXMYw4XMAGLeSok4rrZU6baA36eiazEQdG7H66TyH4gKq42LRYkcjCQtM0L3jnI530 Zhtdq2hHxNiejHmDwtdOUTC6mzEd+3BndfXUhXQ==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [mpls] Alvaro Retana's Comments on draft-ietf-mpls-sr-over-ip-03:
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: Sat, 13 Apr 2019 17:29:43 -0000

Hi Alvaro,

Again punting on your Discuss for a moment.

> Thank you for writing this document!
> In general, the use of terminology (defined in rfc8402 and elsewhere)
> needs to be cleaned up throughout the document.

That's a fine aspiration. Could you give us some pointers to terms that are used uncleanly?

> (1) [nit] From the Abstract: "SR-MPLS could be leveraged...while preserving
> backward compatibility with SR-MPLS."  I'm sure you want to say something
> related to making no changes to SR-MPLS for this application...the use of
> backwards compatibility with itself just sounds strange.  The Introduction has
> similar text, but it does go on to clarify a little.

OK. Abstract text becomes...

      SR-MPLS can be leveraged
      to realize a source routing mechanism across MPLS, IPv4, and IPv6 data
      planes by using an MPLS label stack as a source routing instruction set
      while making no changes to SR-MPLS specifications and interworking with
      SR-MPLS implementations.

Similar tweak to the Introduction.

> (2) [nit] §3.1: "the FIB can be used to tell a router how to process packets" 
> The FIB is generally in the router, so no need to tell it anything. ;-)  Maybe:
> "the FIB can be used by the router to process packets".

OK. Changed to:
        Once constructed, the FIB can be used by a router to tell it how to
        process packets.

> (3) §3.2: "Not all of the nodes in an SR-MPLS domain are SR-MPLS capable."  By
> definition, all nodes in an SR domain participate in the source-based routing
> model [rfc8402].  I think that you meant to say that not all nodes in the
> network (or maybe just the domain) are SR-MPLS capable.

The definition of "SR Domain" is a good subject for debate.
"Participating in the source-based routing model" means what?
A transit node in an SRv6 domain routes packets using the IGP to the current DA in the header. Such nodes do not need to be SRH-capable or SRH-aware. But I think they are within the domain.

A similar discussion has been going on in 6man with respect to the phrase "All intra SR Domain packets are of the SR Domain" in draft-ietf-6man-segment-routing-header-17.txt

> Note that the SR domain in the networks in Figure 1, for example, includes both
> the SR-MPLS networks at both sides and the tunneled portion.  If you mean for
> that picture to represent 3 different SR domains, then please don't use
> "SR-MPLS domain" to describe what is happening in the IP network portion.

I think your comments are harsh. The term "domain" is not used in that context. In fact, the term "domain" is not used until section 3.

Maybe we could completely not use the term. But it seems (to me) to be a good term to describe nodes on the path from SR source to SR destination.

> (4) §3.2: "There are six types of node in an SR-MPLS domain..."  Again, I think
> you mean to point at the types of nodes in the network and not in the SR domain.

Nope, the text is accurate and deliberate. The six subsections that follow describe the cases.
All of the node types are within the SR domain (that is, between entry point where encapsulation happens and exit point where decapsulation happens).

> (5) Security Considerations:  Please also point at the considerations in
> rfc8402.