Subject: RE: RSVP Refresh Reduction question

From: "Reddy, Vikram" <[email-masked]>
Date: Thu, 26 Sep 2002 08:51:33 -0400

Hi George,

Then, maybe the wording in the RFC should specify this. According to the
current wording, this is not explicitly mentioned. Also, the interpretation
of
"willing to receive" is from the RFC.

From Section 2
         0x01: Refresh (overhead) reduction capable

           When set, indicates that this node is willing and capable of
           receiving all the messages and objects described in this
           document.  This includes the Bundle message described in
           Section 3, the MESSAGE_ID objects and Ack messages described
           in Section 4, and the MESSAGE_ID LIST objects and Srefresh
           message described in Section 5.  This bit is meaningful only
           between RSVP neighbors.

Thanks,
Vikram.

-----Original Message-----
From: George Swallow [mailto:[email-masked]]
Sent: Thursday, September 26, 2002 5:35 PM
To: Reddy, Vikram
Cc: 'David Charlap'; IETF MPLS List; [email-masked]
Subject: Re: RSVP Refresh Reduction question 

Reddy -

I don't like the idea of using the bit to mean "willing to receive".
For a properly compliant implementation, if you want to send then you
MUST set the bit and MUST be willing to receive.  If (for reasons that
I haven't imagined yet) you want to just receive, then just set the
bit and don't send.

As far as dealing with a *non-compliant* implementation, I completely
agree with Curtis.

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: "Pan, Ping" <[email-masked]>
Date: Thu, 26 Sep 2002 14:12:33 -0700

Hi,

Actually, having this bit in RSVP message head is a questionable design 
in the first place.

During the design of graceful restart, we invented this capability 
object that is used in RSVP Hello's. One day, Jonathan Lang in a private 
email told me that we should have put all refresh reduction features in 
this capability object. At the time, I was just hoping he won't make me 
to put them in LMP. ;-) But come to think of it, we should have 
advertised the feature capability information via Hello. After all, this 
is only useful among RSVP neighbors.

But, having said that, it's all too late to change. The code has been 
deployed; the feature has been used. Developers can figure out the 
operation details eventually. IMHO, IETF drafts and RFC's are meant to 
describe what's on the wire. Running code is all that matters. Let's 
move on.

Regards,

- Ping