Re: [mpls] Collecting comments on associated bidirectional LSP

[[e-mail]]

Hi lamberto

See in line...

Kind regards

Fei :)



Lamberto Sterling <[e-mail]> 
2010-10-17 16:59

收件人
[e-mail]
抄送
[e-mail], [e-mail], [e-mail]
主题
Re: [mpls] Collecting comments on associated bidirectional LSP






Hi Fei,
See in line, thanks.
 
Cheers
Lamberto

2010/9/25 <[e-mail]>

Hi Sterling 

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

Kind regards 

Fei 


Sterling Lamberto <[e-mail]> 
2010-09-12 09:25 


收件人
[e-mail] 
抄送
[e-mail], [e-mail], [e-mail] 
主题
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 
Lamberto: OK, I see.

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. 

Lamberto: I do not agree. It is very likely that the backward LSP is a 
normal LSP that does not support the association feature described in this 
draft, the the bind mechanism will break with one end binding successfully 
and one end binding failure. The backward LSP should also carry the 
association object to indicate its ability and tunnel id it wishes to 
bind.
 
 ZF: In order to be in accordance with draft-ietf-ccamp-assoc-info-00.txt, 
and do not need to introduce the new association rules, I have deleted 
this operation mode in 01 version. I agree with you that the backward LSP 
should also carry the association object to indicate its ability. But if 
we do this, this operation have no advantages compared to the first 
opearation mode, furthermore, it increases the blocking probability to 
setup associated bidirectional LSP successfully (the ingress nodes do not 
know which tunnel and/or LSP IDs of the egress nodes are unoccupied). 


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

ZF: Yeah, this will be added 
Lamberto: I don't mean to add it. I am interested with the scenario. Can 
you list some?

ZF: According to RFC5654: 14  MPLS-TP MUST support bidirectional transport 
paths with asymmetric bandwidth requirements, i.e., the amount of reserved 
bandwidth
    differs between the forward and backward directions. Here 
bidirectional transport paths include corouted and associated 
bidirectional LSPs. 
As to the scenarios, just my two cents.
(1)Internet service, the bandwidth requirements of upstream and downstream 
direction are different.
(2) For some OAM message, such as LSP ping or BFD, they SHOULD have the 
reverse return path which's bandwidth MAY be smaller than the forward 
direction.
 
 
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 

:)