Re: [PWE3] Comments on draft-jc-pwe3-mpls-tp-static-checking-00.txt

Lizhong Jin<lizhong.jin@zte.com.cn> Wed, 28 March 2012 20:49 UTC

Return-Path: <lizhong.jin@zte.com.cn>
X-Original-To: pwe3@ietfa.amsl.com
Delivered-To: pwe3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8586921E8089 for <pwe3@ietfa.amsl.com>; Wed, 28 Mar 2012 13:49:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.451
X-Spam-Level:
X-Spam-Status: No, score=-101.451 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znih9NjAXjZe for <pwe3@ietfa.amsl.com>; Wed, 28 Mar 2012 13:49:19 -0700 (PDT)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6103021E8043 for <pwe3@ietf.org>; Wed, 28 Mar 2012 13:49:19 -0700 (PDT)
Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286201397396305; Thu, 29 Mar 2012 04:13:57 +0800 (CST)
Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 93082.2133006739; Thu, 29 Mar 2012 04:49:04 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q2SKnCnu030435; Thu, 29 Mar 2012 04:49:12 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn)
In-Reply-To: <mailman.167.1332961259.4202.pwe3@ietf.org>
MIME-Version: 1.0
To: pwe3@ietf.org, sriganesh.kini@ericsson.com
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OF3038CA1C.5F11B6FF-ONC12579CF.0070506A-C12579CF.007258FF@zte.com.cn>
From: Lizhong Jin <lizhong.jin@zte.com.cn>
Date: Wed, 28 Mar 2012 21:48:53 +0100
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-29 04:49:12, Serialize complete at 2012-03-29 04:49:12
Content-Type: multipart/alternative; boundary="=_alternative 007258FFC12579CF_="
X-MAIL: mse01.zte.com.cn q2SKnCnu030435
Subject: Re: [PWE3] Comments on draft-jc-pwe3-mpls-tp-static-checking-00.txt
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Mar 2012 20:49:20 -0000

Hi Sri,
See inline please. Thank you for the comments.

Lizhong


> ------------------------------
> 
> Message: 2
> Date: Wed, 28 Mar 2012 07:30:19 -0700
> From: Sriganesh Kini <sriganesh.kini@ericsson.com>
> To: "pwe3@ietf.org" <pwe3@ietf.org>
> Subject: [PWE3] Comments on
>    draft-jc-pwe3-mpls-tp-static-checking-00.txt
> Message-ID:
>    <CAOndX-uWUpdr9Pc53QvGjfunSchSMLNJsS8OOyuxghgwX8GfKQ@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Comments
> 
> 1. My first thought on looking at this - what is the relationship of 
this
> to a signaling protocol (LDP) ? Is this trying to replicate that
> functionality or provide som new functionality ?
[Lizhong] this mechanism is to only check the configuration, after 
finished, the mechanism will be stopped. So it is a checking tool, not a 
signaling protocol. The checking procedure is part of same as that does in 
signaling protocol (LDP), but there is also exception, e.g, control word 
checking.

> 
> 2. Is this checking intended to be used as operator initiated or 
proactive
> checking ?
[Lizhong] depends on the implementation. In the draft, it is suggested to 
be trigged basically by configuration changing. It could be also triggered 
by a CLI command.
> 
> 3. The term "corresponding PSN tunnel" has been used. I guess this means
> the PSN tunnel to which the PW is nailed to (?) 
[Lizhong] yes

> However there is no receive
> check to ensure that the received msg is indeed on a tunnel that is
> carrying the PW. Even if there was, what is the need to map this to the
> 'corresponding' PSN tunnel ?
[Lizhong] GAP should carry LSP Identifier in the message, and then could 
check if the LSP Identifier is the corresponding PSN tunnel. The draft is 
lack of this content, and would be added in new version. Only when its 
corresponding PSN Tunnel is UP, the PW could be UP, so we use PW's 
underlying PSN tunnel to transmit parameters. 

> 
> 
> 4. If just the in-label is sent can this be used as a label 
advertisement
> mechanism ?
[Lizhong] yes, could do that, and is only used to advertise label, nothing 
else (e.g, status). In that case, the static PW could be configured only 
with in-label, to reduce configuration burden.

> 
> 
> 
> -- 
> - Sri
> ------------------------------
>