Subject: Re: [CCAMP] [mpls] Collecting comments on associated bidirectional LSP

From: Sterling Lamberto <[email-masked]>
Date: Sun, 12 Sep 2010 09:25:59 +0800

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?
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?
3. will asymmetric bandwidth allocation for associated LSP be described in
future draft?

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

:)

---

From: [email-masked]
Date: Sat, 25 Sep 2010 09:25:47 +0800

Hi Sterling

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

Kind regards

Fei

Sterling Lamberto <[email-masked]> 
2010-09-12 09:25

收件人
[email-masked]
抄送
[email-masked], [email-masked], [email-masked]
主题
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. 

ZF: Yeah, this will be added
 
Lamberto.

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 

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 

:)