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

["Rakesh Gandhi (rgandhi)" <[e-mail]>]

Hi Fei,

I see what you are saying. Rewording the text to reflect this (not sure about “SHOULD” word usage):

When an initiating ingress node is provisioned with "Single Sided Associated Bidirectional LSPs" and wishes to control both forward and reverse LSPs by adding "REVERSE_LSP" object, the ingress node SHOULD know the signaling (path) errors on the reverse LSP. Transit and egress nodes SHOULD be requested to notify the signaling error on the reverse LSP by using the NOTIFY message and procedures defined in RFC[3473].


Thanks,
Rakesh


From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, September 12, 2012 9:40 PM
To: Rakesh Gandhi (rgandhi)
Cc: [e-mail]; Lou Berger
Subject: RE: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt


Hi Rekesh, Lou

 >          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....

<fei>Well, I can see one of the advantages of this proposal is that it allows the policy control in the egress/tail, where a decision can be made that whether the signaling error should be passed to the ingress/head. But it changes the rules defined in RFC3473....

     The other proposal keeps alignment with RFC3473, and I prefer it if the LSP control is totally in hand of the ingress/head (in other words, there is no more information needs the egres/tail to inform the ingress/head).

"Rakesh Gandhi (rgandhi)" <[e-mail]<mailto:[e-mail]>>

2012-09-13 08:53

收件人

"[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>

抄送

"[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Lou Berger <[e-mail]<mailto:[e-mail]>>

主题

RE: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt







Hi Fei,

Please see inline..<RG>..

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]<mailto:[mailto:[e-mail]]>
Sent: Wednesday, September 12, 2012 8:42 PM
To: Rakesh Gandhi (rgandhi)
Cc: [e-mail]<mailto:[e-mail]>; Lou Berger
Subject: RE: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt


Hi Rakesh

In the absence of such notification request, egress node SHOULD relay the received signaling error on the reverse LSP to the ingress node using the NOTIFY message."

<fei> "Note that a Notify message MUST NOT be generated unless an appropriate Notify Request object has been received."

      If my understanding is correct, your proposed relay mechanism does not depend on the existing of the Notify Request object, which may conflict with the
      descripitons in RFC3473.

      Do you want to change this or do I have some misunderstanding?

<RG> Yes your understanding is correct.  NOTIFY message in this case is generated based on the presence of the “REVERSE_LSP” object and association type “Single Sided Associated Bidirectional LSPs.  I understand what you are saying though. FYI,  Lou had following thoughts on this. Do you think this simplifies things ?
>          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....

Thanks,
Rakesh



Regards

Fei
"Rakesh Gandhi (rgandhi)" <[e-mail]<mailto:[e-mail]>>

2012-09-13 01:23


收件人

Lou Berger <[e-mail]<mailto:[e-mail]>>

抄送

"[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>

主题

RE: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt











Hi Lou, Fei, WG,

Thanks for your replies. May I propose following text to cover this case? This allows the mid-point solution which has advantages but given the additional complexity can be optional.

Please advise.

"When an initiating ingress node is provisioned with "Single Sided Associated Bidirectional LSPs" and wishes to control both forward and reverse  LSPs by adding "REVERSE_LSP" object, the ingress node SHOULD know the signaling (path) errors on the reverse LSP.  A transit node MAY be requested to notify the signaling error on the reverse LSP by using the NOTIFY message and procedures defined in RFC[3473]. In the absence of such notification request, egress node SHOULD relay the received signaling error on the reverse LSP to the ingress node using the NOTIFY message."

Thanks,
Rakesh


-----Original Message-----
From: Lou Berger [mailto:[e-mail]]<mailto:[mailto:[e-mail]]>
Sent: Wednesday, September 12, 2012 12:14 PM
To: Rakesh Gandhi (rgandhi)
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Rakesh,


On 9/12/2012 11:52 AM, Rakesh Gandhi (rgandhi) wrote:
> Thanks Lou.
>
> Are we ok in general to use NOTIFY message [RFC3473] for this?

I'm not speaking for the WG, as noted my comments were as a participant.
IMO you'll need to fully document the proposal, perhaps discuss alternatives considered, and then ask the WG for concurrence.

>
> One advantage with the mid-point sending notification for the reverse
> LSP is that signaling error propagation time
> (mid->egress-node->ingress-node) is significantly reduced (to
> mid->ingress-node) which may be preferred in some cases.

From my (personal) perspective, the added complexity isn't worth the effort.  Of course, a detailed proposal may show otherwise.

Lou

>
> Thanks,
> Rakesh
>
>
> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]<mailto:[mailto:[e-mail]]>
> Sent: Wednesday, September 12, 2012 9:15 AM
> To: Rakesh Gandhi (rgandhi)
> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> Subject: Re: Question on LSP control in
> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>
> 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]<mailto:[e-mail]>; [e-mail]<mailto:[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]]<mailto:[mailto:[e-mail]]>
>> Sent: Tuesday, September 04, 2012 11:35 AM
>> To: Rakesh Gandhi (rgandhi)
>> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
>