The MPLS WG Archive

[David Charlap <David.Charlap@marconi.com>]

schultz@io.iol.unh.edu wrote:
> 
> 1. Although not explicitly stated, it seems as if you could have a
> MESSAGE_ID object pointing to an entire Srefresh message.  Hence one
> Srefresh message could reference several other Srefresh messages,
> that in turn would reference several Path and Resv states.  The
> standard places no limit on this behavior (from what I can see).

I would be surprised if this would be considered valid.  Especially
considering the section you quote in your next paragraph:

> 2. In section 5.3: "Only state that was previously advertised in
> Path and Resv messages containing MESSAGE_ID objects can be
> refreshed via an Srefresh message."  If you interpret this to mean
> "directly refreshed via an Srefresh message", then this solves the
> problem and the MESSAGE_ID is not used.  However, I suspect that one
> could argue that the state was previously advertised before it was
> placed in the Srefresh message.

As you quoted, SRefresh only refreshes Path and Resv state.  Other kinds
of messages (including SRefresh) do not establish state, and therefore
can not be refreshed via SRefresh.  Your idea about a hierarchy of
SRefresh messages would imply a system where SRefresh messages may
establish state on a router, and this is simply not true.

The only good reason for including a MESSAGE_ID in an SRefresh message
is if you want to request acknowledgement for it.  If the ack_desired
flag is set in the MESSAGE_ID, then the SRefresh will be resent
(according to the exponential backoff algorithm) until an ack is
received for it.

If an SRefresh has a MESSAGE_ID where the ack_desired flag is not set,
then the MESSAGE_ID serves no purpose.

-- David