Re: [mpls] Collecting comments on associated bidirectional LSP

[Lamberto Sterling <[e-mail]>]

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.

>
>
> 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?

>
> 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
> *<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
>
> :)
>