The MPLS WG Archive

["Pan, Ping" <ppan@ciena.com>]

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

Reddy, Vikram wrote:
> 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:swallow@cisco.com]
> Sent: Thursday, September 26, 2002 5:35 PM
> To: Reddy, Vikram
> Cc: 'David Charlap'; IETF MPLS List; swallow@cisco.com
> 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