Subject: RE: Static LSP Configuration

From: Brijesh Kumar <[email-masked]>
Date: Sat, 4 May 2002 18:03:14 -0700

Curtis,

I am kind of curious why won't you think that static LSP may be used as a
tool for simple manual traffic engineering within a small portion of the
network?

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 

-----Original Message-----
From: Curtis Villamizar
To: Ajay Simha
Cc: [email-masked]; gary tam; [email-masked]
Sent: 04/05/02 1:27 PM
Subject: Re: Static LSP Configuration 

In message
<[email-masked]>, Ajay
 Simha writes:
> 
> I think static labels based LSPs will become a nightmare to manage in
a
> production size network. I have had a few customers ask for it but
without a
> really good reason.
> 
> The only time it may actually be useful (IMHO) is an some InterAS VPNs
where
> the two providers don't want to actually exchange label (whether one
consider
> s
> it safe or not).

In the last case you mentioned here, there are clearly better ways to
do this.  I've also seen this same request and that was among the
"wierd requests 2-3 years ago" that I think have gone away.  I think
that particular request is only slightly more alive than features
needed for Enron's bandwidth brokering.

Regardless of whether this is a credible customer request, there is a
better way, LDP just works across AS and for TE use simple loose hops
from the ingress.  It will require some authentication at the inter-AS
borders if this is interprovider and it would help to implement the AS
hop type in RSVP.  If we are talking about inter-AS within a provider,
there is already someone doing that running MPLS/TE in each AS and
LDP/VPN across AS inside TE and I'm confident they wouldn't consider
static LSPs even for a moment, nor are they interested in doing a
single TE hop through both AS.  Plus each AS has IGP areas.

btw- retorical question - with static LSPs, what happens when a link
goes down?

Curtis

---

From: Ajay Simha <[email-masked]>
Date: Sun, 5 May 2002 11:14:20 -0400 (EDT)

On Sat, 4 May 2002, Brijesh Kumar wrote:

BK>
BK>Curtis,
BK>
BK>I am kind of curious why won't you think that static LSP may be used as a
BK>tool for simple manual traffic engineering within a small portion of the
BK>network?

Brijesh,

This would work great in a lab environment where things don't change.
In any production network, how are you going to keep track of which labels go
which way? Why not build a network using static routes instead?

Static label like static routes may lead to forwarding loops with the
slightest misconfiguration.

-ajay
BK>
BK>Also, on your:
BK>>>btw- retorical question - with static LSPs, what happens when a link
BK>goes down?
BK>
BK>Should the expected behaviour  need to be any different than when someone
BK>routes with static routes?
BK>
BK>Cheers,
BK>
BK>--brijesh
BK>
BK>
BK>
BK>
BK>
BK>-----Original Message-----
BK>From: Curtis Villamizar
BK>To: Ajay Simha
BK>Cc: [email-masked]; gary tam; [email-masked]
BK>Sent: 04/05/02 1:27 PM
BK>Subject: Re: Static LSP Configuration
BK>
BK>
BK>In message
BK><[email-masked]>, Ajay
BK> Simha writes:
BK>>
BK>> I think static labels based LSPs will become a nightmare to manage in
BK>a
BK>> production size network. I have had a few customers ask for it but
BK>without a
BK>> really good reason.
BK>>
BK>> The only time it may actually be useful (IMHO) is an some InterAS VPNs
BK>where
BK>> the two providers don't want to actually exchange label (whether one
BK>consider
BK>> s
BK>> it safe or not).
BK>
BK>
BK>In the last case you mentioned here, there are clearly better ways to
BK>do this.  I've also seen this same request and that was among the
BK>"wierd requests 2-3 years ago" that I think have gone away.  I think
BK>that particular request is only slightly more alive than features
BK>needed for Enron's bandwidth brokering.
BK>
BK>Regardless of whether this is a credible customer request, there is a
BK>better way, LDP just works across AS and for TE use simple loose hops
BK>from the ingress.  It will require some authentication at the inter-AS
BK>borders if this is interprovider and it would help to implement the AS
BK>hop type in RSVP.  If we are talking about inter-AS within a provider,
BK>there is already someone doing that running MPLS/TE in each AS and
BK>LDP/VPN across AS inside TE and I'm confident they wouldn't consider
BK>static LSPs even for a moment, nor are they interested in doing a
BK>single TE hop through both AS.  Plus each AS has IGP areas.
BK>
BK>btw- retorical question - with static LSPs, what happens when a link
BK>goes down?
BK>
BK>Curtis
BK>

--

---

From: Ron Bonica <[email-masked]>
Date: Sun, 05 May 2002 11:49:04 -0400

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

---

From: Sukanta ganguly <[email-masked]>
Date: Sun, 5 May 2002 10:42:40 -0700 (PDT)

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

> forward the traffic. See RFC 3031 Sections 3.18 and

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

---

From: Gary Tam <[email-masked]>
Date: Mon, 6 May 2002 09:59:49 -0400 (EDT)

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
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

> forward the traffic. See RFC 3031 Sections 3.18 and

______________________________________________________________________ 
Games, Movies, Music & Sports! http://entertainment.yahoo.ca

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 06 May 2002 10:25:45 -0400

Gary,

         FYI, this mailing list is not for discussion of vendor-
specific issues. Please keep that offline or on mplsops.

         --Tom

> > forward the traffic. See RFC 3031 Sections 3.18 and

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

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 06 May 2002 10:46:06 -0400

In message <[email-masked]>, Gary Tam write

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

---

From: Gary Tam <[email-masked]>
Date: Mon, 6 May 2002 11:20:57 -0400 (EDT)

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
> In message
<[email-masked]>,
> Gary Tam write

---

From: Ajay Simha <[email-masked]>
Date: Mon, 6 May 2002 11:28:09 -0400 (EDT)

On Mon, 6 May 2002, Gary Tam wrote:

GT>Hi Curtis,
GT>
GT>You have some good points. I agree with you that
GT>dynamic signaling is good and essential.
GT>
GT>But for protection, you do not have to have dynamic
GT>signaling protocol. You need 2 disjointed LSPs, and a
GT>fast fault detection / propagation mechanism (could be
GT>an OAM control flow or other means for the targeted
GT>DA). In this case, when there is a link/fiber cut, the
GT>failure can be detected at where the fault occurs and
GT>be propagated to where the switch takes place. In
GT>terms of global/segmented protection, the local-node
GT>detects the failure instantly and propagates failure
GT>condition to the targeted DA of the switch node. The
GT>switch-node performs the switch-over activity as soon
GT>as it gets the switch-over message. In the entire
GT>proceess, there is no dynamic signaling here. 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>

You could use sonet alarms for detection. Any how would OAM control flow
solve any lost pkts?

-ajay
GT>In the Access domain, ie 802.1Q, VLAN/SVLAN is widely
GT>used for data forwarding and customer data separation.
GT>There is no urgent need for an Ethernet network to
GT>implement RSVP-TE or CR-LDP. So static LSP-Stitching
GT>will be a cheap and inexpensive solution for L2 VPN.
GT>
GT>Gary
GT>
GT>
GT>--- Curtis Villamizar
GT><[email-masked]> wrote:
GT>>
GT>> In message
GT>>
GT><[email-masked]>,
GT>> Gary Tam write
GT>> s:
GT>> >
GT>> > In the core network ( between port 2 and 3), it
GT>> can be
GT>> > nested LSP trunking setup by CR-LDP/RSVP-TE. This
GT>> will
GT>> > not change anything in case of failure between 2
GT>> and 3
GT>> > with the obvious exception of port 2 and 3.
GT>> >
GT>> > The static LSP (1,2,3,4) will likely be
GT>> > Martini-encapsulated Tunnel for some L2 VLAN/MPLS
GT>> VCs
GT>> > as well. The L2 FEC can be either MAC DA, VLAN,
GT>> > Coustomer ID, and ATM VC, etc.
GT>> >
GT>> > Gary
GT>>
GT>>
GT>> Gary,
GT>>
GT>> I didn't think I was going to have to answer my own
GT>> retorical question
GT>> "what happens with static LSPs if a link goes down".
GT>>  If any link
GT>> fails you're sunk.  You could in principle create a
GT>> second static LSP
GT>> (a static standby) but with no signaling there is no
GT>> way to tell the
GT>> ingress to use it.
GT>>
GT>> Even with a prmary and standby (regardless of
GT>> whether the primary
GT>> and/or standby are static or dynamic), occassionally
GT>> multiple faults
GT>> occur for which SRLGs do not cover the possibility
GT>> and where it would
GT>> be prohibitively expensive to do so.  A examples
GT>> examples from my
GT>> experience are power outage in Manhattan during
GT>> generator maintenance
GT>> (famous for taking the FAA network down), Amtrak
GT>> train wreck in NJ
GT>> (famous for nearly taking out NYC due to damaged
GT>> fiber on both sides
GT>> of the track), hurricane brushing NC and VA causing
GT>> damage and
GT>> flooding (famous for taking out MAE-E connectivity
GT>> to Europe during an
GT>> IETF), extensive flooding in US midwest, earthquake
GT>> in San Diego,
GT>> Raritan River bridge failure in NJ, gas main leak in
GT>> LA forcing CO to
GT>> cut power, exploding rat in SF power transfer
GT>> switch, and the list
GT>> goes on and on.  You can't write SRLGs to cover
GT>> this.  The only viable
GT>> solution is to dynamically route.
GT>>
GT>> Some providers talk about using an explicit-path
GT>> specified at the
GT>> ingress with a dynamically routed backup (disjoint
GT>> and either
GT>> pre-signaled or just pre-computed, or dynamically
GT>> rerouted after
GT>> failure).  This does not use static insegments and
GT>> outsegments, it
GT>> uses singaled LSPs with configured paths.  Even talk
GT>> of this approach
GT>> (explicit primary path) is becoming more rare
GT>> because when failure
GT>> occurs and when optimal layout is most needed it
GT>> often makes sense to
GT>> allow primaries were not broken by the fault to pick
GT>> alternate less
GT>> congested paths.
GT>>
GT>> second retorical question - Why don't IP providers
GT>> build their
GT>> backbones out of static routes?  I'm hope we don't
GT>> get any <gee I
GT>> don't know why they don't do that IP static routes
GT>> would seem like a
GT>> really great idea> responses.
GT>>
GT>> Curtis
GT>
GT>
GT>______________________________________________________________________
GT>Games, Movies, Music & Sports! http://entertainment.yahoo.ca
GT>

--

---

From: Gary Tam <[email-masked]>
Date: Mon, 6 May 2002 11:42:18 -0400 (EDT)

yes, you can rely on the Physical Optical driver to
monitor the incoming signal/power level, and/or
synchornization (using PLL/CDR). But without a fast
propagation mechanism, you cannot archieve sub 50ms
global protection. I do not see how you can do it with
RSVP or LDP over 5-10 hop path.

---

From: Ajay Simha <[email-masked]>
Date: Mon, 6 May 2002 11:47:48 -0400 (EDT)

GT>yes, you can rely on the Physical Optical driver to
GT>monitor the incoming signal/power level, and/or
GT>synchornization (using PLL/CDR). But without a fast
GT>propagation mechanism, you cannot archieve sub 50ms
GT>global protection. I do not see how you can do it with
GT>RSVP or LDP over 5-10 hop path.

One could argue that with Global protection the number of LSPs that you'd have
in the network increases so much so that static LSPs would no longer be an
option.

With Local Protection as specified in
draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt draft you can achieve ~ 50ms
protection.

Also RSVP hellos are link-local.

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

--

---

From: Gary Tam <[email-masked]>
Date: Mon, 6 May 2002 11:56:05 -0400 (EDT)

Actually in the example I was given previously, there
were always four hops in the path:

   (Access1) P1 - P2 (core) P3 - P4 (Access2) primarly

In this case, so you can 

> GT>> GT>> switch, and the list
=== message truncated ===

---

From: Gary Tam <[email-masked]>
Date: Mon, 6 May 2002 12:05:00 -0400 (EDT)

(Access1) P1 - P2 (core) P3 - P4 (Access2) primarly
 (Access1) P1 - P2'(core) P3'- P4 (Access2) backup1 or
 (Access1) P1'- P2'(core) P3'- P4 (Access2) backup2

In this case, MPLS is just as an aggregation
technology and static LSP is not that bad.

Note: in the core, it is signaled nested trunk LSP
between P2-P3 or P2'-P3'.

---

From: Sudheer Dharanikota <[email-masked]>
Date: Mon, 06 May 2002 10:58:20 -0700

Hi Gary:

Gary Tam wrote:

> > On Mon, 6 May 2002, Gary

I thought the discussion was about data networks. This
suddenly became transport network discusion :-) As you
have noted, there are multiple phases in recovery here.

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

> Tam wrote:

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 06 May 2002 16:31:11 -0400

> hop path is not valid in my opinion.

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).  MPLS restoration needs to
work quite well to do this and still meet SLAs and carrying L2 service
is even more demanding.

Curtis