The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] RSVP-TE ERO Processing
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 >
|
|