Subject: Static and dynamic label distribution protocol relationships

From: [email-masked]
Date: Fri, 7 Jul 2000 12:18:43 +0100

Folks,

Some of you are aware that I am considering the user-plane OAM functional
requirements of MPLS LSPs from an operator's perspective.  Indeed, I have
already had some off/on-list discussions with some of you which have been
very useful - so many thanks to those who took time to comment.
Note - Our discussions seemed to be converging on defining special 'OAM
label' that would sit below the normal user-plane traffic forwarding label.
This would simply mean that when a OAM pkt was sent the label depth which
would normally be M (say) at some nested LSP level (at or below the level of
the OAM pkt insertion) would become M+1.  The key identifier now would be
the fact that the S bit would be set in the special OAM label instead of the
normal forwarding label.

More recently however, and partly in preparation of pursuing the OAM work, I
have been trying to figure out what are the configuration and dynamic
behaviour relationships between the various Label Distribution Protocols
(LDPs) and I would be very grateful if anyone could help me on this matter. 

Considering that........
There are 4 LDP varieties that I am aware of - Vanilla_LDP, RSVP_LDP, CR_LDP
and iBGP4_LDP.  And where:
-	The former is the most generic, and largely based on the IGP
functional behaviour (eg for the major FEC-types).  It uses UDP for
discovery and TCP for everything else.
-	The latter is largely targeted at delivering MPLS-based VPNs,
obviously based on BGP4 functional behaviour and  has a key role is
isolating overlapping v4 private address spaces.  It is based on TCP
sessions.
-	The other 2 are mainly targeted at a CBR/TE role and use RSVP
extensions and Vanilla_LDP extensions respectively.  And one would normally
only choose to implement one of these and not both.
.......then:

1	What are the allowable or deprecated combinations of LDP that can
exist in an operator's network?

2	Does it matter which order the various LDP-types are implemented and
brought up?  For example, the LSPs of an iBGP4 based VPN would need a server
layer LSP (ie label stack of >= 2) within the core LSR network.

3	In 2, should (must?) the server layer LSPs be Vanilla_LDP or could
they be RSVP_LDP or CR_LDP?  Note that the latter might make more sense when
one considers the dynamics of the various LDPs under failure modes, and
especially in the case of offering SLAs to VPN customers......see next
question.

4	  Suppose one had iBGP4 VPN LSPs, running over Vanilla LSPs, running
over RSVP or CR_LDP LSPs.  What happens dynamically on failure here (this
could be various failure modes, but just assume a physical link failure for
now)?  Note - if the answer to 2 was that the 'bringing-up' order of
LDP-types was important, then if seems it would also have to remain so here.
So has anyone done any work on understanding the dynamic post-failure
relationships of the IGP convergence, BGP4 survival (TCP sessions),
Vanilla_LDP (UDP/TCP aspects, and assuming a stable IGP?), the potentially
very fast explicitly routed TE LSPs using RSVP/CR_LDP and the overarching
iBGP4 VPN LSPs (and the ensuing VPN availability/QoS behaviour that an
operator can offer in SLAs)?  This whole area of the dynamic post-failure
behaviour stacked LDP varieties concerns me and it something I think
operators would need to understand better.

5	Can the PHP phenomenon appear in any type of LDP?  And if so, are
there any hidden implications when various LDP-types are nested?
Note - I personally do not like the notion of PHP since it means that I
cannot define a consistent trail termination point for an LSP and hence
cannot be clear on exactly where key functional behaviour is located, eg
defect processing, consequent actions on defect detection (eg sending a FDI
to higher level LSPs), restoration triggers, QoS/avail metric processing,
etc.

I think many operators tuned-in to the list would be grateful for any help
in understanding the above relationships more clearly.

Regards, Neil