Subject: Re: [mpls] Comments for draft-chen-mpls-return-path-specified-lsp-ping-01

From: Nitin Bahadur <[email-masked]>
Date: Wed, 10 Feb 2010 12:02:23 -0800

Hi Mach,   

    Please see inline below for comments.

>	 There are two issues that our draft tries to resolve:
>	1. Current LSP Ping mechanisms are lack of the capability of specifying the return path 
> 	   of an echo reply, hence some time it may bring difficuties in faults localization. 

	NB> This is only a problem for uni-directional LSPs. Also, the problem only exists
if the LSP forward path is UP and the reverse IP path is down. If the forward LSP path
is DOWN, then lsp traceroute should help in fault localization. See my comments below for 
bi-directional LSPs.

>	2. A bidirectional path checking needs at least two LSP pings(inefficient), and sometime
>      difficut even fail to check the reverse direction of a bidirectional path. 

	NB> You don't need 2 LSP-Pings. For bidirectional co-routed LSPs, the egress SHOULD 
      send the packet over the LSP itself.

	For bidirectional associated LSP, the egress again SHOULD send the packet over the 
      associated LSP itself. See Section 3.1 of draft-nitinb-mpls-tp-lsp-ping-extensions-00.
      Even if the specifications in the draft above are not used, I presume there will *some*
      way that one will specify the LSP "association". One could use that way to ensure that
      lsp-ping responses always use that association. So additional protocol machinery is not
      needed.

	For uni-directional LSPs, yes you will need 2 lsp-pings. But the LSP is uni-directional.....
      so you are testing only the forward direction.....
      there is no concept of reverse direction for uni-directional LSPs.

Other comments
--------------
The draft talks about specifying ways in which ingress could specify how the
egress should respond. I fail to see how operators will use this *ability* in
the field. How does the operator know which LSP should be used for return-path?
If the operator knows this via config, then the same config could be added at
LSP egress as well. 

If the operator is just going to loop through (in return-path tlv) all the egress 
initated LSPs hoping for at least 1 successful response, then the scheme is broken.
One should use BFD (or some other mechanism) to ensure that both ingress initiated
and egress initiated (uni-directional) LSPs are UP. If a LSP is UP, then the egress
can respond back via any UP LSP and the echo response will reach the ingress...since the
LSP is UP. If you want to ensure that the echo response comes back via a LSP (and not IP), 
then I guess you could add a code-point that says "reply via lsp" or something like that.

>From a practical operator persecptive, I need to understand more on how someone would
use the feature/flexibility that you are proposing.

Thanks
Nitin

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 10 Feb 2010 18:17:25 -0800

Dear Nitin,
the LSP Ping might not be the only option but I believe that there must be a
Control Plane mechanism to direct return path of BFD session (egress to
ingress) of unidirectional LSP onto specified path (IP routed, LSP or else).
There certainly could be local policy that will select such return path but
that does not preclude from driving selection from headend or NMS. Would LSP
Ping be the only such mechanism? Considering work on MPLS-TP OAM I'd expect
to see appropriate extensions being proposed for RSVP-TE some time soon.
(There's already proposal to bootstrap BFD session via RSVP-TE)

Regards,
Greg

On Wed, Feb 10, 2010 at 12:02 PM, Nitin Bahadur <[email-masked]> wrote:

>      associated LSP itself. See Section 3.1 of
> draft-nitinb-mpls-tp-lsp-ping-extensions-00.
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Nitin Bahadur <[email-masked]>
Date: Wed, 10 Feb 2010 22:11:36 -0800

Hi Greg,

   It doesn’t matter what the OAM protocol is...it could be LSP-Ping or something else....and I agree with you on that.

   I also agree that there should be a control plane mechanism. Currently the drafts/RFC specify 2 mechanisms that apply to
MPLS-TP LSPs – Reply via IP/UDP and Reply via control channel (ACH).

   In context of MPLS-TP, we are talking mainly about bidirectional co-routed and associated LSPs. And the above 2 techniques apply
well to both of them. In fact for co-routed and associated LSPs, we should NOT be specifying a return path and instead ensure/validate that
the echo response is received on the correct reverse path (if ACH is used). Not explicitly specifying the path and validation will ensure that both
ingress and egress have the same idea of the forward and reverse path. In short, I do not see the use of this extension for MPLS-TP LSPs.

   For regular uni-directional LSPs, my main question is what is the operator going to gain by specifying the
return path policy on the ingress (via signaling or NMS). This policy should be on the egress (rather than ingress).  For uni-directional
LSPs if you put the policy on the ingress, then you are adding state (on the ingress) regarding which LSPs exist on the egress.

   I might be missing the real intention and am definitely open to understanding the problem statement in more detail.

Thanks
Nitin

On 2/10/10 6:17 PM, "Greg Mirsky" <[email-masked]> wrote:

Dear Nitin,
the LSP Ping might not be the only option but I believe that there must be a Control Plane mechanism to direct return path of BFD session (egress to ingress) of unidirectional LSP onto specified path (IP routed, LSP or else). There certainly could be local policy that will select such return path but that does not preclude from driving selection from headend or NMS. Would LSP Ping be the only such mechanism? Considering work on MPLS-TP OAM I'd expect to see appropriate extensions being proposed for RSVP-TE some time soon. (There's already proposal to bootstrap BFD session via RSVP-TE)

Regards,
Greg

Other comments
--------------

Thanks
Nitin

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 10 Feb 2010 22:46:20 -0800

Hi Nitin,

> return path policy on the ingress (via signaling or NMS). This policy
> should be on the egress (rather than ingress).  For uni-directional
> LSPs if you put the policy on the ingress, then you are adding state (on
> the ingress) regarding which LSPs exist on the egress.
>
>
>
Dont we generally want the ingress to specify policy because that is where
the OAM initiated?

Thanks,
Vishwas

> the LSP Ping might not be the only option but I believe that there must be
> a Control Plane mechanism to direct return path of BFD session (egress to

---

From: Nitin Bahadur <[email-masked]>
Date: Wed, 10 Feb 2010 23:43:01 -0800

There is a subtle difference. OAM is initiated in the direction of the LSP...which is setup by the ingress.
OAM response is sent by the egress in the reverse direction....so the policy should be on the egress.

Deploying ingress based policy can be a nightmare. Suppose you have a LSP (called lsp-1) from San Francisco to New York.
And suppose you have a LSP (called lsp-2) from NY to SF. You could (in  theory) instruct in the OAM msg that NY should
use lsp-2 for reverse path. Now if the operator in NY wants to rename lsp-2 to lsp-from-ny-to-sf, then the
operator has to make a change even in the router in San Francisco. Isn’t this a deployment hassle? You can say that NMS
will take care of it....but even the NMS has to be programmed with this dependency.....maintenance has to be scheduled
In both NY and SF.

Instead if the policy was only in NY (say – for all OAMs coming on any LSP from SF,  reply using lsp-2), then the operator could easily
change the lsp name and the policy, without scheduling potential down-time/maintenance time in SF. If the operator wanted to bring
down the LSP in NY, then he could do that and get rid of the policy in NY....instead of having to go to SF and change the policy there.

Again, above applies only to uni-directional LSPs.

Nitin

On 2/10/10 10:46 PM, "Vishwas Manral" <[email-masked]> wrote:

Hi Nitin,

Dont we generally want the ingress to specify policy because that is where the OAM initiated?

Thanks,
Vishwas

Dear Nitin,

Regards,
Greg

Other comments
--------------

Thanks
Nitin

---

From: Mach Chen <[email-masked]>
Date: Thu, 11 Feb 2010 17:32:30 +0800

Hi Nitin

Thanks for your comments!

Please see my reply inline...
--------------------------------------------------
From: "Nitin Bahadur" <[email-masked]>
Sent: Thursday, February 11, 2010 4:02 AM
To: "'MachChen 55527'" <[email-masked]>; "'George Swallow'" 
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Subject: RE: Comments for draft-chen-mpls-return-path-specified-lsp-ping-01

> is DOWN, then lsp traceroute should help in fault localization.

There are several conditions that may lead to problems, not just only the 
reverse IP path is down. The return path of the echo reply could be either 
IP or LSP path that depends on the local routing policy.

And the LSP traceroute may not help in fault localization sometimes, take a 
simple topology(A--B--C--D) for example, there is an LSP from A to D and 
maybe an LSP from D to A, no matter what the failure is at the hop between C 
and D or at the reverse path or at D, there will no different in the trace 
result(A..B..C). That means the operator can not yet determine whether the 
forward LSP is with failure.

> See my comments below for bi-directional LSPs.
>

Since the echo reply will not carry the FEC stack information of the reverse 
direction, one LSP-Ping could only complete cv checking of the forward 
direction of the LSP. In order to do cv checking of the reverse direction, 
another LSP-Ping is necessary. With this RPS(Return Path Specified) 
extension, it's really that only one LSP-Ping is enough. And for 
inter-AS/inter-domain LSP, the operators of one side may have no right to 
log on to the remote side to perfom any actions, hence make it impossiable 
to check the reserve direction without the help of the operators of the 
other domain/AS.  With this RPS extension, a single LSP-Ping could finish 
both directions checking.

BTW, for co-routed bidirectional LSP, even if the egress will send packets 
over the LSP itself, but when failures occur, the operators still need to 
further locate which direction is failed. So, changing the return path is an 
alternate method.

> protocol machinery is not

For associated LSP, it has the same issues/requirements as co-routed LSP as 
said above.

>      there is no concept of reverse direction for uni-directional LSPs.

For the operators, they use unidirectional LSPs to provide bidirectional 
service, most of the time, they just see there is a bidirectional path. If 
there is light/easier way to perform bidirectional path checking within a 
single operation, I think it should be good.

> Other comments

The operators could based on their experence and the on-site conditions to 
choose the specific LSP for return-path.

> initated LSPs hoping for at least 1 successful response, then the scheme 

Loop through all the egress initated LSPs is the worsest situation, and for 
most of the time, there will not be too many LSPs. For me this is 
reasonable. Why do you think the scheme is broken?

> and egress initiated (uni-directional) LSPs are UP. If a LSP is UP, then 

IMO, it's not possible to provision BFD session for every LSP and route, 
it's not scale. And if it is only for selection a proper return path to send 
the echo reply, IMHO, provision too many BFD sessions is not cost-effective.

> then I guess you could add a code-point that says "reply via lsp" or 

Force the echo reply to be sent along pure lsp path sounds reasonable, it 
could be an option.

BTW, from my understanding, normally, the echo reply is always trying to 
follow lsp(it have higher priority the IP path). So, in the RPS draft, we 
define a mechanism to force the echo reply follow pure IP path(at least the 
egress uses IP path), hence to verify whether the LSP path is OK.

> use the feature/flexibility that you are proposing.

In short, with our RPS extensions, it has the following benifits:
1. Enable to change/exclude the return paths freely, improve the robustness 
of LSP Ping;
2. Return path could be force to along IP-only path;
3. Improve the efficient for bidirectional path checking;
4. Enable to check a bidirectional inter-domain/AS path;
5. Could be used for enhancing "BFD for MPLS" bootstrap signaling: enable to 
provision a single(not two) BFD session for a bidirectional LSP. More 
specific information could be found at: 
http://tools.ietf.org/html/draft-chen-mpls-bfd-enhancement-00.

Any comments and suggestions are welcomed!

Best regards,
Mach

> Nitin=

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 11 Feb 2010 14:41:58 -0800

Dear Nitin,
I agree on your perspective regarding co-routed bi-directional LSP. As it
was intentionally built with fate sharing between ingress/egress directions
I don't see why operator will need to specify return path other than
opposite direction of LSP under examination.
Troubleshooting bi-directional associated connection might have different
requirements. (Wish we have someone from operators community to speak here).
As directions, in general case, are diversly routed, so I see value in
specifying return path. It is logical to name opposite direction of
associated connection as default return path but explicit, one-time
overwrite seems to have value.
And now we get to unidirectional LSP. Since such construct exists and is
listed in MPLS-TP I consider tools to troubleshoot them be of value. If one
applies bi-directional p2p BFD (aka "classical") to unidirectional LSP then
the question of return path comes up sooner than later. What might be
interesting to explore, I think, is whether BFD Multipoint model can be
applied to unidirectional LSP (unidirectional LSP as special case of
unidirectional p2mp).

Regards,
Greg

On Wed, Feb 10, 2010 at 10:11 PM, Nitin Bahadur <[email-masked]> wrote:

> Hi Greg,
>
>   It doesn’t matter what the OAM protocol is...it could be LSP-Ping or
> something else....and I agree with you on that.
>
>   I also agree that there should be a control plane mechanism. Currently
> the drafts/RFC specify 2 mechanisms that apply to
>   In context of MPLS-TP, we are talking mainly about bidirectional
> co-routed and associated LSPs. And the above 2 techniques apply
> well to both of them. In fact for co-routed and associated LSPs, we should
> NOT be specifying a return path and instead ensure/validate that
> the echo response is received on the correct reverse path (if ACH is used).
> Not explicitly specifying the path and validation will ensure that both
> ingress and egress have the same idea of the forward and reverse path. In
> short, I do not see the use of this extension for MPLS-TP LSPs.
>
>   I might be missing the real intention and am definitely open to
> understanding the problem statement in more detail.
>
> Thanks
> Nitin
>
>

---

From: Mach Chen <[email-masked]>
Date: Fri, 12 Feb 2010 10:41:38 +0800

Hi Nitin,

--------------------------------------------------
From: "Nitin Bahadur" <[email-masked]>
Sent: Thursday, February 11, 2010 2:11 PM
To: "Greg Mirsky" <[email-masked]>
Cc: "MachChen 55527" <[email-masked]>; "George Swallow" 
<[email-masked]>; <[email-masked]>; <[email-masked]>
Subject: Re: [mpls] Comments for 
draft-chen-mpls-return-path-specified-lsp-ping-01

> the echo response is received on the correct reverse path (if ACH is 
> used). Not explicitly specifying the path and validation will ensure that 
> both

If the LSP-Ping message could be only sent along the bidirectional LSP, when 
failures occur, it's hard to differentiate which direction is 
failed(especially for associated bidirectional LSP).

> understanding the problem statement in more detail.

The orginal intention of specifying return path is for enhancing LSP-Ping in 
fault localization. Normally, LSP-Ping echo reply follows a relative stable 
path(default return path that follows the egress routing), as said in my 
previous email, failures at forward LSP, egress, reverse path will lead to 
LSP-Ping failing, and sometime, from the result of ping or trace, there is 
no difference, hence it's hard to differiate where is the failure point. By 
specifying an alternate return path of the echo reply, it could help a lot 
to judge whether the "default" return path is OK or not, hence to determine 
or eliminate the suspect of the return path.

In addition, when having this return path specified capability, it could 
help to check a bidirectional LSP or a pair of unidirectional LSPs within a 
single operation(the echo reply is extended to check the reverse lsp by 
carrying the FEC information of that LSP), hence to reduce the workload of 
the operators. This is particular useful in inter-domain/AS scenarios where 
the operators from one side of the LSP are impossible to log on the remote 
side to operate.

Best regards,
Mach
> ingress) of unidirectional LSP onto specified path (IP routed, LSP or 
> else). There certainly could be local policy that will select such return 
> path but that does not preclude from driving selection from headend or 
> NMS. Would LSP Ping be the only such mechanism? Considering work on 
> MPLS-TP OAM I'd expect to see appropriate extensions being proposed for 
> RSVP-TE some time soon. (There's already proposal to bootstrap BFD session 
> via RSVP-TE)
>
> Regards,
> Greg
>

---

From: Nitin Bahadur <[email-masked]>
Date: Fri, 12 Feb 2010 00:29:58 -0800

Hi Mach,

   I'm splitting my replies into multiple emails to address topics
separately.

> forward LSP is with failure.

Agreed that with current mechanisms you cannot figure out if a failure is
with the forward path or reverse path. That's a good problem statement to
have.

I don't agree with the solution presented. The solution presented makes the
ingress node have detailed knowledge of FECs originating at the egress and
creates an implicit binding betweens multiple return paths.

Instead maybe you can just have a new return mode called "Reply via
alternate path" in which the egress will rely using the non-default path.
If even the non-default path is broken, then you have a problem. I'm not
convinced if that problem is worth addressing....

There might be other ways to address the problem statement...my main intent
is to reduce the coupling between the ingress and egress and reduce
configuration overhead.

I see that some operators have been cc'ed on this email. So it would be good
to get their input on how much complex configuration they want to do on
their mpls boxes to effectively use oam.

Thanks
Nitin

---

From: Nitin Bahadur <[email-masked]>
Date: Fri, 12 Feb 2010 01:13:54 -0800

Hi Mach,

> direction of the LSP.

I'm not an RSVP expert, but I believe, for co-routed bi-directional LSPs,
the FEC stack for the reverse direction will be the same. So CV checking on
the reverse path involves 2 things:

1) Ensuring that received echo response is for the echo request sent
2) Ensuring that echo response is received on the reverse path of the
   bi-directional LSP.

For associated bi-directional LSPs, the ingress node already knows which
egress LSP has been associated with the ingress LSP. So the ingress node
needs to validate:
1) Received echo response is for the echo request sent
2) Echo response is received on the egress LSP.

More details are not needed IMO.

In echo request, we need the FEC stack to identify the LSP under test (to
catch a case where an OAM packet arrives at an un-intended destination).
Note that regular uni-directional LSPs use PHP and hence FEC determination
cannot be based off a label (since there will be no label received on
egress). 

In echo response, if the packet is dropped, then the receiver (ingress) will
time out. If the packet is mis-routed, then the receiver (some random node)
will drop it since it won't be expecting an echo response.

In addition, RFC 4379 specifies, "The FEC Stack TLV from the echo request
MAY be copied to the reply." This has huge implications. This means that for
bi-directional co-routed LSPs, one can copy the incoming FEC stack TLV (if
one wants to) and for bi-directional associated LSPs, once can insert a new
FEC stack TLV identifying the reverse path FEC. The ingress has information
regarding the association, so it can perform any CV validations.

> In order to do cv checking of the reverse direction,
> extension, it's really that only one LSP-Ping is enough.

See above.

> And for 

See below 
 
> single operation, I think it should be good.

Bi-directional associated LSPs will give the operators exactly that. They
just need to add that association.

> choose the specific LSP for return-path.

Experience and on-site conditions => complicated NMS systems and more
maintenance windows. OAM should be simple and stupid...otherwise it will not
be deployable.

> reasonable. Why do you think the scheme is broken?

It's broken because now the ingress needs to know about all the "egress
initiated LSPs". It's too much coupling. As I said in my other email, all
you need is an alternate way of sending the response. Multiple alternate
ways will not provide you with too much benefit. The cost vs benefit
equation doesn't favor multiple alternate paths.

> it's not scale. 

I happily disagree with that statement. I know more than 1 vendor that has
simplified BFD provisioning for LSPs and routes.

Scaling yes, every system will have scaling limits. Some boxes will do
better than others.

If you don't provision BFD for every LSP, then you won't know if a
particular LSP is down and you might black-hole traffic. If you round-robin
packets of 1 bfd session between multiple LSPs, then you are effectively (in
forwarding plane) increasing the time interval between packets sent on a
particular LSP....which is the same as multiple BFD sessions (without
additional control plane state).

Again, as I said, it's my opinion.

> And if it is only for selection a proper return path to send

> follow lsp(it have higher priority the IP path).

That's your assumption...you can have a box that has different policies for
different things. There is nothing in the echo rely that specifies that it
must go over a LSP.

> So, in the RPS draft, we

I think you just need an alternate path....there is no guarantee that your
IP path won't be the same as the LSP path...so it's no better than an
alternate path.

> 1. Enable to change/exclude the return paths freely, improve the robustness

Hard to deploy IMO....need operators to comment. This looks more like a
solution looking for a problem.

> 2. Return path could be force to along IP-only path;

Why not a good ol' L2 path...why IP? In MPLS-TP, there might be no IP
forwarding. So IP-only path might not be useful for MPLS-TP.

> 3. Improve the efficient for bidirectional path checking;

Some benefit exists here.

> 4. Enable to check a bidirectional inter-domain/AS path;

Inter-domain lsp-ping still needs to be worked out. Regular uni-directional
LSP lsp-ping is currently broken for many cases of inter-domain LSPs. I
don't think we should half bake an inter-as solution as part of this draft.
You are welcome to work on an inter-as solution.

> http://tools.ietf.org/html/draft-chen-mpls-bfd-enhancement-00.

That's a separate draft anyways.
 
Thanks
Nitin

---

From: Nitin Bahadur <[email-masked]>
Date: Fri, 12 Feb 2010 01:21:50 -0800

On 2/11/10 2:41 PM, "Greg Mirsky" <[email-masked]> wrote:

Dear Nitin,
I agree on your perspective regarding co-routed bi-directional LSP. As it was intentionally built with fate sharing between ingress/egress directions I don't see why operator will need to specify return path other than opposite direction of LSP under examination.

Troubleshooting bi-directional associated connection might have different requirements. (Wish we have someone from operators community to speak here).

NB> I agree

 As directions, in general case, are diversly routed, so I see value in specifying return path. It is logical to name opposite direction of associated connection as default return path but explicit, one-time overwrite seems to have value.

And now we get to unidirectional LSP. Since such construct exists and is listed in MPLS-TP I consider tools to troubleshoot them be of value. If one applies bi-directional p2p BFD (aka "classical") to unidirectional LSP then the question of return path comes up sooner than later. What might be interesting to explore, I think, is whether BFD Multipoint model can be applied to unidirectional LSP (unidirectional LSP as special case of unidirectional p2mp).

NB> I think the BFD multipoint model can be broken down and represented as a bfd p2p model. In BFD p2mp, leaf nodes do not necessarily need to send packets to the root (ingress) node. In BFD p2p, egress (leaf) node can advertise a very high tx value so that it doesn’t necessarily need to send packets that often to the ingress (root).

NB> Return path is always an issue for p2p mpls bfd sessions....since it can be anything and it can break. Explicitly specifying the return path might not help, since if the return path breaks (permanently), you will need to introduce new logic to instruct the ingress to now ask the egress to send packets on a different return path. It’s going to complicate your state machine more than you want to...and introduce corner cases and timing issues.

Nitin

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 12 Feb 2010 23:26:50 -0800

Hi  Nitin,

> 2) Ensuring that echo response is received on the reverse path of the

I am not sure what you mean the FEC in both directions of a bidirectional
LSP is the same. The FEC of an FTN entry tells what traffic is to be mapped
to a particular LSP and they are bound to be different depending on the
FEC's on each side of the tunnel.

Thanks,
Vishwas

> >> egress should respond. I fail to see how operators will use this
> *ability*
> >> in
> >> If the operator knows this via config, then the same config could be
> added
> >> at
> >> LSP egress as well.
> >
> >> If the operator is just going to loop through (in return-path tlv) all
> the
> >> egress

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 12 Feb 2010 23:40:29 -0800

Hi Nitin,

Interesting example.

If an operator specifies the name does not mean the name is what is
signalled across. We could use the LSP Key for signalling and keep a mapping
in the code from the name to the LSP Key, which could be called different/
same names in either direction. Am I missing the point here?

However I liked the points Mach brought about the fault direction detection.

Thanks,
Vishwas
On Wed, Feb 10, 2010 at 11:43 PM, Nitin Bahadur <[email-masked]> wrote:

> Deploying ingress based policy can be a nightmare. Suppose you have a LSP
> (called lsp-1) from San Francisco to New York.
> And suppose you have a LSP (called lsp-2) from NY to SF. You could (in
>  theory) instruct in the OAM msg that NY should
> operator has to make a change even in the router in San Francisco. Isn’t
> this a deployment hassle? You can say that NMS
> will take care of it....but even the NMS has to be programmed with this
> dependency.....maintenance has to be scheduled
> In both NY and SF.
>
> Instead if the policy was only in NY (say – for all OAMs coming on any LSP
> from SF,  reply using lsp-2), then the operator could easily
> change the lsp name and the policy, without scheduling potential
> down-time/maintenance time in SF. If the operator wanted to bring
> down the LSP in NY, then he could do that and get rid of the policy in
> NY....instead of having to go to SF and change the policy there.
>

---

From: Mach Chen <[email-masked]>
Date: Sat, 20 Feb 2010 10:49:08 +0800

Hi Nitin,

Thanks for your comments and sorry for the delayed response!

--------------------------------------------------
From: "Nitin Bahadur" <[email-masked]>
Sent: Friday, February 12, 2010 4:29 PM
To: "Mach Chen" <[email-masked]>; "'George Swallow'" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "So Ning" 
<[email-masked]>; <[email-masked]>; 
<[email-masked]>
Subject: Re: Comments for draft-chen-mpls-return-path-specified-lsp-ping-01

> with the forward path or reverse path. That's a good problem statement to

Yes.

> creates an implicit binding betweens multiple return paths.

Actually, no matter what the presented solution exists, when the LSPs 
established between the egress and the ingress, the ingress node will always 
have the detailed knowledge of the FECs originating at the egress. The 
RPS-Ping just uses these information to help in fault localization.
> alternate path" in which the egress will rely using the non-default path.

"Reply via alternate path" is one of the fuctions of RPS-Ping.

> If even the non-default path is broken, then you have a problem.
In theory, that would happen, but mostly, this will not happen. If both the 
default and the non-default are broken, that exactly gives the operators 
more evidence to determine that the return path is broken, and the forward 
path is workable, more attention need to be paid to the return direction.

>I'm not convinced if that problem is worth addressing....
I have met such a situation in a real network where it is desired to 
determine of which direction is broken, hence to help in fault localization.

> is to reduce the coupling between the ingress and egress and reduce
In RPS-Ping, it does not require to do any extra permanent configuration in 
advance, it just give more methods to the operators in fault localization.

Best regards,
Mach

---

From: Mach Chen <[email-masked]>
Date: Sat, 20 Feb 2010 16:59:49 +0800

Hi Nitin,

Sent: Friday, February 12, 2010 5:13 PM

> will drop it since it won't be expecting an echo response.

Almost agree with your analysis, but the echo request/the echo reply MUST 
inlcude the FEC Stack of the LSP, hence it could perform CV validations of 
both directions of the LSP.

> regarding the association, so it can perform any CV validations.

Although RFC 4379 has already specified that "The FEC Stack TLV from the 
echo request MAY be copied to the reply." IMHO, for CV validation of the 
reverse path, the current specification is not enough, it does not define 
how to process when the ingress received a echo reply with an FEC Stack TLV. 
And that "MAY" sometime probably means "may not"!

For co-routed bidirectional LSP, since the FEC is the same, that would be 
OK, but at least need some carification.

For associated bidirectional LSP, just copy the FEC Stack TLV from the echo 
reply does not work, the egress/terminator MUST add a new FEC Stack TLV of 
the reverse LSP when sending the echo reply. And the ingress/initiator 
should be able to differentiate the FEC Stack TLV is for forward or reverse 
LSP. This is one of purposes of the RPS-Ping draft trying to achieve.

sniped...

> maintenance windows. OAM should be simple and stupid...otherwise it will 

The RPS solution just adds a new reply mode(Reply via specified return path) 
to the LSP-Ping, hence to provide more fucntions in LSP testing and fault 
localization. Compare to other LSP-Ping function, according to the functions 
it provide, our solution will not increase extra complexity of LSP-Ping and 
it is deployable.

> equation doesn't favor multiple alternate paths.

In theory, RPS solution has the capability to loop through all LSPs, if the 
operators want, it could do that, but it does not mean it should alway be 
like that. Reply via an alternate is included in the RPS solution.

> IP path won't be the same as the LSP path...so it's no better than an

Althouth the IP path and the LSP path may have the same path, but the 
forwarding process of each is different, and it is possible that IP 
forwarding is OK, but MPLS is not OK, and vice versa, and this has real 
happened in a network.

sniped...

Again, here is the summary of our RPS draft.

1. By extending LSP-Ping enable that the return path of echo reply could be 
specified/changed on-demand, hence to help in judging whether the forward or 
reserse LSP is broken.

2. Echo reply is extended(by including the FEC Stack TLV of the return path) 
to have the capability of testing the revserse path, a bidirectional path 
checking could finished within a single operation, hence to simplify the 
operation and increase the efficiency.  With this capability, it could also 
help a lot in inter-damain/AS LSP checking scenario(no need to perform 
reserve LSP checking from the remote side which belongs to other SPs).

Best regards,
Mach

---

From: <[email-masked]>
Date: Mon, 22 Feb 2010 16:27:44 +0000

On 11/02/2010 22:41, "Greg Mirsky" <[email-masked]> wrote:

> Dear Nitin,
> I agree on your perspective regarding co-routed bi-directional LSP. As it was
> intentionally built with fate sharing between ingress/egress directions I
> don't see why operator will need to specify return path other than opposite
> direction of LSP under examination.
> specifying return path. It is logical to name opposite direction of associated
> connection as default return path but explicit, one-time overwrite seems to
> have value.

IMO the opposite direction of the associated bidirectional LSP should be
used by default.

I can't think of an application for overwriting it off the top of my head,
but that's not to say one doesn't exist.

Ben

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 22 Feb 2010 12:18:32 -0500

Without specifying, you cannot tell if the forward or reverse LSP is broken.  These are specified in  RFC4378 already:

   [RFC4379] states that the third mode may be used when the IP return
   path is deemed unreliable. This mode of operation requires that all
   intermediate nodes must support the Router Alert option and must
   understand and know how to forward MPLS echo replies.

	The thing that puzzles me about this draft is that seems to be finding "more reliable" return paths than even "unreliable" ones:

   And in any case, the use modes 2 or 3 cannot guarantee the delivery
   of echo responses through an IP network that is fundamentally
   unreliable. The failure to deliver echo response messages can lead
   to false negatives making it appear that the LSP has failed.

	--Tom

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 22 Feb 2010 09:33:43 -0800

Hi Tom,

Maybe the word "more reliable" is a misnomer. It should probably be
alternate paths.

Thanks,
Vishwas
On Mon, Feb 22, 2010 at 9:18 AM, Thomas Nadeau <[email-masked]>wrote:

>
>        Without specifying, you cannot tell if the forward or reverse LSP is
> broken.  These are specified in  RFC4378 already:
>
>        The thing that puzzles me about this draft is that seems to be
> finding "more reliable" return paths than even "unreliable" ones:
>
> associated
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: Mach Chen <[email-masked]>
Date: Wed, 24 Feb 2010 17:18:02 +0800

Hi Ben,

--------------------------------------------------
From: <[email-masked]>
Sent: Tuesday, February 23, 2010 12:27 AM
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Subject: Re: [mpls-tp] [mpls] Comments for 
draft-chen-mpls-return-path-specified-lsp-ping-01

>> was

How about when the default return path is suspected broken, overwriting may 
help in judging whether the return path is borken or not.

By the way, with this return path specified capability, it may be used to 
setup an associated bidirectional LSP.

---

From: Mach Chen <[email-masked]>
Date: Wed, 24 Feb 2010 17:53:17 +0800

Hi Ben,

--------------------------------------------------
From: "Thomas Nadeau" <[email-masked]>
Sent: Tuesday, February 23, 2010 1:18 AM
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Subject: Re: [mpls-tp] [mpls] Comments 
fordraft-chen-mpls-return-path-specified-lsp-ping-01

> broken.  These are specified in  RFC4378 already:

Yes, agree, thanks for pointing out the RFC.

> The thing that puzzles me about this draft is that seems to be finding 
> "more reliable" return paths than even "unreliable" ones:

Sorry for the puzzle!

As Vishwas said, the draft is trying to help in fault localization (e.g., 
tell whether the forward or reverse LSP is broken) by specifying alternate 
paths.

Best regards,
Mach

---

From: <[email-masked]>
Date: Sun, 28 Feb 2010 19:01:37 +0000

Mach,

> help in judging whether the return path is borken or not.

If the default return path is broken and the default return path is the
opposite direction of an associated bidirectional LSP then the entire
associated bidirectional LSP is essentially broken.

This then implies that use of draft-chen-mpls-return-path-specified-lsp-ping
is for troubleshooting and diagnostic purposes following the failure of an
LSP?

What advantage does draft-chen-mpls-return-path-specified-lsp-ping provide
to troubleshoot the location in the network where the LSP is broken over say
LSP traceroute?

Thanks
Ben

---

From: Mach Chen <[email-masked]>
Date: Mon, 01 Mar 2010 10:38:52 +0800

Hi Ben,

Thanks for your reply!

--------------------------------------------------
From: <[email-masked]>
Sent: Monday, March 01, 2010 3:01 AM
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Subject: Re: [mpls-tp] [mpls] Comments for 
draft-chen-mpls-return-path-specified-lsp-ping-01

> associated bidirectional LSP is essentially broken.

Yes, it should be.

And presumably the normal logic is that when failures occur, and then try to 
find which direction is broken and then re-construct a new associated 
bidirectional LSP.

>
> This then implies that use of 
> draft-chen-mpls-return-path-specified-lsp-ping

This is one of the purposes of 
draft-chen-mpls-return-path-specified-lsp-ping(by specifying alternate 
return paths).

By the way, since the draft extends the fucntion of echo reply(by including 
the FEC stack info of the return path) to enable that echo reply could be 
used to test the reverse direction the bidirectional LSP as well. It give 
the capabiltiy to perform LSP checking from whatever which side of the LSP. 
Hence, a bidirectional LSP could be tested within one operation. And in 
inter-AS/domain scenario, since the operator from one side has no right to 
log on to the remote side to perform any operation, with this extension, the 
operators could check the reverse direation of an inter-AS/domain associated 
bidirectional LSP from their own side.
> to troubleshoot the location in the network where the LSP is broken over 

In some scenarios, even with LSP traceroute, it could not locate the failure 
point. Take the following simple topology as an example:
A--B----C--D
    \     /
     E---F
There is an LSP(A-B-C-D) from A to D and two LSPs from D to A (D-C-B-A and 
D-F-E-B-A). LSP(A-B-C-D) and LSP(D-C-B-A) are binded to an associated 
bidirectional LSP, say LSP-a. No matter what the failure is at the hop 
between C and D of LSP(A-B-C-D) or at the reverse direction of LSP-a or at 
D, there will no different in the trace result(A..B..C).

With draft-chen, if the reverse direction of LSP-a is suspected broken, then 
the operator could initiante another LSP ping by specifying LSP(D-F-E-B-A) 
as the return path and then if it works, it could judge that LSP(D-C-B-A) is 
with failures.

Best regards,
Mach