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

[Greg Mirsky <[e-mail]>]

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) <[e-mail]>
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.
>
> 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
>