The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] RFC3209 Section 4.1.2
Hong Liao wrote: > > In RFC3209 Section 4.21.2 non-support of the label object. > > 4.1.2. Non-support of the Label Object > > Under normal circumstances, a node should never receive a LABEL > object in a Resv message unless it had included a LABEL_REQUEST > object in the corresponding Path message. However, an RSVP router > that does not recognize the LABEL object sends a ResvErr with the > error code "Unknown object class" toward the receiver. This causes > the reservation to fail. > > For example, > > A -------LSR--------B > > If the A sent out a Path msg without the LRO, LSR will forward this path > msg to B, then if B sent a Resv msg with a Label object, will the LSR send > the Resverr msg with the error code "Unknown object class" toward B? If A didn't send a LABEL_REQUEST, and B sent back a LABEL anyway, then B is broken. No LSP can possibly come up, because A wasn't trying to establish one in the first place. It is absolutely correct for A to generate a ResvErr. > I do think so unless LSR is non-support the LABEL object. If A generated a Path without a LABEL_REQUEST, then either it is not running RSVP-TE (meaning the LABEL object definitely isn't supported), or it is a hybrid router, running both classical RSVP and RSVP-TE at once. If it is such a hybrid, then the decision of what to do with an unexpected LABEL object is not specified. Personally, I think the ResvErr should still be generated, since that's what a non-TE router would do for the exact same session. -- David
|
|