Subject: [mpls-tp] Comments on draft-nitinb-mpls-tp-on-demand-cv-00

From: Mach Chen <[email-masked]>
Date: Tue, 22 Jun 2010 11:47:43 +0800

Hi,

Some comments or questions below:

1. Reverse path Connectivity verification(Section)
It says:"For bi-directional LSPs, when the egress sends the echo response, 
the egress MAY attach the target FEC stack TLV [RFC4379] in the echo
   response.  The ingress (on receipt of the echo response) can use the FEC 
stack TLV to perform reverse path connectivity verification..."
But in RFC 4379(Section 4.5), it says "...The FEC Stack TLV from the echo 
request MAY be copied to the reply...", so based on the current LSP Ping 
specification and the existing implementations, the ingress will interpret 
the FEC Stack TLV is for the forward direction LSP.
For co-routed bidirectional LSP, since the FECs for both directions are the 
same, this is OK to re-use the FEC stack TLV for reverse path CV. But for 
associated bidirectional LSP, when the ingress received the echo reponse 
with a FEC stack TLV, how does it determine whether the FEC is of the 
forward direction or backward direction?  IMHO, it's better to use separate 
FEC stack TLV for each direction, especially for associated bi-dir LSP.

2. MPLS-TP LSP trace
It seems that the current draft does not consider associated bi-directional 
LSP scenarios where each direction may follow diverse paths and some MIP 
nodes can not send echo reponse along the reverse lsp directly. So there may 
be need some return path specified mechanisms to help associated 
bidirectional LSP tracing.

Best regards,
Mach

---

From: Mach Chen <[email-masked]>
Date: Tue, 22 Jun 2010 14:47:40 +0800

Hi Riccardo,

Thanks for your prompt response!

I agree with the return path issue that you pointed out, and this is also my 
concern about how this problem could be handled by the draft. This issue is 
related not only to associated bidirectional LSP, but to unidirectional LSP 
and P2MP LSP that may also have no in-band return path. I personally believe 
that some mechanisms are needed to reslove the return path issue.

Best regards,
Mach

--------------------------------------------------
From: "Riccardo Martinotti" <[email-masked]>
Sent: Tuesday, June 22, 2010 12:13 PM
To: "Mach Chen" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [mpls-tp] Comments on draft-nitinb-mpls-tp-on-demand-cv-00

> Dear Mach,
> Please see inline a comment to your point 2 (I just stripped the other 
> point from the body).
>
> Regards,
> Riccardo
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Mach Chen
> Sent: martedì 22 giugno 2010 11.48
> To: [email-masked]
> Subject: [mpls-tp] Comments on draft-nitinb-mpls-tp-on-demand-cv-00
>
>
> Hi,
>
> 1. [...]
> RM> Use of MIP for on demand CV in case of associated bi-directional LSP 
> may be of less use, because in case an echo reply is not received by the 
> MEP (which sent the echo request) it is not possible to know whether the 
> problem is related to the LSP being monitored or to the return path.
>
> Best regards,
> Mach
>
>
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Nitin Bahadur <[email-masked]>
Date: Wed, 23 Jun 2010 14:34:32 -0700

Hi Mach,

> FEC stack TLV for each direction, especially for associated bi-dir LSP.

You are right that there might be some confusion. I'll look into this.
 
> bidirectional LSP tracing.

In non-error cases, I believe all MIPs should be able to send the response
back on the reverse lsp path. In error cases, a MIP might be unable to send
the response (because of the fault). In such a case, the first MIP which is
unable to send the response back is the MIP where the fault is. The spec
currently says that we must reply using application control channel. We can
make that a should, so that if one wants, one can ask that the reply be sent
via UDP....if there is another available path in the network.

Thanks
Nitin

P.S: Please cc: one of the authors always, so that it's easier to dig
through the incoming email flood.

---

From: [email-masked]
Date: Thu, 24 Jun 2010 09:29:59 +0800

Hi Nitin:
  About the question of LSP trace, I still have some confusions with your 
answer. In the draft, section 4.2.3 says "If there is an error and the 
node is unable to identify the LSP on which the echo response would to be 
sent, the node MUST drop the echo request packet and not send any response 
back." This means that response must be sent on a return LSP. But in 
associated bi-directional LSP, MIP does not have an in band return LSP. So 
it seems that LSP tracing can not directly be supported in associated 
bi-directional LSP scenarios. 
  Can you clarify it further? thanks! 

                                 xia.liang
                                Best regards

[email-masked] 写于 2010-06-24 05:34:32:

> > nodes can not send echo reponse along the reverse lsp directly. 
Sothere may
> through the incoming email flood.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Mach Chen <[email-masked]>
Date: Thu, 24 Jun 2010 16:26:46 +0800

Hi Nitin,

Thanks for your reply!

Please see inline...
--------------------------------------------------
From: "Nitin Bahadur" <[email-masked]>
Sent: Thursday, June 24, 2010 5:34 AM
To: "Mach Chen" <[email-masked]>; <[email-masked]>
Subject: Re: [mpls-tp] Comments on draft-nitinb-mpls-tp-on-demand-cv-00

> You are right that there might be some confusion. I'll look into this.

OK.

> via UDP....if there is another available path in the network.

IMHO, even if in non-error cases(for associated bidirectional LSP), the MIPs 
response may not be able to send the response, see the figure below:
A---B---C---D---E
 \             /
  F----G------H
A associated bidirectional LSP combined with two unidirectional LSPs( LSP1: 
A->B->C->D->E, and LSP2: E->H->G->F->A), when the trace request reach at B, 
how does node B send the response? there may not be direct return path from 
B to A (including IP or LSP path), the only way to send the response is 
continue to send the response along LSP1, and round back at E and then send 
along LSP2 back to A. In order to achieve this, IMHO, there need some 
information to direct node B and node E to send the response, including:
1. whether can send the response along the non-in-band path or not
2. how to send the response along the round-path; and if there exist both 
direct return path from a MIP to the ingress and round-path, how to 
determine which path should be used.

Best regards,
Mach

---

From: Nitin Bahadur <[email-masked]>
Date: Thu, 24 Jun 2010 10:56:34 -0700

Hi Mach,

   Very good example. See more below.

> IMHO, even if in non-error cases(for associated bidirectional 
> LSP), the MIPs response may not be able to send the response, 

> see the figure below:
> A->B->C->D->E, and LSP2: E->H->G->F->A), when the trace 
> request reach at 
> A->B->C->D->B,
> how does node B send the response? 

The above case is probably not how things get deployed in transport
networks (transport folks can correct me if I am wrong). Transport networks
typically have bi-directional physical paths.

In any case, there are 2 ways for B to send a response back, 
1) B sends the response back directly to A via IP or some other encapsulation.
2) B tunnels the packet to E and sends the response back.

Option 2 is not practical & insufficient, because if there is a fault at C, then the echo
response will never make it back...giving the impression that the fault is at B. 
Adding the complexity to tunnel the packet to E and then back seems too cumbersome 
and I don't see a real business case/requirement for the same.

Option 1 will not work if there is no IP/MPLS path back to A from B....but I consider that
more of a network design issue....

> there may not be direct 
> return path from B to A (including IP or LSP path), the only 
> way to send the response is continue to send the response 
> along LSP1, and round back at E and then send along LSP2 back 
> to A. In order to achieve this, IMHO, there need some 
> 1. whether can send the response along the non-in-band path 
> or not 2. how to send the response along the round-path; and 
> if there exist both direct return path from a MIP to the 
> ingress and round-path, how to determine which path should be used.

Thanks
nitin

---

From: Nitin Bahadur <[email-masked]>
Date: Thu, 24 Jun 2010 17:22:09 -0700

Hi, Xia,

        Let me clarify what I meant. Consider

  A ----> B ----> C ---> D
   <-----    <----     <---

   Node B is a MIP. Node B does not have a direct LSP from B to A.....since it's a MIP. By the text in the draft, I meant
that node B should be able to identify that there is a LSP in the reverse direction (going to A via it) and should send
the echo response on that LSP. If there is no such LSP (going to A) for which node B is the transit, then node B should
just drop the packet.

Hope that helps
Nitin

 Hi Nitin:
  About the question of LSP trace, I still have some confusions with your answer. In the draft, section 4.2.3 says "If there is an error and the node is unable to identify the LSP on which the echo response would to be sent, the node MUST drop the echo request packet and not send any response back." This means that response must be sent on a return LSP. But in associated bi-directional LSP, MIP does not have an in band return LSP. So it seems that LSP tracing can not directly be supported in associated bi-directional LSP scenarios.
  Can you clarify it further? thanks!

                                 xia.liang
                                Best regards

[email-masked] 写于 2010-06-24 05:34:32:

> > nodes can not send echo reponse along the reverse lsp directly. Sothere may

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 24 Jun 2010 22:21:41 -0400

Dear Mach and All,
you've said "the only way to send the response is continue to send the
response along LSP1, and round back at E and then send along LSP2 back to A.
In order to achieve this, IMHO, there need some information to direct node B
and node E to send the response, including:
1. whether can send the response along the non-in-band path or not
2. how to send the response along the round-path; and if there exist both
direct return path from a MIP to the ingress and round-path, how to
determine which path should be used."
In my understanding that requires that MIPs of associated bi-directional LSP
must be aware of relationship and pairing between forward and reverse
directions of the LSP. As I recall such understanding is only "MAY". I don't
see problem that some troubleshooting mechanism would not be able to work in
MPLS-TP network if there is no functional DCN.

Regards,
Greg

On Thu, Jun 24, 2010 at 4:26 AM, Mach Chen <[email-masked]> wrote:

> IMHO, even if in non-error cases(for associated bidirectional LSP), the
> MIPs response may not be able to send the response, see the figure below:
> A---B---C---D---E
> \             /
>  F----G------H

---

From: [email-masked]
Date: Fri, 25 Jun 2010 10:59:20 +0800

Nitin
I don't agree your opinions, according to your thinking. if there is no 
reverse path from B to A , B would 
not response to the request from A . or else, B would response to the 
request through existing reverse path 
from B to A .
IMO, for node A , how to know of whether to have a path from B to A ?
even if node A know there is a path from B to A , when the path have the 
failure.
do node B generate response packet to A? 
in additon, for node A ,if it can't receive the response packet from B , 
how to identify the error is in the path from A to B or not?

it will be confusion and diffcult to detect and localize the failure in 
the path.

best regards
liu

Nitin Bahadur <[email-masked]> 
发件人:  [email-masked]
2010-06-25 08:22

收件人
"[email-masked]'" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
Re: [mpls-tp] Comments on draft-nitinb-mpls-tp-on-demand-cv-00

Hi, Xia,

  A ----> B ----> C ---> D
   <-----    <----     <---
 
   Node B is a MIP. Node B does not have a direct LSP from B to 
A.....since it's a MIP. By the text in the draft, I meant
that node B should be able to identify that there is a LSP in the reverse 
direction (going to A via it) and should send
the echo response on that LSP. If there is no such LSP (going to A) for 
which node B is the transit, then node B should
just drop the packet.
 
Hope that helps
Nitin

 Hi Nitin: 

                                 xia.liang 
                                Best regards 

Sothere may

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Mach Chen <[email-masked]>
Date: Fri, 25 Jun 2010 11:59:06 +0800

Hi Nitin,

Thanks for your reply!

See my reply inline...
--------------------------------------------------
From: "Nitin Bahadur" <[email-masked]>
Sent: Friday, June 25, 2010 1:56 AM
To: "'Mach Chen'" <[email-masked]>; <[email-masked]>
Subject: RE: [mpls-tp] Comments on draft-nitinb-mpls-tp-on-demand-cv-00

> typically have bi-directional physical paths.

IMHO, it's better for transport network to have bi-directioanl phyical 
paths, but it could not exclude the situation where the two directions are 
diverse(at least partially diverse), and this is one of the reasons that 
associated bidrectional LSP required in MPLS-TP.

> more of a network design issue....

I basically agree with you analyse, so for associated bidirectional LSP, the 
operation is almost the same unidirectional LSP.

One more question: does the tracing result of an associated bidirectional 
LSP inlcude the reverse path, or just one direction? if incluing reverse 
direction, how to process and present the result?

Best regards,
Mach

---

From: Mach Chen <[email-masked]>
Date: Fri, 25 Jun 2010 12:06:44 +0800

Hi Greg,

Thanks for your reply!

If we could restrict the application scenarios of associated bidirectional 
in MPLS-TP network, I agree with you! And IMHO, it's better to clarify this 
somewhere.

Best regards,
Mach

--------------------------------------------------
From: "Greg Mirsky" <[email-masked]>
Sent: Friday, June 25, 2010 10:21 AM
To: "Mach Chen" <[email-masked]>
Cc: "Nitin Bahadur" <[email-masked]>; <[email-masked]>
Subject: Re: [mpls-tp] Comments on draft-nitinb-mpls-tp-on-demand-cv-00

>>>> nodes can not send echo reponse along the reverse lsp directly. So 
>>>> there
>>>> may

---

From: [email-masked]
Date: Fri, 25 Jun 2010 13:30:47 +0800

Hi Greg and Mach

Although associated bidrectional LSP is defined in MPLS-TP network, there 
is no reason it can not be used by traditional MPLS networks. In order to 
do this, it just need to send Path refresh message carring the Association 
object, and the procedure is descirbed in 
draft-zhang-mpls-tp-rsvpte-ext-associated-lsp. Furthermore, Other possible 
solutions, like as GMPLS Calls and LSP_TUNNEL_INTERFACE_ID object have 
been mentioned in draft-ietf-ccamp-mpls-tp-cp-framework.

Requirements said the transit node SHOULD be aware the relationship, and 
it can be done by the methods mentioned above. 

So in my opinion, the scheme described by Mach is workable, but the 
operation is a little complicated....

B.R.

Fei

Mach Chen <[email-masked]> 
发件人:  [email-masked]
2010-06-25 12:06

收件人
Greg Mirsky <[email-masked]>
抄送
[email-masked]
主题
Re: [mpls-tp] Comments on draft-nitinb-mpls-tp-on-demand-cv-00

Hi Greg,

Thanks for your reply!

in MPLS-TP network, I agree with you! And IMHO, it's better to clarify 
this 
somewhere.

Best regards,
Mach

> response along LSP1, and round back at E and then send along LSP2 back 
to 
> A.
> In order to achieve this, IMHO, there need some information to direct 
node 
> B
> In my understanding that requires that MIPs of associated bi-directional 

> LSP
> see problem that some troubleshooting mechanism would not be able to 
work 
> in
>>>>   response.  The ingress (on receipt of the echo response) can use 
the
>>>> FEC
>>>> For co-routed bidirectional LSP, since the FECs for both directions 
are
>>>> the
>>>> same, this is OK to re-use the FEC stack TLV for reverse path CV. But 

>>>> for
>>> the response (because of the fault). In such a case, the first MIP 
which
>>> is
>>> currently says that we must reply using application control channel. 
We
>>> can
>>> make that a should, so that if one wants, one can ask that the reply 
be
>>> sent
>> A->B->C->D->E, and LSP2: E->H->G->F->A), when the trace request reach 
at 
>> B,

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 26 Jun 2010 16:13:49 -0400

Dear Mach,
I have to correct my previous assumption. Per #12 of RFC 5654 transit nodes
of bi-directional associated LSP SHOULD be aware of forward and backward
direction relationship.

Regards,
Greg

---

From: Nitin Bahadur <[email-masked]>
Date: Wed, 30 Jun 2010 17:30:30 -0700

> One more question: does the tracing result of an associated 
> bidirectional LSP inlcude the reverse path, or just one 
> direction? if incluing reverse direction, how to process and 
> present the result?

It currently includes only 1 direction.

Thanks
Nitin