The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <561621C69F17D511A3A20050047340EC01AAF614@VCMD-NT1>, "Ferrell, Willi
am" writes:
>  
> 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


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


> -----Original Message-----
> From: Curtis Villamizar
> To: Ferrell, William
> Cc: 'Steve Yao '; ''curtis@fictitious.org' '; '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: 'curtis@fictitious.org'
> > 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>> 
> > 
>