RE: Notify Message Doubt

["George Young" <george.young@meriton.com>]

Hello Manoj,

The path restoration application I described is where my (company's) interests lie. This possible application is identified in Section 2 of draft-ietf-mpls-generalized-signaling-08.txt.

Others may have other uses for the RSVP NOTIFY message, either after or during generalized LSP establishment.

Regards,
George R. Young
Meriton Networks Inc.
3026 Solandt Rd., Ottawa, ON, Canada, K2K 2A5
phone: +1 613-270-9279 Ext 287
fax: +1 613-270-9628
email: george.young@meriton.com


>-----Original Message-----
>From: manoj juneja [mailto:manojkumarjuneja@hotmail.com]
>Sent: Wednesday, May 22, 2002 1:54 PM
>To: George Young
>Cc: ccamp@ops.ietf.org
>Subject: RE: Notify Message Doubt
>
>
>Hi George,
>           If this is the only reason then does this mean that Notify 
>Message has a significance only after the primary LSP is 
>established  and 
>this message can't be used during the primary LSP estblishment/setup.
>
>Regards,
>manoj.
>
>>From: "George Young" <george.young@meriton.com>
>>To: "manoj juneja" <manojkumarjuneja@hotmail.com>
>>CC: <ccamp@ops.ietf.org>
>>Subject: RE: Notify Message Doubt
>>Date: Wed, 22 May 2002 09:30:32 -0400
>>
>>Hello Manoj,
>>
>>Path restoration (i.e. switching over to an existing back-up 
>path at the 
>>head and the tail) is one mechanism for quick optical protection.
>>
>>I think the RSVP NOTIFY message is a suitable mechanism to 
>trigger path 
>>restoration. Then RSVP messages (e.g. PathTEAR) can be used 
>to take down 
>>the broken path.
>>
>>Regards,
>>George R. Young
>>Meriton Networks Inc.
>>3026 Solandt Rd., Ottawa, ON, Canada, K2K 2A5
>>phone: +1 613-270-9279 Ext 287
>>fax: +1 613-270-9628
>>email: george.young@meriton.com
>>
>> >-----Original Message-----
>> >From: manoj juneja [mailto:manojkumarjuneja@hotmail.com]
>> >Sent: Tuesday, May 21, 2002 6:52 PM
>> >To: ccamp@ops.ietf.org
>> >Subject: Notify Message Doubt
>> >
>> >
>> >Hi All,
>> >        It is mentioned in drft
>> >draft-ietf-mpls-generalized-rsvp-te-07.txt
>> >(sec. 4.3) that Notify Message provides a mechanism to inform
>> >non-adjacent
>> >nodes of LSP related events.
>> >
>> >I think the generation of PathErr or ResvErr at a node will
>> >also trigger the
>> >generation of Notify message to the notify address as received
>> >in Path or
>> >Resv Message. What will the end node need to do when it
>> >receives the notify
>> >message prior to path/resv err ?
>> >
>> >What will the advantage of sending Notify message to the end
>> >node before it
>> >receives path/resv err ?
>> >
>> >Please help me in understanding its advantage/significance in
>> >the optical
>> >domain.
>> >
>> >Regards,
>> >manoj.
>> >
>> >_________________________________________________________________
>> >MSN Photos is the easiest way to share and print your photos:
>> >http://photos.msn.com/support/worldwide.aspx
>> >
>> >
>> >
>
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at 
>http://explorer.msn.com/intl.asp.
>
>