Subject: RE: draft-minei-mpls-ldp-planned-restart-00.txt & draft-ali-ccamp-rsvp-hello-gr-admin-00.txt

From: "zafar ali" <[email-masked]>
Date: Wed, 10 Mar 2004 20:17:18 -0500

Hi Ina, Rahul, Albert, et al

Thanks for your reply. We have a similar draft in CCAMP that formalized
procedure for disabling RSVP GR (and Hello) (see,
http://www.ietf.org/internet-drafts/draft-ali-ccamp-rsvp-hello-gr-admin-
00.txt for details). 

The requirements/ motivations for the two drafts in question are
similar. Ideally what you would like to do in your draft is to also be
able to turn LDP GR on and off on the fly. I hope the two drafts will
get the same treatment from the WGs (adding CCAMP). 

Thanks

Regards... Zafar

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf 
>Of Ina Minei
>Sent: Tuesday, March 09, 2004 6:35 PM
>To: zafar ali
>Cc: 'MPLS wg'; [email-masked]; 'Rahul Aggarwal'; 'Loa 
>Andersson'; 'George Swallow'
>Subject: Re: draft-minei-mpls-ldp-planned-restart-00.txt
>
>
>
>	Zafar,
>
>	3478 details the procedures for doing graceful restart 
>in the case where the capability will be used irrespective of 
>the cause of the crash.
>
>	The proposed enhancement deals with a situation where 
>the operator wants to perform graceful restart only when he is 
>doing a planned upgrade. Why? Because a planned upgrade is a 
>controled environment. This is mostly a comfort-level issue 
>for the operator and a good way to let him convince himself 
>that the feature is working as expected. Many operators are 
>wary of graceful restart, but would really like to see 
>graceful upgrades.
>
>				Ina
>
>On Tue, 9 Mar 2004, zafar ali wrote:
>
>> Hi Ina, Rahul and Albert,
>>
>>
>>
>> I am not sure about motivation behind this draft. Why procedures in 
>> RFC 3478 are are NOT enough to address planned outages? This 
>question 
>> was also raised at the last MPLS WG meeting but I did not hear any 
>> convincing answer.
>>
>>
>>
>> Thanks
>>
>>
>>
>> Regards... Zafar
>>
>>
>

---

From: Rahul Aggarwal <[email-masked]>
Date: Wed, 10 Mar 2004 17:26:36 -0800 (PST)

Hi Zafar,

[snipped]

> similar.

The difference is that RSVP-TE already supports the ability to toggle the
graceful restart capability of a router by including/excluding the restart
capability object in RSVP-TE hellos. This can be done without breaking the
neighbor relationship between the adjacent routers.

rahul

---

From: "zafar ali" <[email-masked]>
Date: Wed, 10 Mar 2004 20:53:53 -0500

>From: Rahul Aggarwal [mailto:[email-masked]] 
>Sent: Wednesday, March 10, 2004 8:27 PM
>To: zafar ali
>Cc: 'Ina Minei'; 'MPLS wg'; [email-masked]; 'Loa Andersson'; 
>'George Swallow'; [email-masked]; 'Reshad Rahman'; 
>[email-masked]
>Subject: RE: draft-minei-mpls-ldp-planned-restart-00.txt & 
>draft-ali-ccamp-rsvp-hello-gr-admin-00.txt
>
>
>
>Hi Zafar,
>
>[snipped]
>
>>
>> Thanks for your reply. We have a similar draft in CCAMP that 
>> formalized procedure for disabling RSVP GR (and Hello) (see,
>> 
>The difference is that RSVP-TE already supports the ability to 
>toggle the graceful restart capability of a router by 
>including/excluding the restart capability object in RSVP-TE 
>hellos. This can be done without breaking the neighbor 
>relationship between the adjacent routers.
>

Hi Rahul, 

We would not be having "part" of this discussion had there be a
statement stating the same in RFC 3473; a clarification is needed.
Furthermore, SPs have similar motivations for removing RSVP Hello
adjacencies without cause 
triggering FRR or GR. Not to mention due to possible millisecond
interval, SPs don't like to see RSVP Hello running even when there is no
application requiring them. You can argue that one node can back-off
RSVP hello interval, but the Hello frequency depends on min of the Hello
intervals at the peering nodes. 

Thanks

Regards... Zafar

>> >From: [email-masked] [mailto:[email-masked]] On Behalf Of Ina 
>> >Minei
>> >Cc: 'MPLS wg'; [email-masked]; 'Rahul Aggarwal'; 'Loa Andersson'; 
>> >'George Swallow'
>> >in the case where the capability will be used irrespective of the 
>> >cause of the crash.
>> >
>> >the operator wants to perform graceful restart only when he 
>is doing 
>> >a planned upgrade. Why? Because a planned upgrade is a controled 
>> >environment. This is mostly a comfort-level issue for the operator 
>> >and a good way to let him convince himself that the feature is 
>> >working as expected. Many operators are wary of graceful 
>restart, but 
>> >would really like to see graceful upgrades.
>> >
>> >				Ina
>> >

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 15 Mar 2004 08:26:00 -0800

Zafar,

> adjacencies without cause triggering FRR or GR. 
> Not to mention due to possible millisecond
> interval, 

Perhaps running RSVP Hellos as millisecond interval is not a wise 
idea in the first place. 

>          SPs don't like to see RSVP Hello running even when there is no
> application requiring them. 

Could you please describe scenario(s) where you would have RSVP Hello
running "even when there is no application requiring them".

Yakov.

---

From: "zafar ali" <[email-masked]>
Date: Mon, 15 Mar 2004 12:01:55 -0500

<snip>
>
>>          SPs don't like to see RSVP Hello running even when there is 
>> no application requiring them.
>
>Could you please describe scenario(s) where you would have 
>RSVP Hello running "even when there is no application requiring them".
>
>Yakov.
>

Hi Yakov, 

Here is a scenario: 

1. You start without any application that require RSVP Hellos. 
--> You will see RSVP Hellos are NOT running. 

2. You enable an application (GR/ FRR) requiring RSVP Hellos. 
--> You will see RSVP Hellos start running. 

So far so good :-) 

3. You disable application requiring RSVP Hello. 
--> One would expect RSVP Hellos to stop but they keeps running :-( If
one side stops replying to RSVP Hello, it would cause traffic disruption
for LSPs that depend on the health of the Hello session. The only way to
get around this limitation is to continue to run Hellos. 

Furthermore, the draft also formalizes procedure for disabling RSVP GR.
Hence in these respect the problem space for
draft-minei-mpls-ldp-planned-restart-00.txt &
draft-ali-ccamp-rsvp-hello-gr-admin-00.txt is the same.  IMO both drafts
address a similar but useful need in operation of networks. 

Like we mentioned in CCAMP WG meeting, we are open to the solution for
administrative shut-down of RSVP Hellos. My comment for
draft-minei-mpls-ldp-planned-restart-00.txt to make the text more
generic as a way to enable/ disable LDP/ GR on the fly. Ina, et al may
like to consider this comment. 

Thanks

Regards... Zafar

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 15 Mar 2004 11:31:18 -0800

Zafar,

> get around this limitation is to continue to run Hellos. 

The scenario you described above seems to assume that there are
RSVP applications that do *not* require to run RSVP Hellos. However,
I think this assumption is fairly problematic for the following
reason.

RSVP Hello have dual semantics - (a) liveness of RSVP module of
the control plane, and (b) liveness of data plane between RSVP
neighbors.  While there are better ways to detect liveness of the
data plane than to use RSVP Hellos (BFD is certainly better than
RSVP Hello for that purpose), using RSVP Hellos for detecting
liveness of RSVP module of the control plane seems to be the best
available today.  And running an application that uses RSVP, without
being able to detect the state of the RSVP module of the control
plane of a neighbor seems to be fairly problematic (to say the least).

Yakov.

---

From: "zafar ali" <[email-masked]>
Date: Mon, 15 Mar 2004 15:58:24 -0500

Hi Yakov, 

Please see my reply in-line. 

Thanks
 
Regards... Zafar

>Of Yakov Rekhter
>Sent: Monday, March 15, 2004 2:31 PM
>To: zafar ali
>Cc: 'Rahul Aggarwal'; 'Ina Minei'; 'MPLS wg'; 
>[email-masked]; 'Loa Andersson'; 'George Swallow'; 
>[email-masked]; 'Reshad Rahman'; [email-masked]
>Subject: Re: draft-minei-mpls-ldp-planned-restart-00.txt & 
>> one side stops replying to RSVP Hello, it would cause traffic 
>> disruption for LSPs that depend on the health of the Hello session. 
>> The only way to get around this limitation is to continue to run 
>> Hellos.
>
>The scenario you described above seems to assume that there 
>are RSVP applications that do *not* require to run RSVP 
>Hellos. 

Yes. Specifically, basic RSVP signaling does NOT require use of RSVP
Hello to detect liveness of RSVP module at the neighbor and instead uses
refresh mechanics for this purpose. Furthermore, RFC3209 says that "The
Hello Message is completely OPTIONAL". 

>However, I think this assumption is fairly problematic 
>for the following reason.
>
>RSVP Hello have dual semantics - (a) liveness of RSVP module 
>of the control plane, and (b) liveness of data plane between 
>RSVP neighbors.  While there are better ways to detect 
>liveness of the data plane than to use RSVP Hellos (BFD is 
>certainly better than RSVP Hello for that purpose), using RSVP 
>Hellos for detecting liveness of RSVP module of the control 
>plane seems to be the best available today. 

Agreed! And I did not say that. Yes, RSVP/ GR is one such application
that makes use of RSVP Hello for this purpose. 

> And running an 
>application that uses RSVP, without being able to detect the 
>state of the RSVP module of the control plane of a neighbor 
>seems to be fairly problematic (to say the least).

Yes, I agree. I think your and my definition of "application" is
different. Nonetheless, do you agree that basic RSVP signaling can work
without RSVP Hello? Otherwise I would expect your implementation starts
sending RSVP Hellos as soon as RSVP is configured on an interface, is
this the case? Please advise.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 15 Mar 2004 13:28:15 -0800

Zafar,

> refresh mechanics for this purpose. 

In principle one could use the refresh mechanism as a liveness
detection of the RSVP module of the control plane. However, the
overhead of the refresh mechanism is certainly higher than of Hello.
And that is why using RSVP Hellos for detecting liveness of RSVP
module of the control plane seems to be the best available today
(note that "best" does not imply "the only").

Yakov.

---

From: "zafar ali" <[email-masked]>
Date: Mon, 15 Mar 2004 17:29:20 -0500

Hi Yakov, 

Please see in-line. 

Thanks
 
Regards... Zafar

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Yakov Rekhter
>Sent: Monday, March 15, 2004 4:28 PM
>To: zafar ali
>> >> >Could you please describe scenario(s) where you would have RSVP 
>> >> >Hello running "even when there is no application
>> >requiring them".
>> >> >
>> >> >Yakov.
>> >> >
>> >> 
>> >> Hi Yakov,
>> >> 
>> >> Here is a scenario:
>> >> 
>> Hello to detect liveness of RSVP module at the neighbor and instead 
>> uses refresh mechanics for this purpose.
>
>detection of the RSVP module of the control plane. However, 
>the overhead of the refresh mechanism is certainly higher than 
>of Hello. And that is why using RSVP Hellos for detecting 
>liveness of RSVP module of the control plane seems to be the 
>best available today (note that "best" does not imply "the only").
>

So we are in agreement :-) The fact of the matter is that RSVP Hellos
are "optional" and an LSR (say LSR-B) may not reply to RSVP Hello
messages unless the LSR-B ALSO thinks that it needs to establish an RSVP
Hello adjacency. In such cases it is even better if the initiating LSR
(LSR-A) knows intent of LSR-B. In other words, the draft in question
does NOT change the equation, but only helps.

---

From: "zafar ali" <[email-masked]>
Date: Mon, 15 Mar 2004 17:29:20 -0500

Hi Yakov, 

Please see in-line. 

Thanks
 
Regards... Zafar

---

From: "zafar ali" <[email-masked]>
Date: Mon, 15 Mar 2004 17:29:20 -0500

Hi Yakov, 

Please see in-line. 

Thanks
 
Regards... Zafar

---

From: "zafar ali" <[email-masked]>
Date: Mon, 15 Mar 2004 17:29:20 -0500

Hi Yakov, 

Please see in-line. 

Thanks
 
Regards... Zafar

---

From: "zafar ali" <[email-masked]>
Date: Mon, 15 Mar 2004 17:29:20 -0500

Hi Yakov, 

Please see in-line. 

Thanks
 
Regards... Zafar

---

From: "zafar ali" <[email-masked]>
Date: Mon, 15 Mar 2004 17:29:20 -0500

Hi Yakov, 

Please see in-line. 

Thanks
 
Regards... Zafar

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 15 Mar 2004 13:28:15 -0800

Zafar,

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 15 Mar 2004 13:28:15 -0800

Zafar,

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 17 Mar 2004 07:15:04 -0800

Zafar,

> So we are in agreement :-) 

So you agree that (a) RSVP Hello should be used to detect liveness
of RSVP module, and (b) any use of RSVP should include (among other
things) the ability to detect liveness of the RSVP module of a neighbor.
Correct ?

Yakov.

---

From: "zafar ali" <[email-masked]>
Date: Wed, 17 Mar 2004 11:11:09 -0500

Hi Yakov, 

Please see my response in-line. 

>Sent: Wednesday, March 17, 2004 10:15 AM
>To: zafar ali
>> >> >> disruption for LSPs that depend on the health of the Hello 
>> >> >> session. The only way to get around this limitation is to 
>> >> >> continue to run Hellos.
>> >> >
>> >> >RSVP applications that do *not* require to run RSVP Hellos.
>> >> 
>So you agree that (a) RSVP Hello should be used to detect 
>liveness of RSVP module, and (b) any use of RSVP should 
>include (among other
>things) the ability to detect liveness of the RSVP module of a 
>neighbor. Correct ?
>

No, unless you can please point me to a place where such use of RSVP
Hello is documented. What you wanted to do can ONLY be achieved if RSVP
Hello protocol is mandatory. The fact remains that RSVP Hellos are
"optional" and standard RSVP (RFC2205) "IS" required to maintain state
via the generation of RSVP refresh messages. 

Thanks

Regards... Zafar

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 17 Mar 2004 08:29:47 -0800

Zafar,

> via the generation of RSVP refresh messages. 

And what is wrong with making RSVP Hellos mandatory, and use it as
*the* mechanism to determing the state of the RSVP module on a neighbor ?

Yakov.

---

From: "zafar ali" <[email-masked]>
Date: Wed, 17 Mar 2004 11:45:31 -0500

Hi Yakov, 

Please see my comments in-line. 

>From: Yakov Rekhter [mailto:[email-masked]] 
>Sent: Wednesday, March 17, 2004 11:30 AM
>To: zafar ali
>> >> >overhead of the refresh mechanism is certainly higher than of 
>> >> >Hello. And that is why using RSVP Hellos for detecting 
>liveness of 
>> >> >RSVP module of the control plane seems to be the best available 
>> >> >today (note that "best" does not imply "the only").
>> >> 
>> Hello is documented. What you wanted to do can ONLY be achieved if 
>> RSVP Hello protocol is mandatory. The fact remains that RSVP Hellos 
>> are "optional" and standard RSVP (RFC2205) "IS" required to maintain 
>> state via the generation of RSVP refresh messages.
>

Are you saying that just because RSVP control plan at the neighbor is up
means that it's in-sync, given that we don't use a reliable transport
mechanics? We still need to rely on RSVP refresh messages for
maintaining states; this is just "HOW" RSVP protocol is defined. And NOT
to mention about existing implementations and deployments. 

Thanks

Regards... Zafar

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 17 Mar 2004 12:57:45 -0800

Zafar,

[clipped...]

> >> >> >Hello. And that is why using RSVP Hellos for detecting liveness of 

Wrt "we don't use a reliable transport mechanics", I assume that
one uses rfc2961 (RSVP Refresh Overhead Reduction Extensions),
which (among other things) supports reliable RSVP message delivery.

Wrt maintaining/refreshing state, we could still rely on RSVP
refresh messages.  But wrt detecting liveness of the neighbor's
RSVP module, I think using RSVP Hellos is a better alternative than
relying on on RSVP refresh messages.

More generally, refreshing state and protocol liveness detection
need not be coupled, and should not be coupled. For an example look
at ISIS or OSPF - resending LSAs to refresh state, sending Hellos
to provide protocol liveness detection.

Yakov.

---

From: "zafar ali" <[email-masked]>
Date: Wed, 17 Mar 2004 17:02:53 -0500

Hi Yakov, 

Thanks
 
Regards... Zafar

>Sent: Wednesday, March 17, 2004 3:58 PM
>To: zafar ali
>> Are you saying that just because RSVP control plan at the 
>neighbor is 
>> up means that it's in-sync, given that we don't use a reliable 
>> transport mechanics? We still need to rely on RSVP refresh messages 
>> for maintaining states; this is just "HOW" RSVP protocol is defined. 
>> And NOT to mention about existing implementations and deployments.
>
>Wrt "we don't use a reliable transport mechanics", I assume 
>that one uses rfc2961 (RSVP Refresh Overhead Reduction 
>Extensions), which (among other things) supports reliable RSVP 
>message delivery.

Yes, I wanted to imply that RSVP requires refresh mechanics. 

>refresh messages.  But wrt detecting liveness of the 
>neighbor's RSVP module, I think using RSVP Hellos is a better 
>alternative than relying on on RSVP refresh messages.
>

For what you are saying, why would someone not use RSVP/ GR? IMO the
best thing to do is to use RSVP GR procedure. If RSVP/ GR is NOT
enabled, what actions you expect a node to take when it detects failures
at the neighbor's RSVP module. Are such actions documented and agreed
upon some where? No matter what your answer would be, my question will
remain, "in such case, why would someone not use RSVP/ GR?". 

Thanks

Regards... Zafar