Re: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping-reply-mode-simple

[Sam Aldrin <[e-mail]>]

[Better late than never]

Thank you Nobo, for replying to my comments with %sam.
See inline for my comments. Removed ones which I considered were answered,
for readability sake. Hope you don't mind it.

-sam




>
> - In sec 2
>
> Some return path(s) are more preferred than others, but preferred
>
>    cannot be used in all cases.  Thus implementations are required to
>
>    compute when preferred return path encoding can and cannot be used,
>
>    and that computation is becoming more and more difficult.
>
>
>
> As response code is initiated by the initiator, user in this case, the
> preferred return path is for UI implementation and not the actual LSP ping
> functionality. Which/what part of implementation are you referring to?
>
>
>
> [NOBO] Ok, this below text more clearer?
>
>
>
> [snip]
>
>    Operators prefer some return path(s) over others for specific LSP
>
>    types.  To accommodate this, implementations may default to operator
>
>    preferred return path (or allow default return path to be configured)
>
>    for specific operation.  However, if the sender of MPLS echo request
>
>    knew that "preferred" return path will not be available at intended
>
>    target node, then it is not very beneficial to specify Reply Mode
>
>    corresponding to "preferred" return path (i.e. sender of MPLS echo
>
>    request will not receive MPLS echo reply in the success case).  What
>
>    would be beneficial, for a given operation, is for the sender of MPLS
>
>    echo request to determine which return path(s) can and cannot be used
>
>    ahead of time.  Thus implementations often compute when preferred
>
>    return path encoding can and cannot be used, and that computation is
>
>    becoming more and more difficult.
>
> [snip]
>
%sam - Looks ok, but don't mind removing last sentence. :D

>
>
> - Sec 2
>
> This document adds one Reply Mode to describe reverse LSP, and one
>
>    optional TLV to describe ordered list of reply modes.  Based on
>
>    operational needs, the TLV can describe multiple Reply Mode values in
>
>    preferred order to allow responder to use first available Reply Mode
>
>    from the list.  This eliminates the need for initiator to compute, or
>
>    sometimes "guess", the "default" return path encoding.  And that will
>
>    result in simplified implementations across vendors, and result in
>
>    improved usability to fit operational needs.
>
>
>
>
>  - Sec 3.1, how is this different from RFC 7110? If same, please call it
> out here and remove TBD1 as sec 4.1 of RFC7110 added reply mode 5 for the
> same. If different to the RFC, I would like to see those details here.
>
>
>
> [NOBO] Reply Mode introduced by RFC7110 specifies that MPLS echo reply is
> to be sent on LSP corresponding to FEC described in Reply Path TLV.
> Although Reply Path TLV has added B flag to indicate "reverse LSP", Reply
> Mode 5 still require Reply Path TLV with B flag to describe "reverse LSP".
> Reply Path TLV is good when wanting to use specific LSP as return path, but
> it's more difficult than necessary when wanting to just use reverse LSP. I
> will add some texts to clarify this.
>
%sam - Are you saying that reply mode 5 with B bit set is not solving the
problem or not optimal (because a TLV is being added?). The text in RFC7110
says, "B (Bidirectional): the return path is required to follow the

         reverse direction of the tested bidirectional LSP.  If B bit is
         set, there is no need to carry any specific reply path sub-

         TLVs, and when received, the sub-TLVs SHOULD be ignored."
As author of RFC7110 is also author of this draft, it would be good to
clarification. From what I see, this new reply mode  proposed in this draft
is already addressed in RFC7110. If the new reply mode adds optimization to
the existing solution, why to add a new mode?

I'll add more to this. Even with RFC7110 or this draft, there is no way to
know the support for these new reply modes, when looking from the source
node. So, if the request is received with this new reply mode, (depending
on implementation) the request may get dropped?

%sam - For RFC4379bis? In RFC4379 sec 4.5, it says "If the reply is sent
over an LSP, the

   topmost label MUST in this case be the Router Alert label (1) (see
   [LABEL-STACK <http://tools.ietf.org/html/rfc4379#ref-LABEL-STACK>]).".


>
>
> General comments:
>
>
>
> - I believe this new enhancement will only provide a degree of variance to
> RFC4379, where the response could be received back at initiator. Here is why
>
> 1. If the response is not received back at source, even with the new TLV,
> one cannot conclude that LSP is broken.
>
>
>
> [NOBO] It depends on how you look at this. With this new TLV, it is
> difficult to figure out if lack of response is due to something broken or
> responder didn't have the return path specified. With this new TLV, list of
> return paths are provided. Thus lack of response means either something is
> broken or none of the return paths specified were available at responder ...
> which, if return path list contained everything, then it can only mean
> something is broken.
>
%sam - the assumption you are making here is, the responding node is broken
locally. If the reply path in the middle is broken, this will solution not
help either, because responding node picks the top reply mode and sends it.
It doesn't know to pick #2 or later in the list, because #1 response mode
didn't make it to source.
Is the scope limited to the ability of responding node to reply, hence
providing multiple reply mode options?

Thanks again
-sam

>
>
>
>
>
>
>