The MPLS WG Archive

[Riad Hartani <riad@caspiannetworks.com>]

Adrian,

Extending a protocol from uni-directional to symmetrical bi-directional is
pretty straightforward to do, extending it to asymmetrical bi-directional
would lead to too much complexity. The complexity would not really appear in
terms of setting up the circuit itself, but more in terms of making sure
that all the other features associated with it ( modify, refresh, various
error handling, existing state machines, various existing operations of LSP
tunnels, etc.) remain unchanged and won't break. Adding the assymetric
component will also make it more difficult to add new extended signalling
features such as point to multipoint signalling, OAM, etc. So, in other
words, if you are worried about protocol simplicity, backward compatibility
and interoperability, then doing assymetrical bi-directional is not a very
good idea. 

About five years ago, ATM signalling (the ITU/B-ISUP version of it, not the
ATMF/PNNI one) was looking at how to potentially do something along the same
lines, but it did not get far. Some of the assymetrical signalling
requirements were partially satisfied by using a sort of single call control
associated with multiple path/bearer connections control (This model would
not apply in today's MPLS where there is no notion of call vs. connection
for the NNI). If we see a move towards pure out-of-band signalling for
optical nets (with a logical mapping between the control path and the bearer
path), then I can see how assymetrical bi-directional would probably be
feasible. In this case, signalling would still be symetrical and this would
map to an assymetric in terms of path setup. 

In any case, if you decide to proceed with the assymetrical bi-directional
feature, then this should be done in a separate Internet Draft, so that
compliance to extended_MPLS is not dependant on this feature.

Riad. 
 

> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Thursday, September 28, 2000 6:11 AM
> To: AF@dataconnection.com
> Cc: mpls@UU.NET
> Subject: Re: Asymmetrical Bi-directional LSPs
> 
> 
> Adrian,
> 
> I agree with Kireeti on this one.  Furthermore, the premiss 
> for this is 
> that the reverse path must be calculated at the sender of the first 
> LSP.  Why can't the egress calculate the (possibly 
> asymmetric) path on it's 
> own?  Your really asking for two LSPs, why signal them as 
> one?  (Even ATM 
> doesn't support this.)
> 
> Lou
> 
> 
> At 02:02 AM 9/28/00, Kireeti Kompella wrote:
> >Hi Adrian,
> >
> > > Lou Berger suggested I poll the list to see what interest 
> there is in being
> > > able to set up asymmetrical bi-directional LSPs without 
> the need for an
> > > exterior signaling protocol.
> >
> >For what it's worth, I neither see the need for this, nor am I
> >in favour of it.  In my (admittedly cynical) view, there is a
> >perfectly good exterior protocol to do this, namely, telnet :-)
> >
> >I do see the need for symmetrical bi-directional LSPs (mostly for
> >optical and SONET trails) and (reluctantly at first) accepted the
> >need to extend RSVP for that.
> >
> >Kireeti.
>