Re: [mpls] Collecting comments on associated bidirectional LSP

[Lamberto Sterling <[e-mail]>]

Hi
Thank you for the clarification.

Cheers
Lamberto

2010/10/18 <[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]* <[e-mail]>>
>
> Hi Sterling
>
> Sorry for the delayed response, I am on vacation. See in line
>
> Kind regards
>
> Fei
>
>   *Sterling Lamberto <**[e-mail]*<[e-mail]>
> *>*
>
> 2010-09-12 09:25
>
>   收件人
> *[e-mail]* <[e-mail]>
> 抄送
> *[e-mail]* <[e-mail]>, *[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).
>

Lamberto: OK, I see.

>
>
> 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: thanks. maybe internet service makes a little sense.

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