Hi Bing,
Thank you for the confirmation.
I've posted the new -07 version to incorporate the change agreed by us. Link as below.
https://datatracker.ietf.org/doc/html/draft-ietf-mpls-spring-lsp-ping-path-sid-07
Cheers,
Xiao Min
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
