Subject: RE: Between OSPF RSVP...

From: "Ferrell, William" <[email-masked]>
Date: Mon, 17 Mar 2003 11:49:18 -0500

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

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

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

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 17 Mar 2003 12:46:22 -0500

In message <561621C69F17D511A3A20050047340EC01AAF614@VCMD-NT1>, "Ferrell, Willi
> numeric improbability, right.

More accurately, if the risk an incomplete RRO the is complete
eliminated by using implementations that are not broken and avoiding
certain network designs.  If the risk is not having the tear down
occur in one of those network designs (ie: inter-area LSPs without
hierarchical LSPs, or where an ABR goes down or is isolated from one
area), then path-tear and directed notify provide an alternate means
to notify the ingress that a reroute is needed.  Path-tear and
directed notify suffer performance degredation if a single path-tear
or notify packet is lost but preferred treatment of control traffic
should solve this.

All problems that have been discussed so far are solved problems.

Curtis