Subject: Re: [Tsvwg] question on draft-ietf-tsvwg-rsvp-proxy-proto-01.txt

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 11 Oct 2007 15:24:57 +0200

Hi Dimitri,

I'm working on the updated version of rsvp-proxy-proto and looking at  
your comments below:

On 26 Jul 2007, at 21:49, dimitri papadimitriou wrote:

> hi francois,
>
>
> indeed but more precisely what deserves imho clarification is
>
> o) since you are reflecting the Notify request object value from  
> the incoming Notify request object in the Path message, the Notify  
> msg sent to the source is the one associated to the Resv
>
> hence that notify includes the following information
>
> <downstream notify session> ::= <SESSION> [<POLICY_DATA>...]
>                                 <flow descriptor list>
>
> sent now upstream towards the sender

Right. The text of new rev will include:

"As a result, as per existing Notify procedures, if an RSVP router
    detects an error relating to a Resv state (e.g.  Admission Control
    rejection after IP reroute), the RSVP router will send a Notify
    message (conveying the Resv Err code) to the IP address contained in
    the Resv Notify Request object.  Since this address has been set to
    the sender's address by the Receiver Proxy, the Notify message is
    sent to the sender.
"

thus in particular:
"if an RSVP router detects an error relating to a Resv state ..., the  
RSVP router will send a Notify
    message (conveying the Resv Err code)"

So it should be clear that "Notify msg sent to the source is the one  
associated to the Resv".

>
> o) there is apparently no need to generate notify on PathErr (the  
> notify request object transported in the Path msg is only there to  
> be reflected in the Resv msg) while as indicated in the extracts  
> the RFC 3473 refers to a SHOULD

We don't intend to modify the existing RFC3473 behavior on  
intermediate nodes. In fact, as a result of the discussions with  
Adrian and John, the new version will include the following statement:
"This section discusses aspects of the use of the Notify message that  
are specific to the RSVP Receiver Proxy. In any other aspects, the  
Notify message operates as per RFC3473"

As a result, Notify may (or actually as you point out "SHOULD") be  
generated as a result of Path state errors. Note that, in our  
environment with a REceiver Proxy, this is likely to be of value to  
the sender anyways.

>
> o) implication of the above two points is that the receiver is also  
> not able to include its own Notify Request object,

The reason we have an RSVP Receiver Proxy in the first place is  
because the receiver is not RSVP capable.
So there doesn't seem to be an issue here.

Thanks

Francois

> indeed RFC 3473 mentions
> "If a message contains multiple Notify_Request objects, only the first
> object is meaningful."
>
>
> i think this would facilitate code re-use and prevent interop issues.
>
> (as examples i have seen some implementations injecting a Notify  
> Request object but not able to Ack (when requested) towards a  
> destination or simply not able to process the Error node address in  
> the error spec objecy)
>
> thanks,
> -d.
>
> Francois Le Faucheur IMAP wrote:
>> Hi Dimitri,
>> On 26 Jul 2007, at 10:49, dimitri papadimitriou wrote:
>>> this version includes use of the notify message:
>>>
>>> RFC 3473 states
>>>
>>> "The Notify message does not replace existing error messages."
>>>
>>> [..]
>>>
>>> "Notify messages are most commonly generated at nodes that detect
>>> an error that will trigger the generation of a PathErr or ResvErr
>>> message."
>>>
>>> which in practice means "Notify messages" are generated when
>>> conditions stated in RFC 3473 are met but do not replace the
>>> generation of error messages as stated in the same reference
>>>
>>> "If a PathErr message is to be generated and a Notify
>>> Request object has been received in the corresponding Path message,
>>> then a Notify message destined to the recorded node SHOULD be
>>> generated. If a ResvErr message is to be generated and a Notify
>>> Request object has been received in the corresponding Resv message,
>>> then a Notify message destined to the recorded node SHOULD be
>>> generated. "
>>>
>>> -> question:
>>>
>>> could authors clarify Fig.4/scenario of the proxy-proto ?
>> The scenario and use of Notify is illustrated in Fig 4 and  
>> described in the text of section 3.2 (above Fig 4).
>> I believe the operation described there is consistent with the  
>> text you quoted above.
>> Cheers
>> Francois
>>>
>>> thanks,
>>> -d.
>>>
>>>
>>>
>>>
>>>
>>>
>> .