Subject: RE: RSVP-TE ERO Processing

From: "Feng, Mark" <[email-masked]>
Date: Tue, 2 Oct 2001 11:19:06 -0700

IMO, this is implementation dependant. Personally, I wouldn't want to
process the ERO each time if there is no change in the ERO. Since the
receiver node won't know whether the message is simply a refresh message
unless it does some kind of check of the message, (1) and (2) are somehow
the same question.

Hope this helps.

- Mark

> -----Original Message-----
> From: Khuzema Pithewan [mailto:[email-masked]]
> Sent: Tuesday, October 02, 2001 5:13 AM
> Cc: [email-masked]
> Subject: RSVP-TE ERO Processing
> 
> 
> Hi,
> 
> I have  few question related to ERO Processing...
> 
> 1. Does ERO Processing done each time when Intermediate node receives
> Path Refresh?
> 2. If Not, then what it should do, when there is a change in 
> ERO object
> received in this Path Refresh than the ERO Object received in earlier
> Path Messages..
> 
> Thanks,
> Khuzema.
>

---

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

> ----------
> From: 	Vishal Mishra[SMTP:[email-masked]]
> Sent: 	Friday, October 05, 2001 11:24 PM
> To: 	Khuzema Pithewan
> Cc: 	[email-masked]
> Subject: 	Re: RSVP-TE ERO Processing
> 
> ERO Processing is done only when the newly arrived ERObject is
> different from the stored ERObject.
> 
> Vishal.
> 
> --- Khuzema Pithewan <[email-masked]> wrote:
> > Hi,
> > 
> > 2. If Not, then what it should do, when there is a change in ERO
> > object
> __________________________________________________
> Do You Yahoo!?
> NEW from Yahoo! GeoCities - quick and easy web site hosting, just
> $8.95/month.
> http://geocities.yahoo.com/ps/info1
>

---

From: Apratim Mukherjee <[email-masked]>
Date: Fri, 12 Oct 2001 04:07:01 -0400

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]
> 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
>