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

From: [email-masked]
Date: Sun, 2 Sep 2012 10:53:18 +0800

Hi Rakesh

See in line tagged with <fei>

Best regards

Fei

"Rakesh Gandhi (rgandhi)" <[email-masked]> 
2012-08-31 21:49

收件人
Lou Berger <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
Question on LSP control in 
draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

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.

<fei> Please check 
http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04#section-3.2.9 
to see whether we need to add more words here. :)

Thanks,
Rakesh

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Tue, 4 Sep 2012 15:14:43 +0000

Thanks Fei for your reply. Please see inline..<RG>.

From: [email-masked] [mailto:[email-masked]]
Sent: Saturday, September 01, 2012 10:53 PM
To: Rakesh Gandhi (rgandhi)
Cc: [email-masked]; Lou Berger
Subject: Re: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Hi Rakesh

Best regards

Fei

"Rakesh Gandhi (rgandhi)" <[email-masked]<mailto:[email-masked]>>

2012-08-31 21:49

收件人

Lou Berger <[email-masked]<mailto:[email-masked]>>

抄送

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

主题

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

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.

<fei> Please check http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04#section-3.2.9 to see whether we need to add more words here. :)

<RG> What I am referring to is as follows: forward LSP path from A (Ingress) - B – C – D (egress). Reverse LSP path is D – E – F – A. Here node A is the initializing LSP ingress node and controls the path for reverse LSP by adding REVERSE_LSP object. So if there is a path error on the reverse LSP say on link F-E, the path error will be sent to head-end of that LSP which is node D. As path for the reverse LSP is controlled by node A, node A needs to know about this path error so it may compute an alternate path for the reverse LSP. Is there a mechanism somewhere defined for node D to relay this path error to initializing node A?
Thanks,
Rakesh

Thanks,
Rakesh

---

From: Lou Berger <[email-masked]>
Date: Tue, 04 Sep 2012 11:35:14 -0400

As I read the current rev, no such notification mechanism is specified.
 Looks like you get to propose one!

Lou (as WG participant).

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Tue, 4 Sep 2012 17:35:39 +0000

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:[email-masked]] 
Sent: Tuesday, September 04, 2012 11:35 AM
To: Rakesh Gandhi (rgandhi)
Cc: [email-masked]; [email-masked]
Subject: Re: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Lou (as WG participant).

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Tue, 11 Sep 2012 13:22:19 +0000

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: [email-masked]; [email-masked]
Subject: RE: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Thanks,
Rakesh

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Tuesday, September 04, 2012 11:35 AM
To: Rakesh Gandhi (rgandhi)
Cc: [email-masked]; [email-masked]
Subject: Re: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Lou (as WG participant).

---

From: [email-masked]
Date: Wed, 12 Sep 2012 09:43:37 +0800

Hi Rakesh

According to the descriptions in RFC3473, I am afraid both the upstream 
notification and downstream notification are permitted.

Some other issues that need to be discussed are tagged in line with <fei> 

Best regards

Fei

2012-09-11 21:22

收件人
Lou Berger <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
RE: Question on LSP control in 
draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Hi WG,

Thanks,
Rakesh

-----Original Message-----
From: Rakesh Gandhi (rgandhi) 
Sent: Tuesday, September 04, 2012 1:36 PM
To: 'Lou Berger'
Cc: [email-masked]; [email-masked]
Subject: RE: Question on LSP control in 

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

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.

<fei>Ok, can you clarify which session the copied NOTIFY message are 
carrying? the forward session1 or the reverse session2?
 
If it is session1, I am afraid that the NOTIFY_REQ object is also needed 
in the forward LSP Path message ( "Note that a Notify message MUST NOT be 
generated unless an appropriate Notify Request object has been received." 
copied from paragraph 4.3.2 from RFC3473 )
 
 If it is session2, there is no copied 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.

<fei> See above, if it is session2, no copied NOTIFY message also.

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. 

<fei> I am afraid NOTIFY_REQ object is also required in the forward and 
reverse LSP's Path or Resv message, otherwise ,the egress node will not 
realy the error message.

Thanks,
Rakesh

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Tuesday, September 04, 2012 11:35 AM
To: Rakesh Gandhi (rgandhi)
Cc: [email-masked]; [email-masked]
Subject: Re: Question on LSP control in 

Lou (as WG participant).

---

From: Lou Berger <[email-masked]>
Date: Wed, 12 Sep 2012 09:14:49 -0400

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

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Wed, 12 Sep 2012 15:52:23 +0000

Thanks Lou.

Are we ok in general to use NOTIFY message [RFC3473] for this?

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.

Thanks,
Rakesh

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Wednesday, September 12, 2012 9:15 AM
To: Rakesh Gandhi (rgandhi)
Cc: [email-masked]; [email-masked]
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

---

From: Lou Berger <[email-masked]>
Date: Wed, 12 Sep 2012 12:14:05 -0400

Rakesh,

> 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

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Wed, 12 Sep 2012 16:59:30 +0000

Hi Fei,

Thanks for your reply.

Please see inline..<RG>..

Sent: Tuesday, September 11, 2012 9:44 PM

Hi Rakesh

According to the descriptions in RFC3473, I am afraid both the upstream notification and downstream notification are permitted.
<RG> Right. In case of reverse LSP, only downstream notification is required towards the initiating ingress node.

Best regards

Fei

2012-09-11 21:22

收件人

抄送

主题

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

Hi WG,

Thanks,
Rakesh

-----Original Message-----
From: Rakesh Gandhi (rgandhi)
Sent: Tuesday, September 04, 2012 1:36 PM
To: 'Lou Berger'
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

<fei>Ok, can you clarify which session the copied NOTIFY message are carrying? the forward session1 or the reverse session2?
<RG> Reverse LSP - session2.
If it is session1, I am afraid that the NOTIFY_REQ object is also needed in the forward LSP Path message ( "Note that a Notify message MUST NOT be generated unless an appropriate Notify Request object has been received." copied from paragraph 4.3.2 from RFC3473 )

<RG> Not sure if I follow “no copied NOTIFY message”.  When there is a signaling error on a reverse LSP (session 2), a mid-point node automatically sends signaling error towards egress node but it also sends a copy of it towards the initiating ingress node when it had received NOTIFY request message for the reverse LSP (session2).

<fei> See above, if it is session2, no copied NOTIFY message also.
<RG> Please see previous reply.

<fei> I am afraid NOTIFY_REQ object is also required in the forward and reverse LSP's Path or Resv message, otherwise ,the egress node will not realy the error message.
<RG> This would be a simplification, where in the absence of a NOTIFY request message, and presence of the REVERSE_LSP object, egress node relays the received signaling error on the reverse LSP (session 2) to the initiating ingress node.
Thanks,
Rakesh

Thanks,
Rakesh

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Tuesday, September 04, 2012 11:35 AM
To: Rakesh Gandhi (rgandhi)
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Lou (as WG participant).

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Wed, 12 Sep 2012 17:23:55 +0000

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:[email-masked]] 
Sent: Wednesday, September 12, 2012 12:14 PM
To: Rakesh Gandhi (rgandhi)
Cc: [email-masked]; [email-masked]
Subject: Re: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Rakesh,

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.

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

Lou

---

From: [email-masked]
Date: Thu, 13 Sep 2012 08:41:39 +0800

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? 

Regards

Fei

2012-09-13 01:23

收件人

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:[email-masked]] 
Sent: Wednesday, September 12, 2012 12:14 PM
To: Rakesh Gandhi (rgandhi)
Cc: [email-masked]; [email-masked]
Subject: Re: Question on LSP control in 

Rakesh,

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

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Thu, 13 Sep 2012 00:53:07 +0000

Hi Fei,

Sent: Wednesday, September 12, 2012 8:42 PM

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.

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

Thanks,
Rakesh

Regards

Fei

2012-09-13 01:23

收件人

抄送

主题

Hi Lou, Fei, WG,

Please advise.

Thanks,
Rakesh

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

Rakesh,

Lou

---

From: [email-masked]
Date: Thu, 13 Sep 2012 09:39:52 +0800

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

2012-09-13 08:53

收件人
"[email-masked]" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, Lou Berger <[email-masked]>
主题
RE: Question on LSP control in 
draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Hi Fei,

Hi Rakesh 

<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 

收件人
Lou Berger <[email-masked]> 
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" <
[email-masked]> 
主题
RE: Question on LSP control in 
draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Hi Lou, Fei, WG,

Please advise. 

Thanks,
Rakesh

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Wednesday, September 12, 2012 12:14 PM
To: Rakesh Gandhi (rgandhi)
Cc: [email-masked]; [email-masked]
Subject: Re: Question on LSP control in 

Rakesh,

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

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Thu, 13 Sep 2012 01:57:18 +0000

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

Sent: Wednesday, September 12, 2012 9:40 PM

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

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

2012-09-13 08:53

收件人

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

抄送

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Lou Berger <[email-masked]<mailto:[email-masked]>>

主题

Hi Fei,

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

Hi Rakesh

Thanks,
Rakesh

Regards

Fei

2012-09-13 01:23

收件人

抄送

主题

Hi Lou, Fei, WG,

Please advise.

Thanks,
Rakesh

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

Rakesh,

Lou

---

From: Lou Berger <[email-masked]>
Date: Thu, 13 Sep 2012 09:02:17 -0400

Rakesh,
	This seems really complicated.  Why allow for the optional notification
from the egress?  There is precedent for use of notify messages without
notify requests (see RFC4974).

Also, as it stands Associated Bidirectional really only requires support
by the end nodes. (I think of it as almost an application overlay on top
of normal LSP signaling.  I'd even consider using the RFC4974 call
approach if it wasn't for requirement 11 in RFC6373.)  I think placing
processing requirements on transit nodes, such as sending reverse_lsp
notifications adds unnecessary complexity and should be avoided unless
absolutely necessary.

Lou (as participant)

On 9/12/2012 9:57 PM, Rakesh Gandhi (rgandhi) wrote:
> When an initiating ingress node is provisioned with "Single Sided
> 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:[email-masked] [mailto:[email-masked]]
> *Sent:* Wednesday, September 12, 2012 9:40 PM
> *To:* Rakesh Gandhi (rgandhi)
> *Cc:* [email-masked]; Lou Berger
> *Subject:* RE: Question on LSP control in
>  />          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..../
> 
> 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....
> 
> *"Rakesh Gandhi (rgandhi)" <[email-masked] <mailto:[email-masked]>>*
> 
> 2012-09-13 08:53
> 
> 	
> 
> 收件人
> 
> 	
> 
> "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>
> 
> 抄送
> 
> 	
> 
> "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>, Lou Berger <[email-masked]
> <mailto:[email-masked]>>
> 
> 主题
> 
> 	
> 
> *From:[email-masked] <mailto:[email-masked]>
> [mailto:[email-masked]] <mailto:[mailto:[email-masked]]> *
> Sent:* Wednesday, September 12, 2012 8:42 PM*
> To:* Rakesh Gandhi (rgandhi)*
> Cc:* [email-masked] <mailto:[email-masked]>; Lou Berger*
> Subject:* RE: Question on LSP control in
> 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."
> 
> 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
> /
> *"Rakesh Gandhi (rgandhi)" <[email-masked]*
> <mailto:[email-masked]>*>*
> 
> 2012-09-13 01:23
> 
> 	
> 
>  
> 
> 收件人
> 
> 	
> 
> Lou Berger <[email-masked] <mailto:[email-masked]>>
> 
> 抄送
> 
> 	
> 
> "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> 
> 主题
> 
> 	
> 
> 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.
> 
> 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
> 
> 
> <mailto:[mailto:[email-masked]]>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>
>> From: Lou Berger [mailto:[email-masked]] <mailto:[mailto:[email-masked]]>
>> Cc: [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>
>>                  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
>> 
>>> Cc: [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>
>>> From: Lou Berger [mailto:[email-masked]] <mailto:[mailto:[email-masked]]>
>>> Cc: [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>> 
>> 
>> 
>> 
>

---

From: John E Drake <[email-masked]>
Date: Thu, 13 Sep 2012 06:04:14 -0700

As a participant, I agree with Lou.

Yours irrespectively,

John

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Lou Berger
> Sent: Thursday, September 13, 2012 6:02 AM
> Cc: [email-masked]
> Subject: Re: [CCAMP] Question on LSP control in draft-ietf-ccamp-mpls-
> tp-rsvpte-ext-associated-lsp-04.txt
> 
> Rakesh,
> 	This seems really complicated.  Why allow for the optional
> notification from the egress?  There is precedent for use of notify
> messages without notify requests (see RFC4974).
> 
> Also, as it stands Associated Bidirectional really only requires
> support by the end nodes. (I think of it as almost an application
> overlay on top of normal LSP signaling.  I'd even consider using the
> RFC4974 call approach if it wasn't for requirement 11 in RFC6373.)  I
> think placing processing requirements on transit nodes, such as sending
> reverse_lsp notifications adds unnecessary complexity and should be
> avoided unless absolutely necessary.
> 
> Lou (as participant)
> 
> > 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
> >
> >
> >
> >
> >
> > consider using the REVERSE_LSP Object in the upstream/Resv direction
> > to allow the egress/tail to provide the ingress/head with arbitrary
> > information..../
> >
> >      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).
> >
> > [mailto:[email-masked]]
> <mailto:[mailto:[email-masked]]>
> > *
> >       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.
> >
> > <RG> Yes your understanding is correct.  NOTIFY message in this case
> > is generated based on the presence of the “REVERSE_LSP” object and
> > understand what you are saying though. FYI,  Lou had following
> > thoughts on this. Do you think this simplifies things ?
> too
> > 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
> >
> > <[email-masked] <mailto:[email-masked]>>,
> > <mailto:[email-masked]>>
> > case? This allows the mid-point solution which has advantages but
> > given the additional complexity can be optional.
> >
> > Please advise.
> >
> > 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
> >
> >
> > Cc: [email-masked] <mailto:[email-masked]>;
> > [email-masked] <mailto:[email-masked]>
> >> 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
> >>> 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>
> >>> 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.
> >>>
> >>> 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.
> >>>
> >>> 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.
> >>>
> >>>> 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
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Thu, 13 Sep 2012 13:15:49 +0000

Good to know that NOTIFY messages can be generated without NOTIFY request messages. Thanks for this info. So I agree that egress node SHOULD relay the signaling errors based on association type of "Single Sided Associated Bidirectional LSPs" and presence of "REVERSE_LSP" object.

Having said that, if an ingress node supports RFC3473 and makes request by sending NOTIFY request message to a transit node, and transit node also supports RFC3473 and the NOTIFY reply, the reverse LSP signaling notification from this transit node can work as well independent of egress relaying the messages. Do you agree? 

Thanks,
Rakesh

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Thursday, September 13, 2012 9:02 AM
To: Rakesh Gandhi (rgandhi)
Cc: [email-masked]; [email-masked]
Subject: Re: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Rakesh,
	This seems really complicated.  Why allow for the optional notification from the egress?  There is precedent for use of notify messages without notify requests (see RFC4974).

Also, as it stands Associated Bidirectional really only requires support by the end nodes. (I think of it as almost an application overlay on top of normal LSP signaling.  I'd even consider using the RFC4974 call approach if it wasn't for requirement 11 in RFC6373.)  I think placing processing requirements on transit nodes, such as sending reverse_lsp notifications adds unnecessary complexity and should be avoided unless absolutely necessary.

Lou (as participant)

On 9/12/2012 9:57 PM, Rakesh Gandhi (rgandhi) wrote:
> reverse LSP by using the NOTIFY message and procedures defined in RFC[3473].
> 
>  
> 
>  
> 
> Thanks,
> 
> Rakesh
> 
>  
> 
>  
> 
> words, there is no more information needs the egres/tail to inform the 
> ingress/head).
> 
> the egress/tail to provide the ingress/head with arbitrary information....
> /
> Thanks,
> Rakesh
>  
>  
> 
> Regards
> 
> Fei
> 
>> this too much so may be off, but method 3 seems to be most consistent 
>>> reverse LSP to the initializing ingress node. The egress node copies 
>>>> object, I would think that the ingress node needs to know about the

---

From: Lou Berger <[email-masked]>
Date: Thu, 13 Sep 2012 09:32:42 -0400

If one wanted to be cute, an ingress could include a NOTIFY_REQUEST
containing the ingress' address in the REVERSE_LSP object as well as the
Resv messages of incoming associated bidirectional LSPs.  Of course,
this means that the ingress would be notified of path errors for an LSP
for which it doesn't have path state...

Do you really want to go down the path of document all possible
uses/combination of objects carried in REVERSE_LSP objects?

Lou

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Thu, 13 Sep 2012 13:51:20 +0000

Hi Lou,

The NOTIFY request and reply procedures are defined in RFC3473 and can be used by any node who supports this RFC and this draft does not add/remove/modify any behavior/requirement in that regard. 

I didn't mean to include the NOTIFY request object in the REVERSE_LSP objects either.

Are we ok to add following text? 

 "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.  
 An egress node MAY use NOTIFY message and procedures defined in RFC[3473] for relaying 
 signaling error on the reverse LSP to the ingress node."

Thanks,
Rakesh

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Thursday, September 13, 2012 9:33 AM
To: Rakesh Gandhi (rgandhi)
Cc: [email-masked]; [email-masked]
Subject: Re: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

If one wanted to be cute, an ingress could include a NOTIFY_REQUEST containing the ingress' address in the REVERSE_LSP object as well as the Resv messages of incoming associated bidirectional LSPs.  Of course, this means that the ingress would be notified of path errors for an LSP for which it doesn't have path state...

Do you really want to go down the path of document all possible uses/combination of objects carried in REVERSE_LSP objects?

Lou

On 9/13/2012 9:15 AM, Rakesh Gandhi (rgandhi) wrote:
>> <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 
>> the ingress/head).
>> usage of the REVERSE_LSP Object in the path message.  Perhaps 
>> to allow the egress/tail to provide the ingress/head with arbitrary information....
>> /
>> Thanks,
>> Rakesh
>>  
>>  
>>
>> Regards
>>
>> Fei
>>
>>> One advantage with the mid-point sending notification for the 
>>> reverse LSP is that signaling error propagation time
>>> consistent with the usage of the REVERSE_LSP Object in the path message.
>>>> 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,
>>>>> the signaling (path) errors (such as soft preemption or admission