Re: [mpls] MPLS-RT review on draft-ninan-mpls-spring-inter-domain-oam-02

Adrian Farrel <> Fri, 04 June 2021 13:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4EF123A11A4; Fri, 4 Jun 2021 06:50:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.051
X-Spam-Status: No, score=-1.051 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MAY_BE_FORGED=0.846, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aymZQRUH5k1l; Fri, 4 Jun 2021 06:50:50 -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 541F13A11A2; Fri, 4 Jun 2021 06:50:49 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id 154DolDo031129; Fri, 4 Jun 2021 14:50:47 +0100
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id DF2844604B; Fri, 4 Jun 2021 14:50:46 +0100 (BST)
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id D2EC246048; Fri, 4 Jun 2021 14:50:46 +0100 (BST)
Received: from (unknown []) by (Postfix) with ESMTPS; Fri, 4 Jun 2021 14:50:46 +0100 (BST)
Received: from LAPTOPK7AS653V ( [] (may be forged)) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id 154DojIE008619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Jun 2021 14:50:46 +0100
From: Adrian Farrel <>
References: <> <> <>
In-Reply-To: <>
Date: Fri, 04 Jun 2021 14:50:45 +0100
Organization: Old Dog Consulting
Message-ID: <071b01d75948$9e6cd950$db468bf0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHSSwWfztk50xVVXXoyRJh0RXJfMQJ/cec0AghmOdqq6bkqUA==
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--25.679-10.0-31-10
X-imss-scan-details: No--25.679-10.0-31-10
X-TMASE-Result: 10--25.679400-10.000000
X-TMASE-MatchedRID: b/1IsOqez6eWfDtBOz4q23FPUrVDm6jt+IfriO3cV8RTpFNEkr6HJoda YX5m6/4YR8EC1tit1BvmcHnEPnqenmcPPLBO2A0bkmtbTcNpxYSZrgJQpYk0sxgoY1prIgoItzB kuk8VO0C3p6/YFpFOqmWM9bBlorLigU6Zx32xJGJyxbfjhbMtyODTYjejIZTwLX3qyf3ewG+tg0 pkemZ4ojnpSV66h8LNVDbs0z7KrCUZPA3643YXYorkmrf0Igi/h1VTeTxSalHLkl8e9W70izaqW BgHP7EjOa2iSLW78KeXimJN0T8TujOOxCxJsyam8pRHzcG+oi0KF0jiwuWuOCGD+Fp3vZHU8f4S tkBOa36aaBYwlL5lPqzGU31jm862CePRqObI81crT6V6InEuV0jEWwwu715sdcfU63y8xPC95iY VgizGV+zAnKDfeixr7c2dg3HqZ1g3DY7ZrB9oHCfphWrcxCwjpNh/2/1+WiWqvcIF1TcLYHyzv7 t8jixK4K9FmervsqUtPe52cSCmDLfptZTbFVSKKZ73BulBsrkUg4oIuVTlOH9nRLJB1yYQfF4vd Mjb6UzE7gW9Nmz5nEiM5ASkVZ8SCpuZLe/V2zHY6EGR3k/uimj1CdgkJWDyZ7zzpl+OAuJnbyAT PFLi0kW/yMoEqTx3FOzk8G4VOiw5HWa1kxc3MQuLP4ROdWHVbXmIkXx4Tqu15eNIExieaQhcpg6 xdvxtBm33ka/xTVdqVVqMUD2FvXMncJz91M+xtT4jIeGRd/XExmr5hqNL1qY7XH28Hn1Ro8WMkQ Wv6iV5glWMeWj1NKebHCxzBV4TKzfM9B6IRt76C0ePs7A07YVH0dq7wY7uA/3R8k/14e0=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [mpls] MPLS-RT review on draft-ninan-mpls-spring-inter-domain-oam-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: Fri, 04 Jun 2021 13:50:55 -0000

Hi All,

I'm late to this party. Sorry. Responding on the top of thread to make it
easier to find.

I understand why you use the term "domain" and it would be perfectly
reasonable except that RFC 8402 takes that term and gives it very specific
meaning, admittedly as "SR domain" most of the time, but degrading to just
"domain" on page 7. 8402 does also have one mention of "IGP domain" and one
of "routing domain". Section 4.2 got away with "source-routed inter-domain
paths" while Section 8 says that SR operates "within a trusted domain" with
traffic filtering at domain boundaries (section 8.1 has a lot of information
that should be relevant to this document).

Recently, there has been a lot of confusion (in the IESG, for example) as to
what the scope and limits of an "SR domain" are. I think that a lot of this
comes from Section 8 of RFC 8402. At the very least, there was a
misunderstanding of the intended scope of SR since (except in a few multi-AS
companies) adjacent ASes to not have a shared trust model.

I suggest that you take some time (probably in Section 1) with a new
subsection on "Definitions of Domain" to try to clarify this.

One thing we noticed in pushing draft-ietf-bess-datacenter-gateway through
the IESG was that it is possible to build on the "SR domain" concept in a
constructive way such that it is constructed of:
- all nodes in the source SR-enabled network
- all nodes in the destination SR-enabled network
- all ASBRs along the path from source to destination network

While it may (or may not) be the case that the transit nodes in an AS are
SR-enabled, it is not important to the way you are building an "SR overlay".


-----Original Message-----
From: mpls <> On Behalf Of Mach Chen
Sent: 04 June 2021 02:55
To: Shraddha Hegde <>;
Subject: Re: [mpls] MPLS-RT review on

Hi Shraddha,

Thanks for considering the comments, looking forward to the revision.

Best regards,

> -----Original Message-----
> From: Shraddha Hegde []
> Sent: Thursday, June 3, 2021 12:30 PM
> To: Mach Chen <>;
> Cc:;
> Subject: RE: MPLS-RT review on draft-ninan-mpls-spring-inter-domain-oam-02
> Hi Mach,
> Thanks for the review.
> Pls see inline ...
> Juniper Business Use Only
> -----Original Message-----
> From: Mach Chen <>
> Sent: Wednesday, June 2, 2021 9:29 AM
> To:
> Cc:;
> Subject: MPLS-RT review on draft-ninan-mpls-spring-inter-domain-oam-02
> [External Email. Be cautious of content]
> Hi,
> I am selected as a MPLS-RT reviewer of
> draft-ninan-mpls-spring-inter-domain-oam.
> After review, I think the problem that the draft is trying to address is
valid and
> useful. The solution is overall workable. My comments are mainly about
Type 3
> and Type 4 segment sub-TLV, I think it's better to address these comments
> before the adoption.
> <Shraddha> Sure.
> Type 3 and 4 sub-TLVs are supposed to be used when the headend/PMS does
> not have the labels or SRGB information of the remote nodes, <Shraddha>
> because  these remote nodes lie in a different domain and SRGB information
> may not be available at the headend in some cases.
>  and assume that the receiving node (egress node) can derive the MPLS
> according to the IPv4/IPv6 addresses.
> <Shraddha>
> I will add a section with  example of multi-domain network with different
> and explain how Type 3 and Type 4 Segments can be used while building the
> return path dynamically for traceroute. The key is only the top segment
has to be
> Type 3/Type 4 the remaining segments to be of type label. For the Top
> label has to be derived from the SRGB of the receiving node (not someone
> so its expected to be available.
> This assumption may not hold, because given that the headend/PMS does not
> have the information, it is very likely that the receiving node has no the
> information either. So the draft should add more text to clarify the use
cases of
> type 3, 4 sub-TLVs, or just remove them.
> <shraddha> I'll add more text to describe clearly how type3/Type 4 should
> used.
> In addition, given type 3 and 4 have valid use case, the optional SID
fields of type
> 3 and 4 are redundant, I think that they should be removed.
> <shraddha> SIDs are optional anyway. I would prefer to keep it in order to
> consistent with segment routing
> path description.
> Section 4,
> "Below types of segment sub-TLVs are applicable for the Reverse Path
>    Segment List TLV."
> Should the "Reverse Path Segment List TLV" be "Return Path TLV"?
> <shraddha> Good catch. I'll fix it.
> Best regards,
> Mach

mpls mailing list