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

From: dimitri papadimitriou <[email-masked]>
Date: Thu, 26 Jul 2007 17:49:11 +0200

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 ?

thanks,
-d.

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 26 Jul 2007 11:04:01 -0500

Hi Dimitri,

> 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

---

From: dimitri papadimitriou <[email-masked]>
Date: Thu, 26 Jul 2007 21:49:30 +0200

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

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

o) implication of the above two points is that the receiver is also not 
able to include its own Notify Request object, 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:
> 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.
>>
>>
>>
>>
>>
>>
> 
> .
>