Re: [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt

Loa Andersson <loa@pi.nu> Thu, 19 May 2011 06:09 UTC

Return-Path: <loa@pi.nu>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DE1E06F6 for <mpls@ietfa.amsl.com>; Wed, 18 May 2011 23:09:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level:
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_62=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVzTxeB9cBoY for <mpls@ietfa.amsl.com>; Wed, 18 May 2011 23:09:11 -0700 (PDT)
Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id BA501E06D1 for <mpls@ietf.org>; Wed, 18 May 2011 23:09:08 -0700 (PDT)
Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id C8ED82A8001; Thu, 19 May 2011 08:09:05 +0200 (CEST)
Message-ID: <4DD4B401.4090501@pi.nu>
Date: Thu, 19 May 2011 08:09:05 +0200
From: Loa Andersson <loa@pi.nu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <yaacov.weingarten@nsn.com>
References: <XFE-RCD-302agj5BbHk0000001a@xfe-rcd-302.cisco.com> <201105130203.p4D23KEd065500@mse02.zte.com.cn> <E4873516F3FC7547BCFE792C7D94039C326FBB@DEMUEXC013.nsn-intra.net>
In-Reply-To: <E4873516F3FC7547BCFE792C7D94039C326FBB@DEMUEXC013.nsn-intra.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: Ross Callon <rcallon@juniper.net>, draft-ietf-mpls-tp-li-lb@tools.ietf.org, Sami Boutros <sboutros@cisco.com>, mpls@ietf.org
Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 May 2011 06:09:11 -0000

Yacoov,

indeed, isn't this one of the reason you'd actuall would like to put
an LSP or PW in loopback?

/Loa

On 2011-05-17 06:03, Weingarten, Yaacov (NSN - IL/Hod HaSharon) wrote:
> Hi,
>
> Again I am not sure that I understand the confusion – if the segment of
> the LSP is in loopback mode then it should be easy for the source LER to
> detect either of the misconnectivity conditions that you describe –
>
> 1. For the case of messages that are lost due to a misconnectivity
> between the source LER and the MIP that is looping back – the messages
> that are lost will not be looped-back, which can be detected by the
> source LER
>
> 2. For the case of messages that are leaking into the segment from a
> different LSP – this message will be looped back by the MIP and the
> source LER could detect an excessive message in the stream.
>
> However, as was pointed out in a separate thread – it is advisable to
> only enter loopback on an LSP that there are no suspected misconnectivities!
>
> Hope this helps,
>
> yaacov
>
> *From:*ext liu.guoman@zte.com.cn [mailto:liu.guoman@zte.com.cn]
> *Sent:* Friday, May 13, 2011 4:47 AM
> *To:* Sami Boutros
> *Cc:* draft-ietf-mpls-tp-li-lb@tools.ietf.org; Loa Andersson;
> mpls@ietf.org; Ross Callon; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
> *Subject:* RE: [mpls] working group last call on
> draft-ietf-mpls-tp-li-lb-01.txt
>
>
> sami, yaccov,hi
> firstly i say sorry for not clearly describling my question.
> for the first question, maybe yaacov's understanding be right. if a mep is
> on loopback state, it can't check the e2e path for mis-connectivity because
> the mep point loopback everything including any OAM packet(cc&cv etc);
>
> for the second question, I know loss/delay measurement should use LM/DM
> fuction to
> implement it. but for loopback function, there are the following two
> application:
> 1 To verify bidirectional connectivity of a MEP with a MIP or a peer MEP;
> 2 To perform a bidirectional in-service or out-of-service diagnostics
> test between a pair of peer MEPs. This includes verifying bandwidth
> throughput, detecting bit errors, etc;
>
> so for application 1, loopback anything will not affect verify
> bidirectional connectivity; but it may affect diagnostics test.
> for example, if mis-connectivity or mis-configuration happened on a LSP
> path, since the mep of the lsp is under loopback state, it can't check
> mis-connectivity,
> so the mep of the lsp maybe loopback other data packet of another lsp to
> the peer mep.or the data pkt of the LSP will be leaked to other LSP
> path, so it must affect the result of diagnostics test including
> bandwidth throughput, bit errors.
>
> maybe i miss something important?
>
> thank sami and yaacov for prompt replying it.
>
> B.R.
> Liu
>
> 	
>
>
>
>
> *Sami Boutros <sboutros@cisco.com>*
>
> 2011-05-13 05:05
>
> 	
>
> 收件人
>
> 	
>
> "Weingarten, Yaacov (NSN - IL/Hod HaSharon)"
> <yaacov.weingarten@nsn.com>, <liu.guoman@zte.com.cn>, "Loa Andersson"
> <loa@pi.nu>
>
> 抄送
>
> 	
>
> "Ross Callon" <rcallon@juniper.net>, <mpls@ietf.org>, "MPLS-TP ad hoc
> team" <ahmpls-tp@lists.itu.int>, <draft-ietf-mpls-tp-li-lb@tools.ietf.org>
>
> 主题
>
> 	
>
> RE: [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt
>
> 	
>
>
>
>
> Agreed Yaacov, during the period of loopback the cc-cv function can't be
> performed, and yes the main benefit is of loopback is to measure
> loss/delay on a segment of a path as you stated.
>
> Thanks,
>
> Sami
> At 10:36 PM 5/11/2011, Weingarten, Yaacov (NSN - IL/Hod HaSharon) wrote:
> Sami, hi
>
> My understanding is that the question that was asked is how do you use
> the cc-cv function to check for mis-connectivity if it is being looped-back.
>
> Truth be told that during the period of loopback you apparently cannot
> check the e2e path for mis-connectivity, and the operator needs to take
> this into consideration. But since the path is not transferring data e2e
> (it is looping everything back) it is by definition not connected e2e.
>
> What is true is what Sami states this functionality should be used to
> setup a loss/delay measurement on a segment of a path, and it should be
> used only for limited periods.
>
> Just my 2cents,
> yaacov
> *
> From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf
> Of *ext Sami Boutros*
> Sent:* Thursday, May 12, 2011 8:03 AM*
> To:* liu.guoman@zte.com.cn; Loa Andersson*
> Cc:* Ross Callon; mpls@ietf.org; MPLS-TP ad hoc team;
> draft-ietf-mpls-tp-li-lb@tools.ietf.org*
> Subject:* Re: [mpls] working group last call on
> draft-ietf-mpls-tp-li-lb-01.txt
>
> To check for mis-connectivity/mis-configuration, you need a cc-cv
> function not a loopback function.
>
> The loopback function can be used for loss/delay measurements, and this
> will be addressed in the delay/loss draft.
>
> Thanks,
>
> Sami
> At 07:11 PM 5/10/2011, liu.guoman@zte.com.cn wrote:
>
>
> hi, all
> for this draft, I have a question for Loopback function.
> in last ietf meeting, IMO, the author sami said this
> Loopback function is to loopback anything. for MEP point of
> a LSP, if it is set to Loopback state, it will loopback all received
> packets including any OAM packet. if so, how to detect mis-connectivity or
> mis-configuration for the LSP?
> in addtion, if it happen mis-connectivity, maybe other LSP packet be
> transported to
> the MEP , and the mep point will still Loopback the wrong packet to peer
> mep point,
> can it affectperformance <app:ds:performance> statistics
> <app:ds:statistics> or measurement on the peer mep point?
>
> B.R.
> liu
>
>
>
>
>
> *
> Loa Andersson <loa@pi.nu>*
> ·¢¼þÈË: mpls-bounces@ietf.org
>
> 2011-05-10 23:43
>
>
> ÊÕ¼þÈË
>
>
> "mpls@ietf.org" <mpls@ietf.org>
>
>
> ³­ËÍ
>
>
> Ross Callon <rcallon@juniper.net>, MPLS-TP ad hoc team
> <ahmpls-tp@lists.itu.int>, draft-ietf-mpls-tp-li-lb@tools.ietf.org
>
>
> Ö÷Ìâ
>
>
> [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt
>
>
>
>
> Working Group,
>
> this is to start a two week working group last call on
>
> draft-ietf-mpls-tp-li-lb-01.txt
>
> Please send your comments to the mpls@ietf.org mailing list.
>
> This working group last call ends on May 25th.
>
> /Loa
>
> for the mpls wg co-chairs
>
> --
>
>
> Loa Andersson email: loa.andersson@ericsson.com
> Sr Strategy and Standards Manager loa@pi.nu
> Ericsson Inc phone: +46 10 717 52 13
> +46 767 72 92 13
> _______________________________________________
> mpls mailing list
> mpls@ietf.org_
> _https://www.ietf.org/mailman/listinfo/mpls
>
>
>
>
>
>
>
>
> --------------------------------------------------------
>
>
> 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.
>
>
>
>
> --------------------------------------------------------
>
> 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.

-- 


Loa Andersson                         email: loa.andersson@ericsson.com
Sr Strategy and Standards Manager            loa@pi.nu
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13