Re: [mpls] Collecting comments on associated bidirectional LSP

[Sterling Lamberto <[e-mail]>]

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

:)