Subject: RE: Static LSP Configuration

From: [email-masked]
Date: Mon, 6 May 2002 06:26:58 +0100

> > Also, on your:
> > >>btw- retorical question - with static LSPs, what happens 
> when a link
> > goes down?
> >
> > Should the expected behaviour  need to be any different 
> than when someone
> > routes with static routes?
> >
> > Cheers,
> >
> > --brijesh
> >
> >
> 
> Brijesh,
> 
> Statically configured LSPs blackhole traffic when a link in 
> the middle of
> the LSP fails.
> 
> The LSR immediately upstream of the failure discards all 
> traffic belonging
> to the LSP. This is because that LSR may not look beyond the 
> MPLS label to
> forward the traffic. See RFC 3031 Sections 3.18 and 3.22 for details.
> 
>                                                    Ron
NH=> Ron,  I agree discarding traffic is the only safe thing to do here.
However, if you were running some form of connectivity verification from
source/sink on the LSP that has failed you could at least detect this and
take appropriate action....which could include invoking prot-sw.
regards, Neil

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 06 May 2002 09:55:38 -0400

>If one wants to have only 2 LSPs (one working and one backup) in his 
>network, why should
>he run LDP?

         Because 2 LSPs is not a realistic example.

         --Tom

>-Shahram
>
> > -----Original Message-----
> > From: Sukanta ganguly [mailto:[email-masked]]
> > Sent: Sunday, May 05, 2002 1:43 PM
> > To: Ron Bonica; Brijesh Kumar; 'Curtis Villamizar '; 'Ajay Simha '
> > Cc: [email-masked]; 'gary tam '; [email-masked]
> > Subject: RE: Static LSP Configuration
> >
> >
> > In a fairly controlled and static environment it may
> > work, but in other situations it will create
> > unresolved links and packet drops, with no recovery to
> > the failure.
> >
> > SG
> >
> > --- Ron Bonica <[email-masked]> wrote:
> > > >
> > > > Also, on your:
> > > > >>btw- retorical question - with static LSPs, what
> > > happens when a link
> > > > goes down?
> > > >
> > > > Should the expected behaviour  need to be any
> > > different than when someone
> > > Statically configured LSPs blackhole traffic when a
> > > link in the middle of
> > > the LSP fails.
> > >
> > > The LSR immediately upstream of the failure discards
> > > all traffic belonging
> > > to the LSP. This is because that LSR may not look
> > > beyond the MPLS label to
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Health - your guide to health and wellness
> > http://health.yahoo.com
> >

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.

---

From: "Nagarajan, Ramesh (Ramesh)" <[email-masked]>
Date: Mon, 6 May 2002 12:03:45 -0400

Gary,

I agree with you about being able to do restoration witthout dynamic
signaling. Also, agree with curtis on his points on multiple failures and
need for signaling (instead of painful manual reestablishment of static
LSPs)  there. In particular, see proposal below for restoration which does
not require failure detection (and any other signaling including failure
notification, LSP switching etc.,) for many L1 and L2 layer failures:

http://www.ietf.org/internet-drafts/draft-nagarajan-ccamp-mpls-packet-protec
tion-00.txt

ramesh.

----------------------------------------------------------------------------
--------------------------------------------------
Room 3M-335, Bell labs
Tel: 732-949-2761
101 Crawfords Corner Road
Fax: 732-834-5906
Holmdel, NJ 07733.
e-mail: [email-masked].
----------------------------------------------------------------------------
---------------------------------------------------

> ----------
> From: 	Gary Tam[SMTP:[email-masked]]
> Sent: 	Monday, May 06, 2002 11:20 AM
> To: 	[email-masked]
> Cc: 	Ron Bonica; Brijesh Kumar; 'Curtis Villamizar '; 'Ajay Simha ';
> [email-masked]; [email-masked]
> Subject: 	Re: Static LSP Configuration 
> 
> Hi Curtis, 
> 
> You have some good points. I agree with you that
> dynamic signaling is good and essential. 
> 
> But for protection, you do not have to have dynamic
> signaling protocol. You need 2 disjointed LSPs, and a
> fast fault detection / propagation mechanism (could be
> an OAM control flow or other means for the targeted
> DA). In this case, when there is a link/fiber cut, the
> failure can be detected at where the fault occurs and
> be propagated to where the switch takes place. In
> terms of global/segmented protection, the local-node
> detects the failure instantly and propagates failure
> condition to the targeted DA of the switch node. The
> switch-node performs the switch-over activity as soon
> as it gets the switch-over message. In the entire
> proceess, there is no dynamic signaling here. Besides,
> it will be too slow and costly to do protection with
> RSVP-signaling - ie 50ms protection. Even if you scale
> the RSVP/LDP Hello intervals to 5ms, there are lots of
> issues such as link flapping, lots of hellos. etc.   
> 
> In the Access domain, ie 802.1Q, VLAN/SVLAN is widely
> used for data forwarding and customer data separation.
> There is no urgent need for an Ethernet network to
> implement RSVP-TE or CR-LDP. So static LSP-Stitching
> will be a cheap and inexpensive solution for L2 VPN. 
> 
> Gary
> 
>  
> --- Curtis Villamizar
> <[email-masked]> wrote:
> > 
> > In message
> >
> <[email-masked]>,
> > Gary Tam write
> > s:
> > > 
> > > In the core network ( between port 2 and 3), it
> > can be
> > > nested LSP trunking setup by CR-LDP/RSVP-TE. This
> > will
> > > not change anything in case of failure between 2
> > and 3
> > > with the obvious exception of port 2 and 3. 
> > > 
> > > The static LSP (1,2,3,4) will likely be
> > > Martini-encapsulated Tunnel for some L2 VLAN/MPLS
> > VCs
> > > as well. The L2 FEC can be either MAC DA, VLAN,
> > > Coustomer ID, and ATM VC, etc. 
> > > 
> > > Gary
> > 
> > 
> > Gary,
> > 
> > I didn't think I was going to have to answer my own
> > retorical question
> > "what happens with static LSPs if a link goes down".
> >  If any link
> > fails you're sunk.  You could in principle create a
> > second static LSP
> > (a static standby) but with no signaling there is no
> > way to tell the
> > ingress to use it.
> > 
> > Even with a prmary and standby (regardless of
> > whether the primary
> > and/or standby are static or dynamic), occassionally
> > multiple faults
> > occur for which SRLGs do not cover the possibility
> > and where it would
> > be prohibitively expensive to do so.  A examples
> > examples from my
> > experience are power outage in Manhattan during
> > generator maintenance
> > (famous for taking the FAA network down), Amtrak
> > train wreck in NJ
> > (famous for nearly taking out NYC due to damaged
> > fiber on both sides
> > of the track), hurricane brushing NC and VA causing
> > damage and
> > flooding (famous for taking out MAE-E connectivity
> > to Europe during an
> > IETF), extensive flooding in US midwest, earthquake
> > in San Diego,
> > Raritan River bridge failure in NJ, gas main leak in
> > LA forcing CO to
> > cut power, exploding rat in SF power transfer
> > switch, and the list
> > goes on and on.  You can't write SRLGs to cover
> > this.  The only viable
> > solution is to dynamically route.
> > 
> > Some providers talk about using an explicit-path
> > specified at the
> > ingress with a dynamically routed backup (disjoint
> > and either
> > pre-signaled or just pre-computed, or dynamically
> > rerouted after
> > failure).  This does not use static insegments and
> > outsegments, it
> > uses singaled LSPs with configured paths.  Even talk
> > of this approach
> > (explicit primary path) is becoming more rare
> > because when failure
> > occurs and when optimal layout is most needed it
> > often makes sense to
> > allow primaries were not broken by the fault to pick
> > alternate less
> > congested paths.
> > 
> > second retorical question - Why don't IP providers
> > build their
> > backbones out of static routes?  I'm hope we don't
> > get any <gee I
> > don't know why they don't do that IP static routes
> > would seem like a
> > really great idea> responses.
> > 
> > Curtis
> 
> 
> ______________________________________________________________________ 
> Games, Movies, Music & Sports! http://entertainment.yahoo.ca
>

---

From: "Nagarajan, Ramesh (Ramesh)" <[email-masked]>
Date: Mon, 6 May 2002 19:13:20 -0400

Sudheer,

I am taking the liberty of attaching e-mail (on MPLS WG) from Neil Harrison
of BT on the proposal. He has some excellent comments/perspective (among
others) on the 2x BW issue (see his point 1). I share these viewpoints. 
Failure detection/reporting avoidance is only one of the advantages of the
proposal (and highlighted in the context of the discussion on this thread).
There are many other advantages that we can discuss at length.

ramesh.

> > From: Harrison,N,Neil,IKO1 R
> > Sent: 24 April 2002 13:20
> > To: IETF MPLS WG (E-mail)
> > Subject: comments on nagarajan-ccamp-mpls-packet-protection-00.txt
> > 
> > I noted George S asked for comments on
> > nagarajan-ccamp-mpls-packet-protection-00.txt to be taken 
> on the list in his
> > notes of the MPLS WG mtg.....so here are some 1st pass comments:
> > 
> > 1       I noted a criticism in the mtg notes that it uses 
> 2x the BW of one
> > LSP....well yes it is 1+1 so I'd say that's obvious.  
> However, I think we
> > have to place any such criticism of BW efficiency in 
> context.  For example,
> > if I compare it with LDP as a server layer to (say) rfc2547 
> VPNs, then
> > because there is no relationship between a pkt's up-state 
> QoS forwarding
> > treatment and a pkt's survivability requirements (vis-à-vis same or
> > different DS-coded pkts of *any* VPN), operators are forced 
> to over-engineer
> > such networks and *hope* (because there is no assurance) 
> that traffic
> > survives under failures....a factor of 2x over-engineering 
> on some DS
> > classes is not uncommon.
> > 
> > Hence, the point I want to make here is that using BW wisely to
> > reduce/remove a complexity/problem is one thing (which I 
> support), but
> > asking an operator to throw BW at a problem that should not 
> really exist
> > (because the application/problem in question has only been partially
> > defined, eg just the connectivity bit of VPNs) is something 
> else.  So any
> > criticism of BW efficiency only makes sense against the 
> context of the
> > application/problem it is addressing IMO.
> > 
> > 2       I noted in section 6.2 you address the practical 
> issue of carrying
> > the sequence number (if implemented in such a way), and 
> suggest that it sits
> > directly below the shim header (1st 4 octets of payload).  
> This is possible.
> > 2 things spring to mind here:
> > 
> > -       IMO you really need some way to be sure you have correct A-B
> > connectivity....and this includes defects where perhaps 
> another LSP, LSP X
> > say, gets merged unintentionally into the LSP Y between 
> A-B.  In this case
> > you would get some unexpected results looking for a 
> sequence number in such
> > mismerged pkts.  I would therefore recommend you run a 
> periodic data-plane
> > LSP CV OAM flow on each of the LSPs to verify correct 
> connectivity, since
> > these contain unique LSP source identifiers and will detect 
> all defects, not
> > just simple breaks (and if following Y.1711, it will also 
> invoke the correct
> > consequent actions on failure).
> > 
> > -       You will need to configure the LSP sink points to 
> expect LSPs
> > containing sequence numbers.  This can be done manually of 
> course, but you
> > may want to consider some auto signalling config...and I 
> later noted that
> > you have considered this aspect in section 6.4 wrt RSVP 
> say.  A further way
> > to achieve this signalling function could be by the use of 
> special OAM
> > pkts....and its something being considered by those who are 
> working on MPLS
> > OAM in Y.1711 for automatic CV activation/deactivation.
> > 
> > 3       Given that the scheme you are proposing seems to 
> fit where one has a
> > critical LSP connectivity application (like a 
> control/management-channel
> > say), then I think you ought to be running some solid OAM fault
> > detection/handling function on it in any case....I gave one 
> example above
> > wrt mismerging and seeing arbitrary sequence number 
> effects.  Moreover, I
> > noted later you gave an algorithm for processing the sequence number
> > implementation case at the egress that is associated with a 
> sliding window.
> > I would suggest that this needs coupling with defect 
> detection mechanisms in
> > order to make the correct processing decisions.....one 
> obvious cut-off point
> > is when you would consider one of the LSPs to have become 
> 'unavailable'
> > (this is also defined in Y.1711).
> > 

> > 4       Final comment....simple ideas are often the best, 
> and this idea is
> > certainly simple in principle.  I think it could find 
> excellent uses for
> > critical applications.
> > 
> > regards, Neil
> >
> 

> ----------
> From: 	Sudheer Dharanikota[SMTP:[email-masked]]
> Sent: 	Monday, May 06, 2002 6:41 PM
> To: 	Nagarajan, Ramesh (Ramesh)
> Cc: 	Shahram Davari; [email-masked]'; Gary Tam; Ajay Simha; Ron
> Bonica; Brijesh Kumar; [email-masked]; CCAMP WG
> Hi Ramesh:
> "Nagarajan, Ramesh (Ramesh)" wrote:
> 
> > Sudheer, Shahram,
> >
> > I agree. *Fast* failure detection and reporting are challenging issues
> even
> > when we consider physical layer failures (fiber cut etc.,) only. If you
> > throw in soft failures of many kinds it becomes even more challenging.
> > This was one of the motivations, among many others, in developing a
> > restoration scheme/proposal (link below for convenience) which provides
> > broad coverage for many failures without requiring failure detection and
> > reporting. This will work across the recent L2/L1 technologies that you
> > refer to which lack either proper failure detection and/or reporting.
> >
> > ramesh.
> >
> >
> Although I agree that 1+1 mechanisms may solve (to be precise avoid)
> such problems, they are very resource intensive. Also most of the
> data applications do not need the recovery times that you can support
> by 1+1. In my opinion, the challenge is to support less resource intensive
> but reasinably faster restoration times for data applications by reusing
> the under-lying technologies.
> 
> Regards,
> 
> sudheer
> 
> >
> >
> > > From:         Sudheer Dharanikota[SMTP:[email-masked]]
> > > Sent:         Monday, May 06, 2002 5:27 PM
> > > To:   Shahram Davari
> > > Cc:   [email-masked]'; Gary Tam; Ajay Simha; Ron Bonica;
> Brijesh
> > > Kumar; [email-masked]; CCAMP WG
> > > Shahram Davari wrote:
> > > > Curtis,
> > > > > From: Curtis Villamizar [mailto:[email-masked]]
> > > > > Sent: Monday, May 06, 2002 4:31 PM
> > > > > To: Sudheer Dharanikota
> > > > > Cc: Gary Tam; Ajay Simha; [email-masked]; Ron Bonica;
> Brijesh
> > > > > Kumar; 'Curtis Villamizar '; [email-masked]; CCAMP WG
> > > > > In message <[email-masked]>, Sudheer Dharanikota
> writes:
> > > > > >
> > > > > > Transport networks are *built* to provide 50 msec recovery
> > > > > > times (e.g., rings, span, 1+1 etc). Hence a failures are
> > > > > scoped to be
> > > > > > within a domain (typically a ring or a span or in the worst case
> > > > > > end-to-end[1+1 case]).  Excluding failure detection time in this
> > > > > > 50 msec (taking from SONET knowledge), failure reporting
> > > > > > and recovery should take 50 msec. Obviously this cannot
> > > > > >  be done with OSS intervention. One can use SONET's
> > > > > > inband signaling mechanisms for failure reporting or use
> > > > > > *directed notification* mechanisms such as the ones proposed
> > > > > > for signaling protocols. Note that if we assume a ring topology
> then
> > > > > > the messages are only one hop away (with the assumption that
> > > > > > only the DCS are the intelligent devices). So your worry of 5-10
> > > > > > hop path is not valid in my opinion.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > sudheer
> > > > >
> > > > >
> > > > > The discussion was about MPLS but an underlying assumption seemded
> to
> > > > > enter into the thread with that last email that either APS was
> running
> > > > > under MPLS or L2 was the application and APS was running over MPLS
> > > > > provided over multiple end to end L2 tunnels.
> > > > >
> > > > > I don't know of anyone doing SONET APS over the L2 tunnels of an
> MPLS
> > > > > backbone.
> > > > >
> > > > > I do know of providers who want to eliminate the APS on the sonet
> > > > > links under their MPLS network cutting some costs significantly
> (but
> > > > > with all things considered, not in half).
> > > >
> > > > What mechanism will they use to detect the failure then?
> > >
> > > With most of the *recent* L2/L1 technologies, failure dection is not
> the
> > > only problem.
> > > Without APS-like mechanisms (sub-second) failure reporting is also a
> major
> > > problem.
> > > In my opinion, for the sake of the underlying technologies which does
> not
> > > have
> > > APS-like reporting mechanisms, we need to optimize our signaling
> protocols
> > > and propose sensible control plane topologies.
> > >
> > > Regards,
> > >
> > > sudheer
> > >
> > > >
> > > >
> > > > -Shahram
> > > >
> > > >   MPLS restoration needs to
> > > > > work quite well to do this and still meet SLAs and carrying L2
> service
> > > > > is even more demanding.
> > > > >
> > > > > Curtis
> > > > >
> > >
> > >
>

---

From: [email-masked]
Date: Tue, 7 May 2002 13:45:57 +0100

Ajay Simha wrote 06 May 2002 16:28
> GT> Besides,
> GT>it will be too slow and costly to do protection with
> GT>RSVP-signaling - ie 50ms protection. Even if you scale
> 
> Not true.
> GT>the RSVP/LDP Hello intervals to 5ms, there are lots of
> GT>issues such as link flapping, lots of hellos. etc.
> GT>
NH=> What is not true here?  If you set too fast a prot-sw trigger as you go
up the network stack and closer to applications you are going to fire this
on error events where it should be firing.  And which applications actually
need a sub-50ms prot-sw action anyway?  50ms is in SDH/Sonet because 'it was
as fast as possible on such rings at that time'.....it was not driven by any
applications, just the technology/physics.  To chase this goal higher up the
network stack without understanding *why* you are doing this is sheer folly.
> 
> You could use sonet alarms for detection. Any how would OAM 
> control flow
> solve any lost pkts?
NH=> I'm getting a bit worried by this 'let's rely on L1 OAM for everything'
statement that seems to occur frequently.  SDH/Sonet does detect failures in
(and below) these layers because those who designed these protocols thought
about these problems in the 1st place.  However, there are differences
whether we are talking STM, VC4 or VC11/12 signals say, eg a failure of a
VC11/12 signal does *not* necessarily assume its parent VC4 (or lower STM)
trails are affected.  The higher layers get told of lower level defects
because the lower layer trail termination points inject a Forward Defect
Indicator (FDI) towards those higher layers.....these higher layers do *not*
see specific/individual raw L1 defects, eg LOL, LOF, etc....they see a
generic FDI.  Why?  Well, there is very sound practical reason we do this,
and that is to stop an explosion of higher layer alarms, ie incoming FDI
means *don't* raise alarms here even though your signal has failed because
the real failure is lower and elsewhere....possible even in a different
country!  However, you can, and sometimes must, act on these failures in the
higher layer, eg stop QoS counting if you reach a point of unavailability
(assuming you have defined this) or trigger prot-sw if the lower layer has
not recovered in time T.

The reason you need OAM mechanisms in all layer networks is that there can
be failures in layer network X that are only relevant to layer network X and
are not seen by lower layer network Y say.  So if you get a failure in a FR,
ATM or MPLS network then SDH/Sonet OAM tools won't help you a bit....you
have to detect the failure within the relevent (ie lowest level) trail that
is affected and raise an alarms at its trail term point, and you should
inject FDI into its clinet layers to suppress alarms being raised at those
trail term points as I noted earlier....this behaviour is recursive.

Of course, detecting a failure won't 'solve any lost pkts' as you note, but
if you don't detect the failure in the 1st place how are you going to invoke
prot-sw as a corrective action?  BTW the answer is not necessarily to rely
on the OAM 'hello' mechanisms built-in to control-plane protocols like
RSVP-TE (signalling) or an IGP (routing) because:
-	in some technologies these use different data-planes (more obvious
for cct-sw technologies than pkt-sw technologies, eg OTNs say....but still
true in both cases in princple)
-	in all cases they use different nodal processing components
And in respect of the latter point, even when we assume very close coupling
of traffic/control-plane data-planes we can still have failures of the
traffic data-plane whilst the control-plane protocols think everthing is
still fine.....this is why LSP-Ping was drafted as one solution to this
problem, and why a more generic solution has been developed in Y.1711.
  
<snipped to end NH>

---

From: Shahram Davari <[email-masked]>
Date: Tue, 7 May 2002 11:28:48 -0700

What is the physical architecture? Is it still a ring? a single ring?

-Shahram

> Sent: Monday, May 06, 2002 8:46 PM
> To: Shahram Davari
> Cc: [email-masked]'; Sudheer Dharanikota; Gary Tam; 
> Ajay Simha;
> Ron Bonica; Brijesh Kumar; [email-masked]; CCAMP WG
> <[email-masked]
> > > 
> > > links under their MPLS network cutting some costs 
> significantly (but
> SONET framing is still used.  What is not used is a SONET protect
> path.  SONET is involved in the detection, but plays no role in the
> recovery.  It seems a few providers did buildouts in recent years
> costing lots of money, and used SONET protect paths while there was
> excess capacity.  Not the most efficient, but it works great.  Then as
> the capacity filled but revenue had not yet met the demands of incured
> debt, decided that they don't want the increased debt of a further
> buildout and are seeking a more cost effective way to meet their SLAs.
> 
> Curtis
>

---

From: Shahram Davari <[email-masked]>
Date: Tue, 7 May 2002 14:50:57 -0700

As another example customers could be assigned a fix label, and be multiplexed 
to the same access link, The PE could use the label to differentiate between them.
No need to run LDP in customer CE.

-Shahram

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, May 07, 2002 8:46 AM
> To: [email-masked]
> Cc: [email-masked]
> Sounds very reasonable to me Gary.  I mean LSPs supporting 
> VPNs should not
> be changing very often should they?.....they will usually be 
> long-holding
> and ought to be decoupled from any arbitrary routing changes 
> (or indeed any
> control-plane misbehaviour) by design.
> 
> regards, Neil
> 
> > From: Gary Tam [mailto:[email-masked]]
> > Sent: 06 May 2002 15:00
> > Thanks all, 
> > I think I get my answer that Cisco is not supporting
> > static LSP configuration. 
> > 
> > Oh well, ... 
> > 
> > Don't you think static LSP will be useful for L2 VPN
> > in stitching two access domains together. In most
> > case, the L2 Access network does not have to support
> > any of the complicated signaling procotocls, but still
> > enjoy the benifit of utilizing MPLS. See the following
> > example: 
> > 
> >    (Access1) 1 - 2 (Core) 3 - 4 (Access2)
> > 
> > In this example, the network operator needs only to
> > setup the L2 FEC at ingress LSP, assign and maintain
> > labels on 1,2,3,&4 as to setup the static LSP between
> > the two access doamins and the core network. 
> > 
> > In the core network ( between port 2 and 3), it can be
> > nested LSP trunking setup by CR-LDP/RSVP-TE. This will
> > not change anything in case of failure between 2 and 3
> > Martini-encapsulated Tunnel for some L2 VLAN/MPLS VCs

---

From: Shahram Davari <[email-masked]>
Date: Tue, 7 May 2002 14:54:34 -0700

Some one at Cisco told me that there is a way to do it in Cisco CLI,
but it will be officially supported in future.

-Shahram

---

From: Shahram Davari <[email-masked]>
Date: Tue, 7 May 2002 15:00:41 -0700

Why not? Imagine this example that I gave in another email:

Customers could be assigned a fix label, and be multiplexed 
to the same access link, The PE could use the label to differentiate between them.
No need to run LDP in customer CE.

-Shahram

> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: Monday, May 06, 2002 9:56 AM
> To: Shahram Davari
> Cc: 'Sukanta ganguly'; Ron Bonica; Brijesh Kumar; 'Curtis 
> Villamizar ';
> 'Ajay Simha '; [email-masked]; 'gary tam '; [email-masked]

---

From: [email-masked]
Date: Wed, 8 May 2002 20:20:29 +0100

Curtis Villamizar wrote 08 May 2002 19:12
> In message 
> <[email-masked]>, nei
> [email-masked] writes:
> > be changing very often should they?.....they will usually 
> be long-holding
> > and ought to be decoupled from any arbitrary routing 
> changes (or indeed any
> When a fiber gets chopped or a laser goes dead the LSP should affected
> as little as possible, with the path change as transparent as possible
> to the end user.  That is different from disallowing path change.  By
> decoupled, I'm hoping you mean that path changes due to failure should
> be expected to occur (and very rapidly) and should be transparent.
> 
> Curtis
NH=> Yes I agree with that Curtis.  What we don't want however is for VPN
topologies (ie the trails that compose these) to be flapping about just
because some routing protocol thinks it has a better way from getting from A
to B.  Nor do we want the VPN topologies to be affected if there is a
control-plane failure/misbehaviour (be it a signalling or routing
protocol)......the data-plane in VPNs here needs to be pretty solidly
decoupled from any such instances IMO.  It therefore follows that the
data-plane LSPs of such VPN constructs need to be (i) control-plane agnostic
(inc case of none, if need be) and (ii) fault-managed independently of the
signalling/routing protocol in force (inc none).  There is also the issue of
'performance independence/isolation' per VPN to consider.  Now if I
extrapolate/extend that requirement into what that means for things like LDP
LSPs and rfc2547 VPNs I have some concerns here.  In the former case, I
can't get survivability and QoS isolation between VPNs (assuming
like-DS-class merging across VPN populations) and in the latter case I have
a potential common-mode failure mechanism across all VPNs.   Neither of
these seem like good engineering practices.....even if the solutions are
'elegant' in their own right (purely from connectivity considerations....but
this is not enought IMO).

regards, Neil