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

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 7 Nov 2013 08:02:37 +0000

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

---

From: Loa Andersson <[email-masked]>
Date: Thu, 07 Nov 2013 09:21:36 -0800

Folks,

<chair hat off>

On 2013-11-07 00:02, Nobo Akiya (nobo) wrote:

<snip>

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

I can understand why we came up with with this order of preference;
I can also understand the logic behind what Curtis said "If the IP path
is there, use that! It will always work"

However thinking about it I'm more and more convinced that the order
of preference need to established not as something that is once and
for all fixed by the standard. I think that the operator would benefit
from be able to decide the order of preference at configuration
time.

/Loa

</chair hat off>

>
> -Nobo
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 7 Nov 2013 10:40:18 -0800

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

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 7 Nov 2013 19:12:22 +0000

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. 

> - As others pointed out, IP is the best option available for all FEC types,

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.

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

-Nobo

> -----Original Message-----
> From: Sam Aldrin [mailto:[email-masked]]
> Sent: Thursday, November 07, 2013 1:40 PM
> To: Nobo Akiya (nobo)
> Cc: [email-masked]; draft-akiya-mpls-lsp-ping-reply-mode-
> [email-masked]
> Subject: Re: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping-
> reply-mode-simple
> 
> Hi Nobo and authors,
> 
> - 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.
> - 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.
> 
> - 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
> > A. For new TLV processing by responder, we will review for further error
> conditions and introduce new error code if we see the need.
> >
> > 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
> >

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 7 Nov 2013 11:31:45 -0800

Hi Nobo,

Thanks for the reply. Inline for my comments.

On Nov 7, 2013, at 11:12 AM, Nobo Akiya (nobo) <[email-masked]> wrote:

> 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.
> 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…
%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. 
> 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 pa…
%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

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 7 Nov 2013 19:38:10 +0000

Hi Loa,

Thanks for comments.

> "If the IP path is there, use that! It will always work"

Yes, that's a good comment from Curtis. There's one thing that I'd like to point out.

Multisegment-Pseudowire over TP was a scenario where I was scratching my head few months ago. Initiating TP segment could have IP routes (TP in IP based domain), but next TP segment may not have IP routes (IP in IP-less domain). So the "If the IP path is there ..." is something which initiator does not always have knowledge of. In this case, using Reply Mode of IP can cause responder to drop the request. Same problem as using Reply Mode 4/5 but not having paths corresponding to Reply Mode 4/5 at responder.

The question is whether standard should have pre-defined preference or not, I'd like to wait for more comments.

Thanks,
Nobo

> From: Loa Andersson [mailto:[email-masked]]
> Sent: Thursday, November 07, 2013 12:22 PM
> To: Nobo Akiya (nobo); [email-masked]
> Cc: [email-masked]
> However, we would like to seek for further input from others in the WG,
> particularly from operators. Thanks!
> 
> I can understand why we came up with with this order of preference; I can
> also understand the logic behind what Curtis said "If the IP path is there, use
> that! It will always work"
> 
> However thinking about it I'm more and more convinced that the order of
> preference need to established not as something that is once and for all
> fixed by the standard. I think that the operator would benefit from be able
> to decide the order of preference at configuration time.
> 
> /Loa
> 
> </chair hat off>
> 
> >
> > -Nobo
> >

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 7 Nov 2013 21:38:38 +0000

Hi Sam,

/pong :)

Please see inline.

> Sent: Thursday, November 07, 2013 2:32 PM
> To: Nobo Akiya (nobo)
> >> 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-specifie
> >> d-lsp- ping/?include_text=1> should be fixed rather than introduce
> >> another mode.
> >
> > 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.

[NOBO] One example. Doing a traceroute on an associated RSVP LSP (i.e. bi-directional) that is partially co-routed, reply mode 5 will not work but 6 will. 

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

[NOBO] Considering return path TLV draft is very late in the stage (LC done already), I would bet that authors/chairs would want to progress return path TLV draft.

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

[NOBO] See above.

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

[NOBO] Similar, yes. But return path TLV draft leaves traceroute as "outside the scope", and that means problem described in this draft is not very relevant and thus not discussed/solved.

-Nobo

> >> 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-specifie
> >> d-lsp- ping/?include_text=1> should be fixed rather than introduce
> >> another mode.
> >> - 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
> >> - 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.
> >>
> >> - 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
> >> 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
> >>>