Subject: RE: Re: Between OSPF RSVP...

From: Jean Philippe Vasseur <[email-masked]>
Date: Wed, 12 Mar 2003 18:02:00 -0500

Hi,

At 15:25 12/03/2003 -0500, Nair, Girish (Girish) wrote:
>Giovanni,
>
>I agree. Link down LSP rerouting can be done a little more efficiently
>using the IGP. This has been done in some proprietary signaling
>implementations
>and works well. It involves tighter coupling between the IGP and signaling
>though.

You do not need any proprietary signalling protocol here.

JP.

>Girish
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Wednesday, March 12, 2003 3:13 PM
>To: mpls
>Subject: Re:Re: Between OSPF RSVP...
>
>
>Hi Curtis hi all,
>essentially my considerations are: if i have two pre-calculated disjoint
>backup paths and i use opaque LSA to flood the link failure information,
>it could be a reasonable faster  way of proceeding instead of using RSVP if
>i have an intelligence in the source routers (routers have to be able to
>switch among the two LSPs if they receive that particular opaque LSA; note
>that for a restoration of many LSPs RSVP will work in series, but OSPF will
>work in parallel with its flooding mechanism).
>So the basic question is: is it a reasonable way the use of OSPF  and opaque
>LSA? Is there a reason to the use always RSVP for path protection, since, i
>think, increasing the LSPs corrupted by one link failure (if there are many
>active LSPs on the link that goes down) the OSPF mechanism of flooding is
>more efficient than using many RSVP messages from node that detects the
>failure towards the LSPs senders?
>
>Thanks in advance for your kind answers and observations.
>
>Giovanni Di Giacomo
>
>
>In message <[email-masked]>,
>"john151@libero
>.it" writes:
> > Hi all,
> > I' m interesting in protection/restoration (P/R) mechanisms and after
>having
> > read some works, i' d like to do some observations.
> > In a TE path protection scenario, there are works dealing with the use of
>RSV
> > P-TE messages to signal, in  example,
> > a link failure.
> > But could it have sense this other way of recovery?
> > ...After a detection of a failure, OSPF ( OSPF-TE ) uses the flooding
>mechani
> > sm to advertise the all network that one link is broken
> > ( ... using opaque LSA? ); then all nodes, receiving the LSA with this
>inform
> > ation, could compute an analysis of what LSPs ( LSP having source in that
>nod
> > e ) are interested by the failure. Then, in example, each node that wants
>to
> > do restoration in a MPLS scenario could make a Label Switching if there is
>a
> > Backup Path available.
> > This approach has some problem:
> > -   a faster trigger on OSPF in detecting failure, since HELLO mechanism
>is s
> > low;
> > -   the prioriting of the sequence ---flooding LSA---  and  then
>---computing
> >  SPF algorithm--- to do faster;
> > -   the adding of intelligence in each node to do the Switching.
> >
> > I know that these are only some observations containing ( i hope few )
>errors
> >  and that aren't complete, but since i haven' t found any P/R mechanisms
>in a
> >  TE scenario using OSPF ( or any optimized version of this ), i' d like to
>ma
> > ke you a question:
> > is this a possible way of study ( as an alternative to RSVP signalling )
>or i
> > s completely wrong and out of all standards?
> >
> > Thanks in advance for your kind answers and observations.
> >
> > Giovanni Di Giacomo
>
>
>OSPF/TE already uses the SONET framing detection to trigger fast
>flooding of link down.  This is a FAQ.
>
>Ingress then quickly find any affected LSPs (the quickly part is an
>implementation detail, but reasonable implementations don't do a
>search of all LSPs but rather have this information already available
>as a data structure hung off the TE-LSDB entry for the link).
>
>Presignaled disjoint backup LSPs from the ingress are known as
>"standby" LSP and are implemented by most LSR as an alternate to FRR.
>In practice, standby LSP provide anywhere from sub second to a few
>second restoration AFAIK.  Otherwise the ingress must resignal the
>affected LSPs on new paths.  This is supposed to take just a few
>seconds but in practice if a lot of LSPs are affected most LSR seem to
>fall back to IP forwarding and get the LSPs up in 10s of seconds.
>Implementations are improving and getting this to consistently a few
>seconds, even for large topologies and large numbers of affected LSPs
>is being discussed elsewhere usually referred to as the "fast
>convergence" problem.
>
>LDP makes direct use of the OSPF derived next-hop.
>
>Curtis

---

From: Steve Yao <[email-masked]>
Date: Mon, 17 Mar 2003 11:17:37 -0600

Hi Will,

Whether an RRO can fit into a Path/Resv message is dependent on a
combination of various factors including, for example, large private
objects. However, at this point, it appears that the likelihood of such a
scenario is low.

Steve

>From: Ferrell, William [mailto:[email-masked]]
>Sent: Monday, March 17, 2003 10:49 AM
>To: 'Curtis Villamizar '; Ferrell, William
>Cc: ''Steve Yao ' '; ''mpls ' '
>Subject: RE: Between OSPF RSVP... 
>
>
> 
>Steve
>Yes , you hit the nail on the head .. That was the "this"
>In essence we're saying that risk is mititaged through 
>effective design and
>numeric improbability, right.
>Will
>
>From: Curtis Villamizar
>To: Ferrell, William
>Cc: 'Steve Yao '; [email-masked]' '; 'mpls '
>Sent: 3/17/03 10:37 AM
>Subject: Re: Between OSPF RSVP... 
>
>
>In message <561621C69F17D511A3A20050047340EC01AAF610@VCMD-NT1>,
>"Ferrell, Willi
>am" writes:
>>  
>> Steve 
>> 
>> I ask a simple question or two. 
>> 1. how detrimental could this be to our MPLS implementation and 
>> 2. What should we do to mitigate the risk ?
>> Will
>
>
>Will,
>
>What is "this" in your question?  If it partially filled RRO, we
>determined it not occur except for certain conditions that are
>entirely a matter of network design (such as interarea).  We also
>concluded that even if the RRO was partially filled, the path-tear and
>notify (if used) would handle tear down and initiate reroute.
>
>Please be more specific in your question, if I haven't answered it.
>
>Curtis
>
>
>
>> From: Steve Yao
>> To: [email-masked]'
>> Cc: mpls
>> Sent: 3/14/03 12:51 PM
>> Subject: RE: Between OSPF RSVP... 
>> 
>> 
>> 
>> >Steve,
>> >
>> >In two messages prior you stated:
>> >
>> >> The RRO received at the HE only contains the IP addresses 
>> >that map to half
>> >> of the LSAs or LSPs that the LSP traversed. 
>> >
>> >You mentioned that only half the LSA/LSPDU were in the RRO, so the
>> >question "What cases were you thinking of?" that you just asked
>should
>> >be directed to you.
>> 
>> I asked the question since you mentioned earlier:
>> 
>> >It wasn't intended to cover all cases and does not depricate use of
>> >path-tear.  You still didn't answer my question.
>> 
>> But it is ok if you don't want to answer the question.
>> 
>> >
>> >Since you brought up the issue "where RRO may be too large" 
>why don't
>> >you do the math and tell us 1) how big the RRO would have 
>to be to be
>> >too large and 2) how likely you think that is of occurring.  RSVPd
>> >objects can be 64KB each.  The IPv4 address subobject is 8 bytes
>long,
>> >including type and length.  Add a label subobject (8 bytes) and fit
>it
>> >into a reasonable MTU and you're still at hundreds of hops.  I get
>> >200+ into a 4KB MTU and most networks seem to be going for 8K MTU so
>I
>> >get "not very likely" for question 2).
>> >
>> >Curtis
>> >
>> 
>> I agree that this is not very likely.
>> 
>> Steve
>>  <<ATT77972.txt>> 
>> 
>

----------------------------------------- (on Chiaro SMTP Relay)

This e-mail and any files transmitted with it are the property
of Chiaro Networks, Ltd., and may contain confidential and 
privileged material for the sole use of the intended recipient(s)
to whom this e-mail is addressed. If you are not one of the named
recipient(s), or otherwise have reason to believe that you have 
received this message in error, please notify the sender and 
delete all copies from your system.  Any other use, retention, 
dissemination, forwarding, printing or copying of this e-mail is 
strictly prohibited.

---------------------------------------------------------

---

From: "Ferrell, William" <[email-masked]>
Date: Mon, 17 Mar 2003 15:38:07 -0500

Steve 
Thanx, I tend to look at matters from a pesimistic perspective at times. My
questions are rarely about the operational likelihood and randomly
accidental factors(unless mis-configuration comes into view) but often I
focus on the malicious and intentional. Then the questions turn to loss
factor and mitigation.
Sorry for bugging you guys . 

Will

-----Original Message-----
From: Steve Yao
To: 'Ferrell, William'; 'Curtis Villamizar '
Cc: Steve Yao; ''mpls ' '
Sent: 3/17/03 12:17 PM
Subject: RE: Between OSPF RSVP... 

Hi Will,

Whether an RRO can fit into a Path/Resv message is dependent on a
combination of various factors including, for example, large private
objects. However, at this point, it appears that the likelihood of such
a
scenario is low.

Steve

>> I agree that this is not very likely.
 <<ATT01329.txt>>