IETF Logo Mail Archive

Re: [mpls] Collecting comments on associated bidirectional LSP

zhang.fei3@zte.com.cn Sat, 25 September 2010 01:25 UTC

Return-Path: <zhang.fei3@zte.com.cn>
X-Original-To: mpls@core3.amsl.com
Delivered-To: mpls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFB613A682C; Fri, 24 Sep 2010 18:25:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -94.264
X-Spam-Level:
X-Spam-Status: No, score=-94.264 tagged_above=-999 required=5 tests=[AWL=0.771, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCb4WcVbBqJw; Fri, 24 Sep 2010 18:25:39 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id A97003A6B31; Fri, 24 Sep 2010 18:25:37 -0700 (PDT)
Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 205952043691617; Sat, 25 Sep 2010 09:23:59 +0800 (CST)
Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 55813.2806151920; Sat, 25 Sep 2010 09:26:05 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o8P1PssJ083657; Sat, 25 Sep 2010 09:25:54 +0800 (CST) (envelope-from zhang.fei3@zte.com.cn)
In-Reply-To: <AANLkTinkNTDm4zKpZz2OhP5WZvRkPiH_UM-3C6ZkmVhb@mail.gmail.com>
To: Sterling Lamberto <lamberto.sterling@gmail.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OF98D959B1.84CD3364-ON482577A9.0006CBCC-482577A9.00085725@zte.com.cn>
From: zhang.fei3@zte.com.cn
Date: Sat, 25 Sep 2010 09:25:47 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-09-25 09:25:48, Serialize complete at 2010-09-25 09:25:48
Content-Type: multipart/alternative; boundary="=_alternative 00085722482577A9_="
X-MAIL: mse2.zte.com.cn o8P1PssJ083657
Cc: mpls@ietf.org, ccamp@ietf.org, mpls-tp@ietf.org
Subject: Re: [mpls] Collecting comments on associated bidirectional LSP
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sat, 25 Sep 2010 01:25:40 -0000

Hi Sterling

Sorry for the delayed response, I am on vacation. See in line

Kind regards

Fei



Sterling Lamberto <lamberto.sterling@gmail.com> 
2010-09-12 09:25

收件人
zhang.fei3@zte.com.cn
抄送
mpls-tp@ietf.org, ccamp@ietf.org, mpls@ietf.org
主题
Re: [mpls] Collecting comments on associated bidirectional LSP






Hi Fei,
After a brief review of the draft, there are several points:
1. section 4.1, point 3, why node B sends PATH message of LSP2 with 
ASSOCIATION object with same  value as that of LSP1? It seems a bit 
strange, what's your consideration about that?

ZF:It is in accordance with RFC4872, based on the same value, the two LSPs 
can be bound together

2. in section 4.2 peer mode, what if the backward LSP has been already 
setup before setting up the forward LSP? In that case, if backward LSP 
without ASSOCIATION object does not wish to be bound, how to handle that 
case?

ZF: Actually I do not consider the situation that the backward LSP does 
not wish to be bound in the 00 version of this draft. It can be handled in 
accordance with the first operation mode. That is to say, if Association 
object is carried, it can be bound; if not carried, can not be bound. 

3. will asymmetric bandwidth allocation for associated LSP be described in 
future draft?

ZF: Yeah, this will be added
 
Lamberto.
 
==========================================================
Hi all, 

Associated bidirectional LSP, defined in RFC5654, is useful for protection 
switching, for OAM that requires a reply (from MIP or MEP), and for defect 
correlation. 

There are potentially several solutions, such as GMPLS call, the 
Association object, and the LSP_TUNNEL_INTERFACE_ID object. Furthermore, 
the scheme based on the extensions to 

the Association object has been presented in IETF77, and there are some 
discussions on the mailinglist. 

We need to receive more comments on this topic to push this work forward, 
then update the document, 

http://tools.ietf.org/html/draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-00
, which is recently expired. 

Any comments are welome. 

B.R. 

Fei 

:)

v2.26.15 | Report a Bug | By Email | System Status