Re: Static LSP Configuration

[Sudheer Dharanikota <sudheer@nayna.com>]

Hi Gary:


Gary Tam wrote:

> 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.
>
> --- Ajay Simha <asimha@cisco.com> 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:
> >
> > 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><curtis@workhorse.fictitious.org> wrote:
> > GT>>
> > GT>> In message
> > GT>>
> >
> GT><20020506135949.87793.qmail@web11208.mail.yahoo.com>,
> > 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>
> >
> > --
> >
>
> ______________________________________________________________________
> Games, Movies, Music & Sports! http://entertainment.yahoo.ca