Re: [mpls] Question on draft-lm-mpls-sfc-path-verification Fri, 18 September 2020 15:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 24F753A0C31; Fri, 18 Sep 2020 08:08:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KCvxTWdr8T74; Fri, 18 Sep 2020 08:08:32 -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 3C41C3A0B75; Fri, 18 Sep 2020 08:07:49 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTPS id A9E9AC1F7DA8F842F2BD; Fri, 18 Sep 2020 23:07:47 +0800 (CST)
Received: from (unknown []) by Forcepoint Email with ESMTPS id 8DDF3255934EE880FBB4; Fri, 18 Sep 2020 23:07:47 +0800 (CST)
Received: from ([]) by with SMTP id 08IF7kUO074490; Fri, 18 Sep 2020 23:07:46 +0800 (GMT-8) (envelope-from
Received: from mapi (njxapp02[null]) by mapi (Zmail) with MAPI id mid203; Fri, 18 Sep 2020 23:07:46 +0800 (CST)
Date: Fri, 18 Sep 2020 23:07:46 +0800 (CST)
X-Zmail-TransId: 2afa5f64cd42290c32ea
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <>
Mime-Version: 1.0
From: <>
To: <>
Cc: <>, <>, <>
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: 08IF7kUO074490
Archived-At: <>
Subject: Re: [mpls] =?utf-8?q?Question_on_draft-lm-mpls-sfc-path-verification?=
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, 18 Sep 2020 15:08:34 -0000

Hi Loa,

Thanks for your questions and suggestions.

Please see in line with [Yao].


发件人:LoaAndersson <>
抄送人 <>; <>; <>rg>;
日 期 :2020年09月18日 11:16
主 题 :Re: Question on draft-lm-mpls-sfc-path-verification


So most is sorted out :).

Some small issues.

On 17/09/2020 18:47, wrote:
> The SFC Basic Unit FEC Sub-TLV maybe included in a SFC Validation TLV
> carried both in a MPLS echo request and a MPLS echo reply.
>  Currently 
"currently means that it is defined in section 3.3 of 
draft-lm-mpls-sfc-path-verification, right. I find the definition is 3.3 
rather weak, more detals is needed. e.g. that the sub-tlv is defined for 
FEC Stack TLV (TLV #1).

[Yao] Got it. The details of the definition and processing procedure will be added to the section.

the SFC Basic Unit FEC Sub-TLV is denfined as a sub-TLV

> of the Target FEC Stack TLV,  carried in a MPLS echo request. Its usage 
> is similar to other sub-TLVs of the Target FEC Stack. 
ok- fine, but the sub-TLVs are shared between TLV 1, 16, and 21. Is that 
true for the SFC Basic Unit FEC Sub-TLV?

[Yao] If the SFC is bi-directional, the SFC Basic Unit FEC Sub-TLV can be carried in TLV 16 for reverse SFP connectivity verification or in TLV 21 to carry the specified return SFP info to be used by the echo reply.  There are more details needed in this section as you said. I'll make it clearer.

The information
> carried in the Basic Unit FEC Sub-TLV is obtained from the control 
> plane.  After receiving a MPLS echo request with the Target FEC Stack 
> TLV and the SFC Basic Unit FEC Sub-TLV included, an SFF may enter the 
> FEC validation procedure to check whether the information is the same 
> between the control place and the local data plane. If the validation is 
> not passed, the SFF will generate an MPLS echo reply with an error code 
> as defined in RFC8029.
OK - and you need to point out the range from which the sub-tlv should 
be allocated.

[Yao] OK, I will add the paragraph about the allocation in the next version and I believe that the sub-TLV should be allocated from range 0-16383, which is standards action.



Plz note that we are doing updates to the LSP Ping registry, so far I 
have not seen anything that directly have an impact on this draft.
See - draft-ietf-mpls-lsp-ping-registries-update-.

[Yao] Thanks for reminding~ I'll go through the draft to learn more about it. 



Loa Andersson                        email:
Senior MPLS Expert                
Bronze Dragon Consulting             phone: +46 739 81 21 64