The MPLS WG Archive

["Robert Schellhase" <rschell@megapathdsl.net>]

Thanks for the RSVP insights. They improve my overall understanding of
what's happening.

UDLR is supposed to fix the problem of receiving on one interface while
sending on another, by combining the two physical paths into a single
logical interface. So it sounds like we are saying that since MPLS uses RSVP
to build its tunnels, but RSVP needs bi-directional interfaces to get its
job done, and therein lies the problem.

Am I reading this correctly? Does anyone else have thoughts, or a possible
workaround idea?

Best regards,
Robert

-----Original Message-----
From: Alexander Marhold [mailto:Alexander.Marhold@proin.com]
Sent: Thursday, November 30, 2000 2:07 AM
To: Nhat Thanh Hoang; Alexander.Marhold@xandl.cso.net; eduard metz;
rschell@megapathdsl.net
Subject: RE: MPLS for UDLR


> As I know RSVP for traffic engineering that uses in MPLS context is
> unidirectional, which means you need to configure at least two
> constraint-based LSPs (ingress--->egress and ingress<---egress),
> if you want
> a bidirectional path.
>
>> LSP is unidirectional, but RSVP is not,
>>

Sorry for not being clear enough:
Of course you are right  the tunnel which is set up by RSVP is
unidirectional (this is what we tell RSVP when starting the RESV message).

What I wanted to express is:
That the messages itself, RSVP is sending forward (RESV) and backwards
(PATH) to set up the path are assumed to go over the same links in forward
and reverse direction. In the UDLR case those links forward and reverse are
different.

And I think that exactly that is the problem in the UDLR case.

with best regards
Alexander