Subject: RE: RSVP-TE ERO Processing

From: Apratim Mukherjee <[email-masked]>
Date: Wed, 10 Oct 2001 12:45:50 +0530

A doubt regarding this  given inline...

Thanks
Apratim
> ----------
> From: 	David Charlap[SMTP:[email-masked]]
> Sent: 	Friday, October 05, 2001 1:25 AM
> To: 	[email-masked]
> 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
>

---

From: Bora Akyol <[email-masked]>
Date: 10 Oct 2001 08:01:55 -0700

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

---

From: David Charlap <[email-masked]>
Date: Thu, 11 Oct 2001 11:07:57 -0400

Apratim Mukherjee wrote:
> 
> 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.

If the route to a loose next-hop changes, this should be detected and
handled when the route changes.  The router should not wait for the next
Path refresh to do this work.

This is the same as what happens when there is no ERO and the route to
the egress changes.

The issue of route changes is orthogonal to the issue of ERO changes.

-- David