Subject: RE: Asymmetrical Bi-directional LSPs

From: Adrian Farrel <[email-masked]>
Date: Thu, 28 Sep 2000 10:44:58 +0100

Bora,

I agree with your concerns about moving goal-posts, but...

>-----Original Message-----
>From: Bora Akyol [mailto:[email-masked]]
>"J. Noel Chiappa" wrote:
>>     > From: Bora Akyol <[email-masked]>
>>     > Although I don't like the idea, if this comes to 
>>     >happen, option 3
>>     > would be my preference.
>>
>> ??? LSP's aren't bidirectional anyway, right? (What *is* the 
>> opposite of 'merge' - 'spray'? :-) So what difference does it
>> make if someone wants the back channel to take a different 
>> path? It's not like there's a mechanism already to do 
>> bidirectional LSP's and this is breaking it.
>
>Not quite true, if we do option 3, then we will have to add 
>another object to the PATH message to indicate the reverse 
>path that we would like the reverse LSP to follow. This is 
>more work and I am getting tired of adding new stuff to our
>RSVP code almost every week ;-(

This need not be the case.  Consider that GMPLS allows a Label on a Path
message.  If we remove the requirement for a Label_Request/Suggested_Label
we are there.

>I do not want to add to RSVP-TE before it becomes an RFC. If 
>you look at MPLS WG web page, you will find that there is a 
>boatload of MPLS ID's but not many RFCs.
>This is frustrating because things keep on changing and nothing is ever
>finalized. I think MPLS WG should close its doors to new items 
>until it can clear its existing items.

Agree.  It is hard to develop to a draft that keep s changing.

I may be wrong, but I believe that RSVP-TE is quite close to stable now.
The changes I'm discussing would be for the Generalized Signaling draft,
which (I assume) will make its separate way towards RFC.

Adrian
--
Adrian Farrel  mailto:[email-masked]
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422

---

From: [email-masked]
Date: Thu, 28 Sep 2000 18:42:18 +0100

Adrian,

1st some quick observations on need or otherwise for bi-directionally
symmetric LSPs:

1	Depends on application and whether LSP supporting public application
directly (eg public voice service) or a larger aggregate service (eg a
VPN.....which maybe has voice as 1 application component).  For the former I
think bi-directionally symmetric LSPs are essential (some may disagree I
guess).

2	Let's look at the VPN issue a little bit further.  Operators will
need to be able to offer orthogonal availability and QoS SLAs to many
customers, but esp VPN customers.  QoS only applies to the up-state of a LSP
and is only relevant to required forwarding behaviour of a given application
and not its survivability requirement.  That is, voice in 1 VPN may be
mission critical but this may not be true in another VPN.....but both need
EF treatment otherwise they don't work.  But if we aggregate/merge DS
classes in LSPs within the core of a MPLS network we will tend to lose sight
of the VPN topology.  On failure, DS aggregation will tend to favour
survival of the EF class (ie if we have congestion), ie in other words CNLS
networks mutate failures into QoS hits, and having several DS classes just
skew this effect.  So, the fundamental point I am trying to make here (in
relation to the question you ask) is that (i) I must have the ability to
offer SLAs which have orthogonal availability and QoS components and (ii)
for some services such as VPNs I may *not* want to merge the traffic therein
on a DS/LSP basis within my core network since the survivability index I
wish to associate with that VPN is much more important than any QoS
aspect......hence, I will need to use bi-directional (and ideally symmetric)
LSPs if I am not controlling the applications which are using this VPN (and
I am not, the customer is).

3	If I am aggregating only purely AF-types of traffic (eg current BE
Internet, and outside VPNs) then uni-directionally established LSPs look
seem OK.

4	There are some other issues wrt OAM and prot-sw that are impacted by
the choice of unidirectional/bi-directional (asym/sym) LSPs, and also
whether one can assume congruent user-plane and control-plane
routings.......the latter will vary with technology, eg Optics.  But these
depend on whether one wants to tell an upstream end of an LSP from A->B that
problems are being experienced at B.  Some of these issues can be tackled
outside the user-plane, eg via the control-plane or management-plane say, if
this is appropriate.  One factor that needs to be stressed however is in
respect of any OAM BDI (backward defect indicator) in the case of
bi-directional LSPs and unidirectional failures.  Any BDI *must* be
generated from the (source) trail termination of the return LSP and *not*
some mid point.  This allows correct arch operation for both symmetric and
asymmetric bi-directional LSP routings.

In terms of the 1,2,3 options you gave, I prefer 3.

Neil

---

From: Riad Hartani <[email-masked]>
Date: Thu, 28 Sep 2000 15:03:03 -0700

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. 

> From: Lou Berger [mailto:[email-masked]]
> Sent: Thursday, September 28, 2000 6:11 AM
> To: [email-masked]
> Cc: [email-masked]
> 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.
>