Re: [CCAMP] Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

[Lou Berger <[e-mail]>]

Rakesh,
	Speaking as WG participant, I haven't thought about this too much so
may be off, but method 3 seems to be most consistent with the usage of
the REVERSE_LSP Object in the path message.  Perhaps consider using the
REVERSE_LSP Object in the upstream/Resv direction to allow the
egress/tail to provide the ingress/head with arbitrary information....

Lou

On 9/11/2012 9:22 AM, Rakesh Gandhi (rgandhi) wrote:
> Hi WG,
> 
> Any thoughts on the following proposal?
> 
> Thanks,
> Rakesh
> 
> 
> -----Original Message-----
> From: Rakesh Gandhi (rgandhi) 
> Sent: Tuesday, September 04, 2012 1:36 PM
> To: 'Lou Berger'
> Cc: [e-mail]; [e-mail]
> Subject: RE: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
> 
> 
> Thanks Lou for your reply.
> 
> RFC 3473 defines procedures for NOTIFY request and reply. We could use this for reverse LSP signaling error notification to the initiating ingress node.
> 
> <Notify message> ::= <Common Header> [<INTEGRITY>] [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
> <ERROR_SPEC>   
> <notify session list ::= <upstream session> <downstream session>  >
> 
> There are multiple ways we can use the NOTIFY message.
> 
> Method 1 - Mid-point aware with Path message request:
> When an egress node receives a Path message with REVERSE_LSP object, the node will insert NOTIFY_REQ message in the reverse LSP path message with node ID of the initiating ingress node. A mid-point node will send  a copy of the signaling error to the initiating node using the NOTIFY message.
> 
> IPv4 Notify Request Object
>    IPv4 Notify Node Address: 32 bits
>       The IP address of the node that should be notified when generating an error message.
> 
> Method 2 - Mid-point aware with Resv message request:
> When an initiating ingress node receives a Path message for a reverse LSP, the node will insert NOTIFY_REQ message in the reverse LSP Resv message with its own node ID. A mid-point node will send a copy of the signaling error to the initiating node using the NOTIFY message.
> 
> Method 3 - Tail-end relaying :
> When an egress node receives a Path message with REVERSE_LSP object, the node will relay the received signaling error message on the reverse LSP to the initializing ingress node. The egress node copies the received "ERROR_SPEC" object into a NOTIFY [RFC3473, section 4.3] message and signals it to the ingress node. In this case, NOTIFY_REQ message is not required. 
> 
> Please advise your thoughts.
> 
> Thanks,
> Rakesh
> 
> 
> 
> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]] 
> Sent: Tuesday, September 04, 2012 11:35 AM
> To: Rakesh Gandhi (rgandhi)
> Cc: [e-mail]; [e-mail]
> Subject: Re: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
> 
> As I read the current rev, no such notification mechanism is specified.
>  Looks like you get to propose one!
> 
> Lou (as WG participant).
> 
> On 8/31/2012 9:49 AM, Rakesh Gandhi (rgandhi) wrote:
>> Hi Lou, Fei,
>>
>> When an (originating) ingress node is provisioned with "5 (TBD)  Single Sided Associated Bidirectional LSPs  (A)" and wishes to control both forward and reverse  LSPs by adding "REVERSE_LSP" object, I would think that the ingress node needs to know about the signaling (path) errors (such as soft preemption or admission failure) on the reverse LSP.  Is there any text somewhere in an RFC/draft that describes how a mid-point node can send the signaling (path) error to the originating ingress node for the reverse LSP? Is there an assumption to use RSVP_NOTIFY message? Sorry if I had missed any previous discussion on this topic.
>>
>> Thanks,
>> Rakesh
>>
>>
>>
>>
>>
> 
> 
> 
>