[Last-Call] Re: [mpls] draft-ietf-mpls-spring-lsp-ping-path-sid-06 ietf last call Opsdir review

["Liubing \(Leo\)" <leo.liubing=40huawei.com@xxxxxxxxxxxxxx>]

Hi Xiaomin,

 

Thanks for your quick reply and addressing my comment. And pardon for my slow response due to the Labor’s Day holiday.

The revision is a minimal usage description, but maybe it’s already sufficient. So I’m ok with the current version. (A bit more scenario/background would be better if you wish.)

 

B.R.

Bing

 

From: xiao.min2@xxxxxxxxxx <xiao.min2@xxxxxxxxxx>
Sent: Friday, May 2, 2025 10:32 AM
To: Liubing (Leo) <leo.liubing@xxxxxxxxxx>
Cc: ops-dir@xxxxxxxx; draft-ietf-mpls-spring-lsp-ping-path-sid.all@xxxxxxxx; last-call@xxxxxxxx; mpls@xxxxxxxx
Subject: Re: [mpls] draft-ietf-mpls-spring-lsp-ping-path-sid-06 ietf last call Opsdir review

 

Hi Bing,

 

Thanks for your Opsdir review and comments.

The abstract of RFC 8029 says "

The MPLS echo request is intended

   to contain sufficient information to check correct operation of the

   data plane and to verify the data plane against the control plane,

   thereby localizing faults.

"

The extensions defined in this draft inherits the intention of LSP Ping introduced by RFC 8029.

Would the following updates to the Introduction section address your comments?

OLD

Procedures for LSP Ping

   [RFC8029] as defined in [RFC8287] and [RFC8690] are applicable to

   PSID as well.  Note that LSP Traceroute [RFC8287] is left out of this

   document because the transit node is not involved in PSID processing.

NEW

Procedures for LSP Ping

   [RFC8029] as defined in [RFC8287] and [RFC8690] are applicable to

   PSID as well, which can be used to check correct operation of the PSID and to verify the PSID against the control plane.  Note that LSP Traceroute [RFC8287] is left out of this

   document because the transit node is not involved in PSID processing.

 

Cheers,

Xiao Min

Original

From: BingLiuviaDatatracker <noreply@xxxxxxxx>

To: ops-dir@xxxxxxxx <ops-dir@xxxxxxxx>;

Cc: draft-ietf-mpls-spring-lsp-ping-path-sid.all@xxxxxxxx <draft-ietf-mpls-spring-lsp-ping-path-sid.all@xxxxxxxx>;last-call@xxxxxxxx <last-call@xxxxxxxx>;mpls@xxxxxxxx <mpls@xxxxxxxx>;

Date: 2025年04月30日 17:22

Subject: [mpls] draft-ietf-mpls-spring-lsp-ping-path-sid-06 ietf last call Opsdir review

Document: draft-ietf-mpls-spring-lsp-ping-path-sid
Title: Label Switched Path (LSP) Ping for Segment Routing (SR) Path Segment
Identifier with MPLS Data Plane Reviewer: Bing Liu Review result: Has Nits

Hi Dear author, I'm assigned to review
draft-ietf-mpls-spring-lsp-ping-path-sid-06 by OPSDir.

General status: Has Nits
This document is a concrete proposal of defining PSID FEC sub TLVs for LSP
Ping. The content and node behavior of the sub-TLVs is well specified in
details. No problems found in tehchnical perspective.

The Nit:
I've been a bit confusing of what is the usage of the newly defined TLVs when
firstly read the draft. Then I found it might be mainly for verification of the
conformance between the control plane and the data plane for a given FEC, based
on some texts "hidden" in the sub-TLV definition section. (And yet, not very
sure whether there might be other usage.) I'd suggest to add some
background/scenarios description in Section 1 and also summarize it in the
abstract. I believe it would be very helpful to navigate the readers who don't
know the bachground of this work.

B.R.
Bing


_______________________________________________
mpls mailing list -- mpls@xxxxxxxx
To unsubscribe send an email to mpls-leave@xxxxxxxx

 

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx