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

["Nobo Akiya (nobo)" <[e-mail]>]

Hi Sam,

Yes, thank you for comments.
Please find response with [NOBO] in-line.

From: Mach Chen [mailto:[e-mail]]
Sent: Friday, February 07, 2014 4:54 AM
To: Sam Aldrin; Nobo Akiya (nobo)
Cc: [e-mail]; [e-mail]; Curtis Villamizar
Subject: RE: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping-reply-mode-simple

Hi Sam,

Thanks for your comments, the authors (some still on their vacation) will discuss and address your comments later.

Best regards,
Mach

From: mpls [mailto:[e-mail]] On Behalf Of Sam Aldrin
Sent: Friday, February 07, 2014 4:24 AM
To: Nobo Akiya (nobo)
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Curtis Villamizar
Subject: Re: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping-reply-mode-simple

Hi Nobo et al,

Please find my initial comments of the draft v01.

- non-corouted -> associated

[NOBO] Ok. I have modified: s/non-co-routed/associated (i.e. LSPs in the two directions are not co-routed)/

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

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

[NOBO] Unfortunately, I don't lol. With this TLV, implementations no longer have to keep the logic to compute/guess available return path(s). A set of return path(s) can always be used, irrespective of LSP type or operational type. Looking at the comments below, I think one aspect which you may have missed is the fact the sender of MPLS echo reply will set "Reply Mode" field to the one which was used (from the list in TLV). Thus list can always be provided in MPLS echo request, and initiator can deterministically conclude, from "Reply Mode" field in MPLS echo reply, which return path responder chose.

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

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

[NOBO] It will work as is, thus I didn't see a need to clarify this. But ok, I will add some texts to clarify this.

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.

2. Bidirectional LSP's exist only for few FEC types. Hence this will be limited to those FEC types.

[NOBO] Not necessary. Reverse LSP Reply Mode can be used for any FEC types in the Reply Mode Order TLV. For those FEC types which do not have reverse LSP, reverse LSP reply mode will just get ignored. This is why I think this draft will simplify things. An implementation can allow Reply Mode preferences to be configured. An implementation can then use that list for all FEC types for all operational types ... no more "is this return path available" computation.

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.

[NOBO] As indicated above, initiator will know which Reply Mode was used from the list by responder, by looking at Reply Mode field in MPLS echo reply.

  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.

[NOBO] LOL. This is backwards compatible. Reply Mode Order TLV is an optional TLV. MPLS echo request can still set Reply Mode value to a certain value (and also carry Reply Mode Order TLV), which Reply Mode value can be used by responder node which do not understand Reply Mode Order TLV.

-Nobo

cheers
-sam

On Dec 16, 2013, at 6:28 PM, Nobo Akiya (nobo) <[e-mail]<mailto:[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