The MPLS WG Archive

[neil.2.harrison@bt.com]

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