The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] RSVP HOP on PathErr
*> *> Bob, *> *> As I mentioned, we're dealing with a distributed implementation and we're *> trying to minimize the amount of replicated state information. The PathErr *> as well as all other messages that flow towards the origin have to be *> transferred from the egress card to the correct ingress card, and having a *> separate mechanism for PathErr is a nuisance. *> *> Thanks, *> *> John *> I am not fundamentally hostile to adding HOP to PathErr if there is a good reason, but I interpret your comment above as an implementation problem in a particular organization of the router hardware. Did I misinterpret? Such considerations aside, I see NO separate mechanism; the PathErr is routed upstream just as Resv messages are routed upstream. Bob Braden *> -----Original Message----- *> From: Bob Braden [mailto:braden@ISI.EDU] *> Sent: Tuesday, September 19, 2000 8:44 AM *> To: lberger@labn.net; AF@dataconnection.com; John Drake *> Cc: swallow@cisco.com; petera@nortelnetworks.com; mpls@UU.NET; *> braden@ISI.EDU *> Subject: RE: RSVP HOP on PathErr *> *> *> *> *> From jdrake@calient.net Tue Sep 19 08:13:33 2000 *> *> From: John Drake <jdrake@calient.net> *> *> To: "'Lou Berger'" <lberger@labn.net>, Adrian Farrel *> <AF@dataconnection.com> *> *> Cc: swallow@cisco.com, petera@nortelnetworks.com, mpls@UU.NET, *> braden@ISI.EDU *> *> Subject: RE: RSVP HOP on PathErr *> *> Date: Tue, 19 Sep 2000 08:13:22 -0700 *> *> MIME-Version: 1.0 *> *> X-Mailer: Internet Mail Service (5.5.2650.21) *> *> X-Lines: 61 *> *> *> *> Lou, *> *> *> *> I think the point is that since PathErr doesn't have HOP, it doesn't *> have *> *> the LIH information. This means that a node has to have another *> mechanism, *> *> like Session ID, to get PathErr to the correct ingress interface, and *> this *> *> is extra work and complexity, paticularly in a distributed *> implementation. *> *> *> *> Thanks, *> *> *> *> John *> *> Why doesn't the path state tell you the correct incoming interface? *> You should have path state at all nodes upstream of the failure. *> *> Bob Braden *> *> *> *> *> -----Original Message----- *> *> From: Lou Berger [mailto:lberger@labn.net] *> *> Sent: Tuesday, September 19, 2000 3:34 AM *> *> To: Adrian Farrel *> *> Cc: swallow@cisco.com; petera@nortelnetworks.com; mpls@UU.NET; *> *> braden@isi.edu *> *> Subject: Re: RSVP HOP on PathErr *> *> *> *> *> *> Adrian, *> *> *> *> I don't see the need for this change, particularly since there are no *> *> non-RSVP hops with RSVP-TE. *> *> *> *> In an abstract sense having HOP in PathErr is no big deal, but the call *> was *> *> made not to include it when the protocol was specified in RFC2205. I *> don't *> *> think we should make changes in the base protocol just because of *> *> aesthetics. *> *> *> *> What case do see where you can't "get back to the same interface" on *> *> receipt of a PathErr? *> *> *> *> Lou *> *> *> *> At 04:45 AM 9/19/00, Adrian Farrel wrote: *> *> >Hi, *> *> > *> *> >Here's a bit of controversy for you! *> *> > *> *> >I just polled the RSVP list to see if anyone recalled why PathErr does *> not *> *> >carry RSVP HOP. Bob Braden helpfully replied that it was left out *> because *> *> >it was not needed (reasonable enough!). *> *> > *> *> >Can I suggest that it now has its uses in MPLS, especially GMPLS where *> a *> *> >reservation may already have been made on the forward path (i.e. when *> the *> *> >Path message was processed) and it is necessary to get back to the *> same *> *> >interface (identified by the LIH) when the PathErr is received. *> *> > *> *> >Would either of you, for this reason or for symmetry, be prepared to *> put *> *> >RSVP HOP on PathErr in your drafts (rsvp-lsp-tunnel or *> *> >generalized-signaling)? *> *> > *> *> >Regards, *> *> >Adrian *> *> >-- *> *> >Adrian Farrel mailto:af@datcon.co.uk *> *> >Network Convergence Group *> *> >Data Connection Ltd., Chester, UK *> *> >http://www.datcon.co.uk/ *> *> >Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 *> *> *> |
|