Subject: Re: [mpls] I-D Action: draft-zheng-mpls-lsp-ping-yang-cfg-06.txt

From: "Faisal Iqbal (faiqbal)" <[email-masked]>
Date: Tue, 14 Nov 2017 22:27:05 +0000

Dear Authors,
Thank you for initiating the work on Yang Model for LSP Ping and sharing your draft. I have gone through the document and find it very useful and important work item. Please see below for some comments on the document. I'm still a beginner in Yang modeling so I apologize if I'm missing something obvious or well-understood.

Sec 3.1 - I think the document aims to specify various existing MPLS OAM targets (including P2MP) through a combination of target-fec-type and target-fec structure. Is my understanding correct?

Sec 3.1 - I did not find a way to specify some important parameters in the container control-info that operators can use to control echo request path or other parameters. Specifically:

i.                 Operator should be allowed to specify RSVP interface by tunnel name as well. For some operators, name may be more meaningful than tunnel number.

ii.                A field to provide a destination address in 127/8 range.

iii.               An option to specify a range of destination addresses to test e.g. give destination start address 127.0.0.1 and end address 127.0.0.8, system will initiate 8 echo requests correspondingly.

iv.               Given that TTL is a field in the container control-info, I feel that operator should be given an option to specify whether or not to use Downstream Detailed Mapping (DDMAP) TLV, or even the deprecated DSMAP TLV.

v.                Operator should also be allowed to specify DDMAP TLV sub-TLV fields such as the presence, type, and size of multipath TLV.

Sec 3.3 - I had following questions about the result-info structure.

i.                 If the echo reply contains a TLV (e.g. DDMAP TLV for request to a transit node), how will we communicate that information to the user? Operator may use LSP Ping to identify downstream path(s) from a particular downstream node.

ii.                What does probe-index refer to?

Sec 6 - For target-fec-type, is there a way for operator to specify a particular control plane or FEC (as defined in RFC-8029 e.g. LDP, Generic FEC etc.) to be used for echo request?

Does this document only tackle LSP Ping operation? Would other echo request operations such as LSP Traceroute for LSP path discovery be documented separately?

Some minor editorial comments below.
-"Model presented in [RFC4560];" instead of "Model presented in[RFC4560] ;" in Section 1.2
-Text in Section 3 should read "...and result information for multiple instances of LSP-Ping test." Instead of "...and result information for multi instances of LSP-Ping test."
- "IETF Multiprotocol" instead of ""IETF Multiprotocl" in Section 6.
-Description for enum success should read "The test probe is successful" instead "The test probe is successed"
-Description for leaf sum-of-squares in Section 6 should read "replies" instead of "replys"

Regards,
Faisal Iqbal

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 17 Nov 2017 11:09:16 +0800

Hi Faisal,
many thanks for your detailed and thoughtful comments, suggestions. I'll
read it all very carefully once get out of IETF meeting adrenaline rush
(early next week). In the meantime, thank you and looking forward to work
with you on the model.

Regards,
Greg

On Wed, Nov 15, 2017 at 6:27 AM, Faisal Iqbal (faiqbal) <[email-masked]>
wrote:

> Dear Authors,
>
> Thank you for initiating the work on Yang Model for LSP Ping and sharing
> your draft. I have gone through the document and find it very useful and
> important work item. Please see below for some comments on the document.
> I’m still a beginner in Yang modeling so I apologize if I’m missing
> something obvious or well-understood.
>
>
>
> Sec 3.1 – I think the document aims to specify various existing MPLS OAM
> targets (including P2MP) through a combination of target-fec-type and
> target-fec structure. Is my understanding correct?
>
>
>
> Sec 3.1 – I did not find a way to specify some important parameters in the
> container control-info that operators can use to control echo request path
> or other parameters. Specifically:
>
> i.                 Operator should be allowed to specify RSVP interface
> by tunnel name as well. For some operators, name may be more meaningful
> than tunnel number.
>
> iii.               An option to specify a range of destination addresses
> to test e.g. give destination start address 127.0.0.1 and end address
> 127.0.0.8, system will initiate 8 echo requests correspondingly.
>
> iv.               Given that TTL is a field in the container
> control-info, I feel that operator should be given an option to specify
> whether or not to use Downstream Detailed Mapping (DDMAP) TLV, or even the
> deprecated DSMAP TLV.
>
> v.                Operator should also be allowed to specify DDMAP TLV
> sub-TLV fields such as the presence, type, and size of multipath TLV.
>
>
>
> Sec 3.3 – I had following questions about the result-info structure.
>
> i.                 If the echo reply contains a TLV (e.g. DDMAP TLV for
> request to a transit node), how will we communicate that information to the
> user? Operator may use LSP Ping to identify downstream path(s) from a
> particular downstream node.
>
> Sec 6 – For target-fec-type, is there a way for operator to specify a
> particular control plane or FEC (as defined in RFC-8029 e.g. LDP, Generic
> FEC etc.) to be used for echo request?
>
>
>
> Does this document only tackle LSP Ping operation? Would other echo
> request operations such as LSP Traceroute for LSP path discovery be
> documented separately?
>
>
>
> -“Model presented in [RFC4560];” instead of “Model presented in[RFC4560]
> ;” in Section 1.2
>
> -Text in Section 3 should read “…and result information for multiple
> instances of LSP-Ping test.” Instead of “…and result information for multi
> instances of LSP-Ping test.”
>
> - "IETF Multiprotocol” instead of “"IETF Multiprotocl” in Section 6.
>
> -Description for enum success should read “The test probe is successful”
> instead “The test probe is successed”
>
> -Description for leaf sum-of-squares in Section 6 should read “replies”
> instead of “replys”
>
>
>
> Regards,
>
> Faisal Iqbal
>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 28 Nov 2017 18:07:38 -0800

Hi Faisal,
apologies for the delay to respond to your thorough review of the MPLS LSP
ping data model and great comments. Please find my answers and notes
in-line and tagged GIM>>.
I'm looking forward to be working with you as co-author on this draft. Hope
you'll agree.

Regards,
Greg

> target-fec structure. Is my understanding correct?
GIM>> Yes, you're absolutely correct.

> by tunnel name as well. For some operators, name may be more meaningful
GIM>> I think we may use tunnel-ref and tunnel-p2mp-ref defined
in draft-ietf-teas-yang-te.
GIM>> And extending your suggestion, should it be for other FECs, for
example, static?

> 127.0.0.8, system will initiate 8 echo requests correspondingly.
GIM>> I like the idea to provide optional controls over entropy of LSP
Ping. These may be useful not only for LSP Ping but BFD over MPLS LSP.

> sub-TLV fields such as the presence, type, and size of multipath TLV.
GIM>> Agree. And what the defaults could be?

> ii.                What does probe-index refer to?
GIM>> Index of an LSP ping within a test session.

> FEC etc.) to be used for echo request?
GIM>> It must be extended, agreed. I think it is r/w. Not?

> request operations such as LSP Traceroute for LSP path discovery be
GIM>> Great observation! Traceroute should be supported. Path discovery?

> -Description for leaf sum-of-squares in Section 6 should read “replies”
GIM>> Thank you, Faisal. Will include in the next update.