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

From: [email-masked]
Date: Thu, 25 Mar 2010 08:44:48 -0800

Hi MPLS WG and authors,
Because of time limited at MPLS session, I need to address my comments 
more clearly.
The problem is for "Specify a more generic tunnel FEC as return path". 
Every time, you want to do LSP Ping, you have to setup a dedicated RSVP-TE 
tunnel on the remote node. This dedicated RSVP-TE tunnel will, of course 
consume BW resource in the network. Then the operation step will be as 
follows:
1. Setup a dedicated RSVP-TE tunnel on the remote node,
2. Do LSP Ping on local node, and specifying the return path,
3. After LSP Ping sucessfully, delete the dedicated RSVP-TE tunnel on the 
remote node, or leave it as it is to continue consuming BW resource?
4. Or you want to have a dedicated RSVP-TE tunnel on the remote node 
without deleting it anytime? But this is unacceptable for me.

Please consider the above operational issue. And the key problem is, LSP 
Ping is an on-demand function. I know, by using RSVP-TE tunnel as return 
path can bring the reliability to Ping function. But please keep in mind, 
the solution cost more, gain less.

If you do want to do reliable detection, use other mechanism, e.g, BFD as 
described in the BFD-Enhance draft. Just put LSP Ping operation as simple 
as it is now.

Best Regards
Lizhong

------------------------------

Message: 3
Date: Sun, 28 Feb 2010 19:01:37 +0000
From: <[email-masked]>
Subject: Re: [mpls] [mpls-tp] Comments for
                 draft-chen-mpls-return-path-specified-lsp-ping-01
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: [email-masked], [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"

Mach,

On 24/02/2010 09:18, "Mach Chen" <[email-masked]> wrote:
>> 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.
> 
> How about when the default return path is suspected broken, overwriting 
may
> 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

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

End of mpls Digest, Vol 70, Issue 40
************************************

--------------------------------------------------------
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: Fri, 26 Mar 2010 01:35:05 +0800

Hi Lizhong,

The draft does not propose to setup a new dedicated RSVP-TE Tunnel, the 
Tunnel or LSPs are already there, it just uses it, I think you misunderstand 
the draft.

Thanks,
Mach

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

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

---

From: [email-masked]
Date: Thu, 25 Mar 2010 13:54:27 -0800

Hi Mach,
What do you mean by "the Tunnel or LSPs are already there"? When and 
what's the purpose of setting up these "Tunnel or LSPs" you mentioned, 
carring service or leave them alone or only for LSP Ping?

We should think about the whole operational process.

BR
Lizhong

Mach Chen <[email-masked]> 
2010-03-25 09:35
Please respond to
Mach Chen <[email-masked]>

To
[email-masked], [email-masked]
cc
[email-masked], [email-masked], [email-masked], 
[email-masked]
Subject
Re: [mpls] [mpls-tp] Comments for 
draft-chen-mpls-return-path-specified-lsp-ping-01

Hi Lizhong,

The draft does not propose to setup a new dedicated RSVP-TE Tunnel, the 
Tunnel or LSPs are already there, it just uses it, I think you 
misunderstand 
the draft.

Thanks,
Mach