The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Oct> msg00145



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

RSVP-TE ERO Processing

  • From: Apratim Mukherjee <ApratimM@netbrahma.com>
  • Date: Wed, 10 Oct 2001 12:45:50 +0530

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
>