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

[Sam Aldrin <[e-mail]>]

Hi Nobo et al,

Please find my initial comments of the draft v01.

- non-corouted -> associated
- 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?
- 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.

I do not subscribe to the text above as is. Even with the new proposal, the compute/guess/default still remain, irrespective of presence/absence of this new TLV. All you might be adding is an option for sender to group different return codes, instead of initiator to send request individually (of course little more than I summarized, but hope you got my point)

- 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.

- Missing details on how it will work within proxy LSP ping.

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. 
  2. Bidirectional LSP’s exist only for few FEC types. Hence this will be limited to those FEC types. 
  3. To solve one thing, we might be loosing other aspects. For example, when I chose return codes in this order, a. Return LSP(5); b. IP(2). So, if return LSP is broken, with RFC4379 & RFC7110, response will not be received. But with this, if IP path exists, response will be received and you do not know how the response is received and initiator will not know the response is sent over IP. Breakage of return LSP will not be know at the initiator.
  4. As least common denominator is still RFC4379, to support backward capability, it is impossible to safely assume the network is fully supportive of the new capability. Do we need controller for that? </jk>. At the end of the day, this is optimization for the sender to reduce number of requests. 

cheers
-sam

On Dec 16, 2013, at 6:28 PM, Nobo Akiya (nobo) <[e-mail]> wrote:

> Hi Sam, Curtis, Greg,
> 
> Thank you for your comments at IETF88, in particular about:
> 
> - Transition plan
> - Deviating operational preference in Reply Mode order
> - Error cases for "Reply Mode Order TLV"
> 
> These points have been updated in -01.
> 
> In summary, we have decided to remove " Reply via pre-defined preference" Reply Mode, and to allow the "Reply Mode Order TLV" to be used with any Reply Mode value in echo request.
> 
> URL:             http://www.ietf.org/internet-drafts/draft-akiya-mpls-lsp-ping-reply-mode-simple-01.txt
> Status:          http://datatracker.ietf.org/doc/draft-akiya-mpls-lsp-ping-reply-mode-simple
> Htmlized:        http://tools.ietf.org/html/draft-akiya-mpls-lsp-ping-reply-mode-simple-01
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-akiya-mpls-lsp-ping-reply-mode-simple-01
> 
> -Nobo