The MPLS WG Archive

[Bora Akyol <bora@cisco.com>]

I think what has been said so far is that at every hop, the LSRs at
least need to check whether the ERO has changed. If loose hops are
involved then the LSR needs to either do a second route lookup or TED
calculation  and
make sure that the best route to the next hop is still the same.

You may want to review Kireeti's draft on TE route calculation. I
haven't been paying attention to the list for a while so I am not sure
if the draft is still current.

Bora

Apratim Mukherjee <ApratimM@netbrahma.com> writes:

> A doubt regarding this  given inline...
> 
> Thanks
> Apratim
> > ----------
> > From: 	David Charlap[SMTP:David.Charlap@marconi.com]
> > Sent: 	Friday, October 05, 2001 1:25 AM
> > To: 	mpls@UU.NET
> > Subject: 	Re: RSVP-TE ERO Processing
> > 
> > Girish Bhat wrote:
> > > 
> > > I don't think the ERO needs to be processed with every refresh.
> > > When the ERO changes, the source node creates a new path message
> > > with the same session id but a different lsp id. Note that path
> > > refreshes are sent along the old path with the old lsp id till the
> > > new path gets established. Once the resv message comes back along
> > > the new path, the old path is torn.
> > 
> > You've just described make-before-break.  This is the way ingress nodes
> > are supposed to do the rerouting.
> > 
> > But a transit router should not assume that it will work this way. 
> > There may be broken routers out there.  You still must be prepared to
> > handle the case where the ERO changes, even if your switch isn't capable
> > of anything more than generating a PathErr.
> > 
> > If the ERO changes, you should assume that the ingress node changed it
> > 
> Apratim : >>> Why is it that we are concerned only about when we recieve a
> changed ERO ? Even in the other case , where the ERO object has not changed
> , I think processing of the ERO should still be done as the second hop might
> be a loosely routed hop . In which case the path to the loosely routed hop
> could definitely change at run-time . Or it could be the same case if the
> second object is a AS No or an abstract node . How can we assume that the
> route stays the same as when we recieved the ERO for the first time although
> the ERO has the same contents ? 
> 
> > for a reason and that this is not some weird manifestation of line
> > noise.  To ignore the change and continue sending out Path messages to
> > the old next-hop with the old ERO is broken behavior.
> > 
> > -- David
> >