[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: TE metric and graceful restart
Don,
> Kireeti, Zafer:
>
> I think that Zafer picked up on my earlier point that just because routing
> is gracefully restarting an implementation may have an independent
> LSP system that can function just fine so why be forced to penalize
> it? On the other hand, you may have an LSP system that is linked
> to routing such it must restart as well and then I would agree that
> zeroing bandwidth may well be necessary( but somewhat less "graceful").
> I'm not convinced changing Metrics is required at all.
>
> So I would agree with Zafer the wording should be such that either
> case is allowed,
Here is the current text:
When a restarting node is going to originate its TE LSAs, the TE LSAs
containing Link TLV should be originated with 0 unreserved bandwidth,
and if the Link has LSC or FSC as its Switching Capability then also
with 0 as Max LSP Bandwidth, until the node is able to determine the
amount of unreserved resources taking into account the resources
reserved by the already established LSPs that have been preserved
across the restart. Once the restarting node determines the amount of
unreserved resources, taking into account the resources reserved by
the already established LSPs that have been preserved across the
restart, the node should advertise these resources in its TE LSAs.
First of all note that the node advertises 0 unreserved b/w
*only* "until the node is able to determine the
amount of unreserved resources taking into account the resources
reserved by the already established LSPs that have been preserved
across the restart."
Second, note that originating TE LSA with 0 unreserved b/w
is *should*, not *must*.
With this in mind, don't you think that the text is ok ?
Or do you still want to change "should" in the first sentence above
into "may" ?
Yakov.
>
> Don
> -----Original Message-----
> >From: Zafar Ali [mailto:zali@cisco.com]
> >Sent: Sunday, April 28, 2002 1:53 AM
> >To: Kireeti Kompella
> >Cc: ccamp@ops.ietf.org
> >Subject: RE: TE metric and graceful restart
> >
> >
> >Dear Kireeti,
> >
> >Thanks for the reply; Please see comments in-lined.
> >
> >At 10:01 PM 4/27/2002 -0700, Kireeti Kompella wrote:
> >
> >
> >On Sat, 27 Apr 2002, Zafar Ali wrote:
> >
> >> The reason that I understood this as a MAY case is that a node that saves
> >> bandwidth usage state information locally is able to determine (or
> >> estimate) the amount of unreserved resources immediately upon start-up.
> In
> >> which case it MAY advertise the saved (projected) value(s) during the
> >> graceful restart period.
> >
> >Attractive as that may be, life is not so simple. The process of
> >recovery for signaling is complex enough without having new LSPs set
> >up during recovery. The idea of discouraging LSPs during recovery is
> >not just that the recovering node doesn't know its unreserved bandwidth,
> >but that it wants to complete recovery before setting up new LSPs.
> >
> >A simple example is that the recovering node X uses per-box labels,
> >gets a new LSP request while recovering, and allocates label L to that
> >request. But L is already in use for an existing LSP ....
> >One can
> >work around this particular example, but keeping it simple seems like
> >a good initial goal.
> >
> >Agreed! As I also mentioned that in doing so the node looses the charm
> >of discouraging other nodes in the network
> >in using it, during the restart period. This opens doors for some
> >potential race conditions and >scenarios like the one you mentioned
> >in the email. Of course, a node that may choose to do so >has to deal
> >with kind of scenarios that you mentioned in the email. I see that
> >there are some tradeoffs involved and the standard should leave a
> >room for exercising such options. Hence, IMO this should be a local
> >(vendor specific) decision.
> >
> >In short, while I am agreeing with the recommendation, I think the
> >"SHOULD" part should be >>removed and the standard should leave it as
> >part of the local decision.
> >
> >Thanks
> >
> >Regards... Zafar
> >
> >>
> >>
> >>At least, that's my take.
> >>
> >>Kireeti.
>
> ------_=_NextPart_001_01C1EFB2.8A7BC48E
> Content-Type: text/html;
> charset="iso-8859-1"
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
> <HEAD>
> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
> <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
> <TITLE>RE: TE metric and graceful restart</TITLE>
> </HEAD>
> <BODY>
>
> <P><FONT SIZE=2>Kireeti, Zafer:</FONT>
> </P>
>
> <P><FONT SIZE=2>I think that Zafer picked up on my earlier point that just be
cause routing</FONT>
> <BR><FONT SIZE=2>is gracefully restarting an implementation may have an indep
endent </FONT>
> <BR><FONT SIZE=2>LSP system that can function just fine so why be forced to p
enalize </FONT>
> <BR><FONT SIZE=2>it? On the other hand, you may have an LSP system that is li
nked </FONT>
> <BR><FONT SIZE=2>to routing such it must restart as well and then I would agr
ee that </FONT>
> <BR><FONT SIZE=2>zeroing bandwidth may well be necessary( but somewhat less &
quot;graceful").</FONT>
> <BR><FONT SIZE=2>I'm not convinced changing Metrics is required at all. </FON
T>
> </P>
>
> <P><FONT SIZE=2>So I would agree with Zafer the wording should be such that e
ither </FONT>
> <BR><FONT SIZE=2>case is allowed,</FONT>
> </P>
>
> <P><FONT SIZE=2>Don </FONT>
> <BR><FONT SIZE=2>-----Original Message-----</FONT>
> <BR><FONT SIZE=2>>From: Zafar Ali [<A HREF="mailto:zali@cisco.com";>mailto:
zali@cisco.com</A>]</FONT>
> <BR><FONT SIZE=2>>Sent: Sunday, April 28, 2002 1:53 AM</FONT>
> <BR><FONT SIZE=2>>To: Kireeti Kompella</FONT>
> <BR><FONT SIZE=2>>Cc: ccamp@ops.ietf.org</FONT>
> <BR><FONT SIZE=2>>Subject: RE: TE metric and graceful restart</FONT>
> <BR><FONT SIZE=2>></FONT>
> <BR><FONT SIZE=2>></FONT>
> <BR><FONT SIZE=2>>Dear Kireeti, </FONT>
> <BR><FONT SIZE=2>></FONT>
> <BR><FONT SIZE=2>>Thanks for the reply; Please see comments in-lined. </FO
NT>
> <BR><FONT SIZE=2>></FONT>
> <BR><FONT SIZE=2>>At 10:01 PM 4/27/2002 -0700, Kireeti Kompella wrote:</FO
NT>
> <BR><FONT SIZE=2>></FONT>
> <BR><FONT SIZE=2>></FONT>
> <BR><FONT SIZE=2>>On Sat, 27 Apr 2002, Zafar Ali wrote:</FONT>
> <BR><FONT SIZE=2>></FONT>
> <BR><FONT SIZE=2>>> The reason that I understood this as a MAY case is
that a node that saves</FONT>
> <BR><FONT SIZE=2>>> bandwidth usage state information locally is able t
o determine (or</FONT>
> <BR><FONT SIZE=2>>> estimate) the amount of unreserved resources immedi
ately upon start-up. In</FONT>
> <BR><FONT SIZE=2>>> which case it MAY advertise the saved (projected) v
alue(s) during the</FONT>
> <BR><FONT SIZE=2>>> graceful restart period.</FONT>
> <BR><FONT SIZE=2>></FONT>
> <BR><FONT SIZE=2>>Attractive as that may be, life is not so simple.
The process of</FONT>
> <BR><FONT SIZE=2>>recovery for signaling is complex enough without having
new LSPs set</FONT>
> <BR><FONT SIZE=2>>up during recovery. The idea of discouraging LSPs
during recovery is</FONT>
> <BR><FONT SIZE=2>>not just that the recovering node doesn't know its unres
erved bandwidth,</FONT>
> <BR><FONT SIZE=2>>but that it wants to complete recovery before setting up
new LSPs.</FONT>
> <BR><FONT SIZE=2>></FONT>
> <BR><FONT SIZE=2>>A simple example is that the recovering node X uses per-
box labels,</FONT>
> <BR><FONT SIZE=2>>gets a new LSP request while recovering, and allocates l
abel L to that</FONT>
> <BR><FONT SIZE=2>>request. But L is already in use for an existing L
SP .... </FONT>
> <BR><FONT SIZE=2>>One can</FONT>
> <BR><FONT SIZE=2>>work around this particular example, but keeping it simp
le seems like</FONT>
> <BR><FONT SIZE=2>>a good initial goal.</FONT>
> <BR><FONT SIZE=2>></FONT>
> <BR><FONT SIZE=2>>Agreed! As I also mentioned that in doing so the node lo
oses the charm </FONT>
> <BR><FONT SIZE=2>>of discouraging other nodes in the network </FONT>
> <BR><FONT SIZE=2>>in using it, during the restart period. This opens doors
for some </FONT>
> <BR><FONT SIZE=2>>potential race conditions and >scenarios like the one
you mentioned </FONT>
> <BR><FONT SIZE=2>>in the email. Of course, a node that may choose to do so
>has to deal </FONT>
> <BR><FONT SIZE=2>>with kind of scenarios that you mentioned in the email.
I see that </FONT>
> <BR><FONT SIZE=2>>there are some tradeoffs involved and the standard shoul
d leave a </FONT>
> <BR><FONT SIZE=2>>room for exercising such options. Hence, IMO this should
be a local </FONT>
> <BR><FONT SIZE=2>>(vendor specific) decision. </FONT>
> <BR><FONT SIZE=2>></FONT>
> <BR><FONT SIZE=2>>In short, while I am agreeing with the recommendation, I
think the </FONT>
> <BR><FONT SIZE=2>>"SHOULD" part should be >>removed and th
e standard should leave it as </FONT>
> <BR><FONT SIZE=2>>part of the local decision. </FONT>
> <BR><FONT SIZE=2>></FONT>
> <BR><FONT SIZE=2>>Thanks</FONT>
> <BR><FONT SIZE=2>></FONT>
> <BR><FONT SIZE=2>>Regards... Zafar </FONT>
> <BR><FONT SIZE=2>></FONT>
> <BR><FONT SIZE=2>>></FONT>
> <BR><FONT SIZE=2>>></FONT>
> <BR><FONT SIZE=2>>>At least, that's my take.</FONT>
> <BR><FONT SIZE=2>>></FONT>
> <BR><FONT SIZE=2>>>Kireeti.</FONT>
> </P>
>
> </BODY>
> </HTML>
> ------_=_NextPart_001_01C1EFB2.8A7BC48E--
>