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

Hi Nobo,

Thanks for the reply. Inline for my comments.

On Nov 7, 2013, at 11:12 AM, Nobo Akiya (nobo) <nobo@cisco.com> wrote:

> Hi Sam,
> 
> Thanks for comments. Please see inline.
> 
>> - Why do you need a new reply mode 6, when reply mode 4 and 5 (via
>> another draft) are already present? If you think reply mode 5 doesn't suffice
>> the need to support reverse LSP, then the
>> <http://datatracker.ietf.org/doc/draft-ietf-mpls-return-path-specified-lsp-
>> ping/?include_text=1> should be fixed rather than introduce another mode.
> 
> Reply mode 4 and 5 has its own use, but those are not always available at responder nodes.
> Whether responder node (transit-LSR, or LSR not part of the LSP) has control-channel or reverse LSP is conditional. Instead of MPLS echo request being dropped at those responder nodes which do not have return path indicated by received Reply Mode, it's better for initiator to obtain the error, as it's a diagnostic tool. 
%sam - Think I am missing something here. Could you provide details on the scenarios why reply mode 6 will work where reply mode 5 cannot work. If you can can clarify that, it would be clear. 
Having said that, if there is really something missing by reply mode 5, but is being solved by reply mode 6, I would rather have it fixed in reply mode 5 itself, before it is published as RFC.
> 
>> - As others pointed out, IP is the best option available for all FEC types,
>> albeit TP LSP.
> 
> There are two points.
> 1. "albeit TP LSP" is exactly one of the reasons.
> 2. IP path is indeed available in most cases, but I've also heard from some that reply on control-channel/reverse-LSP is preferred over IP path in order to a) preserve disjointness in networks, and b) deterministic reverse direction.
%sam - I am not debating on why reverse path LSP is required or not. Rather, I want to know why mode 5 is not solving it. 
> 
>> - Regarding the order of preference, my opinion is, the source should select
>> the preference of the reply mode. The existing reply modes does exactly
>> that. Receiver should not chose different reply mode to what was sent by
>> source. Agree with draft on that aspect and neither does the existing
>> RFC4379 does differently.
>> - Regarding multiple reply options and preference within a single request, I
>> see it as more of optimization solution for the OAM workflow. The cost
>> incurred to support the new type is too high and do not support adding one
>> more mode. Would like to keep it simple as it is, without these new
>> changes required on the network device, while it could be achieved by the
>> application/user without any change.
> 
> As much as I appreciate your comments, I disagree. Primary because words from operators [2 from above], I believe, are valid. And if that's the case, using control-channel, reverse-LSP or return path TLV simply won't work in all cases.
%sam - The same case was made for return path ping too, if I remember correctly. So, my disagreement is not about the need, but why mode 5 is not solving it. But My point above is related to mode 7 TLV. Do you disagree that it is not optimization, assuming you have return modes 1-6?

cheers
-sam
> 
> -Nobo
> 
>> -----Original Message-----
>> From: Sam Aldrin [mailto:aldrin.ietf@gmail.com]
>> Sent: Thursday, November 07, 2013 1:40 PM
>> To: Nobo Akiya (nobo)
>> Cc: mpls@ietf.org; draft-akiya-mpls-lsp-ping-reply-mode-
>> simple@tools.ietf.org
>> Subject: Re: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping-
>> reply-mode-simple
>> 
>> Hi Nobo and authors,
>> 
>> I have few comments about this draft, which I raised in the meeting as well.
>> 
>> - Why do you need a new reply mode 6, when reply mode 4 and 5 (via
>> another draft) are already present? If you think reply mode 5 doesn't suffice
>> the need to support reverse LSP, then the
>> <http://datatracker.ietf.org/doc/draft-ietf-mpls-return-path-specified-lsp-
>> ping/?include_text=1> should be fixed rather than introduce another mode.
>> - As others pointed out, IP is the best option available for all FEC types,
>> albeit TP LSP.
>> - Regarding the order of preference, my opinion is, the source should select
>> the preference of the reply mode. The existing reply modes does exactly
>> that. Receiver should not chose different reply mode to what was sent by
>> source. Agree with draft on that aspect and neither does the existing
>> RFC4379 does differently.
>> - Regarding multiple reply options and preference within a single request, I
>> see it as more of optimization solution for the OAM workflow. The cost
>> incurred to support the new type is too high and do not support adding one
>> more mode. Would like to keep it simple as it is, without these new
>> changes required on the network device, while it could be achieved by the
>> application/user without any change.
>> 
>> Draft specific comment (though I do not prefer multiple return types in the
>> first place :D)
>> - Sec 3.3 point #5 , is incorrect. TLV should allow this. Reason is, if the first
>> preferred return mode could not be supported, one could use  reply mode 1
>> as next preference, where it will not reply.
>> 
>> cheers
>> -sam
>> On Nov 7, 2013, at 12:02 AM, Nobo Akiya (nobo) <nobo@cisco.com> wrote:
>> 
>>> Hi MPLS WG Members,
>>> 
>>> First of all, thanks for many comments during WG session on Tuesday.
>>> 
>>> A. For new TLV processing by responder, we will review for further error
>> conditions and introduce new error code if we see the need.
>>> 
>>> B. For pre-defined preference Reply Mode:
>>> 
>>> Current proposed order:
>>> 1. control-channel
>>> 2. reverse-lsp
>>> 3. IP path
>>> 
>>> That was what author felt as a reasonable order based on input from some,
>> at the time of writing the draft. However, we would like to seek for further
>> input from others in the WG, particularly from operators. Thanks!
>>> 
>>> -Nobo
>>> 
>>> _______________________________________________
>>> mpls mailing list
>>> mpls@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mpls
> 