Subject: RE: Refresh Reduction

From: Manoj Agiwal <[email-masked]>
Date: Fri, 8 Feb 2002 17:51:43 +0530

Hi  Ben ,
   Summary refresh message format is

   The Srefresh message format is:

   <Srefresh Message> ::= <Common Header> [ <INTEGRITY> ]
                         [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
                         [ <MESSAGE_ID> ]
                         <srefresh list> | <source srefresh list>

   <srefresh list> ::= <MESSAGE_ID LIST> | <MESSAGE_ID MCAST_LIST>
                         [ <srefresh list> ]

   <source srefresh list> ::= <MESSAGE_ID SRC_LIST>
                                [ <source srefresh list> ]

What I think you are talking about is Message ID which one receives in
MESSAGE_ID LIST .
What I wanted to know was the use of MESSAGE_ID  in 

   <Srefresh Message> ::= <Common Header> [ <INTEGRITY> ]
                         [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
                         [ <MESSAGE_ID> ]
                         <srefresh list> | <source srefresh list>
Regards ,
Manoj

> ----------
> From: 	[email-masked][SMTP:[email-masked]]
> Sent: 	Friday, February 08, 2002 5:17 PM
> To: 	Manoj Agiwal
> Cc: 	[email-masked]'; [email-masked]'
> Subject: 	Re: Refresh Reduction
> 
> 
> Hello Manoj,
> 
> The Srefresh message is used to refresh Resv state and Path state of the
> LSP tunnels.  This is accomplished by referencing the Path and Resv
> messages by their associated MESSAGE_ID objects.
> 
> I would suggest processing these objects to maintain state.  If a
> MESSAGE_ID object stops appearing in a Srefresh message I think that it
> should be timed out and the LSP torn down.
> 
> Please let me know if I am wrong.
> 
> Thanks,
> -Ben
> 
> On Fri, 8 Feb 2002, Manoj Agiwal wrote:
> 
> > Hi ,
> >     Why there is a Message ID Object in the SRefresh message .
> >  Will there be any processing based on this message ID .
> > Regards ,
> > Manoj
> >
> >
>

---

From: [email-masked]
Date: Fri, 8 Feb 2002 08:00:03 -0500 (EST)

Hello Manoj,

My apologies for misunderstanding your initial question.  There are two
possibilities here:

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).

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.

Please let me know your thoughts on this.

Thanks,
-Ben

---

From: David Charlap <[email-masked]>
Date: Fri, 08 Feb 2002 11:21:46 -0500

[email-masked] wrote:
> 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

---

From: Suresh Katukam <[email-masked]>
Date: Fri, 08 Feb 2002 10:29:33 -0800

David,

I agree with you. But at the same time it is an optional object.
Regular Srefresh messages do not need MESSAGE_ID object.
If we were to insert MESSAGE_ID with ACK desired bit set in all Srefresh,
then there is no need to wait for K updates before determining
a LSP is down.

I would really think the usage of MESSAGE_ID is valid only
when you do RESTART procedure using Srefresh message. When
a control channel fails and comes back up, you want to make sure
that the other guy received your Srefresh message. For this,
you will have to add MESSAGE_ID object with ACK_DESIRED
bit set.

Thanks,
Suresh