The MPLS WG Archive

[Sean Crocker <crockers@trinicom.com>]

>This is mandatory behavior.
>
>This algorithm is described in RFC 2205.  In there, RSVP is supposed to
>respond to a non-RSVP router by setting the "adspec break" bit in the
>ADSPEC object.  This way, the egress router will know that the Path went
>through a non-RSVP router, and that QoS reservations can not be
>guaranteed.
>
>In RSVP-TE, the PathErr for non-MPLS router was invented because MPLS
>itself can't work if one or more node along the LSP doesn't participate
>in the signaling.

David,

I agree with you that this is mandatory.  However, quoting section 4.2.5 of the RSVP-TE
draft:


   RSVP is designed to cope gracefully with non-RSVP routers anywhere
   between senders and receivers. However, obviously, non-RSVP routers
   cannot convey labels via RSVP. This means that if a router has a
   neighbor that is known to not be RSVP capable, the router MUST NOT
   advertise the LABEL_REQUEST object when sending messages that pass
   through the non-RSVP routers.  The router SHOULD send a PathErr back
   to the sender, with the error code "Routing problem" and the error
   value "MPLS being negotiated, but a non-RSVP capable router stands in
   the path."  This same message SHOULD be sent, if a router receives a
   LABEL_REQUEST object in a message from a non-RSVP capable router. See
   [1] for a description of how a downstream router can determine the
   presence of non-RSVP routers.

So I'm assuming the last sentence is a reference to the algorithm in the last paragraph of
RFC2205 section 3.8.  However, that reference seems to partially dismiss this (at least to
me it appears that way):

      With normal IP forwarding, RSVP can detect a non-RSVP hop by
      comparing the IP TTL with which a Path message is sent to the TTL
      with which it is received; for this purpose, the transmission TTL
      is placed in the common header.  However, the TTL is not always a
      reliable indicator of non-RSVP hops, and other means must
      sometimes be used.  

I'm thinking that if this is the best way to detect a non-RSVP upstream neighbor, then
perhaps the RSVP-TE draft should be reworded to explicitly include this mechanism to
prevent confusion.

Sean

>
>-- David






---------------------------------------
This message was sent by www.trinicom.com Webmail.