[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Need to close on signaling solution for graceful shutdown (Follow-up on our Action Item)

To: "Zafar Ali \(zali\)" <zali@cisco.com>
Subject: RE: Need to close on signaling solution for graceful shutdown (Follow-up on our Action Item)
From: Dimitri.Papadimitriou@alcatel.be
Date: Mon, 6 Mar 2006 08:48:11 +0100
Cc: "Adrian Farrel" <adrian@olddog.co.uk>, "Anca Zamfir \(ancaz\)" <ancaz@cisco.com>, ccamp@ops.ietf.org, dpapadimitriou@psg.com, "Jean Philippe Vasseur \(jvasseur\)" <jvasseur@cisco.com>, "Kireeti Kompella" <kireeti@juniper.net>, owner-ccamp@ops.ietf.org, "Zafar Ali \(zali\)" <zali@cisco.com>
hi zafar

planned restart and shutdown may indeed involve non fully overlapping 
operations but there is nothing that mandates from this that the IGP 
should make use of different procedures from preventing other nodes to use 
the links that will become unusable (shutting down TE links is a subset of 
the implied operations of a planned restart ... this said, section 3 of 
your document also mentions shutdown of an entire node)

your section should be adapted such as to detail when this new procedure 
would be advisable leaving the existing procedures unaffected and 
applicable 

much thanks,
- dimitri.





"Zafar Ali \(zali\)" <zali@cisco.com>
Sent by: owner-ccamp@ops.ietf.org
06/03/2006 05:36
 
        To:     "Zafar Ali \(zali\)" <zali@cisco.com>, Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Adrian Farrel" <adrian@olddog.co.uk>, "Anca Zamfir 
\(ancaz\)" <ancaz@cisco.com>, <ccamp@ops.ietf.org>, 
<dpapadimitriou@psg.com>, "Jean Philippe Vasseur \(jvasseur\)" 
<jvasseur@cisco.com>, "Kireeti Kompella" <kireeti@juniper.net>, 
<owner-ccamp@ops.ietf.org>
        Subject:        RE: Need to close on signaling solution for 
graceful shutdown (Follow-up on our Action Item)


< Attachment draft-ali-ccamp-mpls-graceful-shutdown-03.txt removed >


Dimitri,

We are planning to sending the enclosed version before the flood gate
closes. The use of link attribute subTLV is stated as completely
optional. Please find the following text in enclosed updated version.

"to deal with nodes not compliant with this document (i.e., does not
implement link attribute sub-TLV based solution), the node initiating
graceful shutdown MAY originate the TE LSA/LSP containing Link TLV with
0 unreserved bandwidth, Traffic Engineering metric set to 0xffffffff,
and if the Link is non-PSC then also with 0 as Max LSP Bandwidth."

Thanks

Regards... Zafar

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Zafar Ali (zali)
> Sent: Sunday, March 05, 2006 1:02 PM
> To: Dimitri.Papadimitriou@alcatel.be
> Cc: Adrian Farrel; Anca Zamfir (ancaz); ccamp@ops.ietf.org;
> dpapadimitriou@psg.com; Jean Philippe Vasseur (jvasseur);
> Kireeti Kompella; owner-ccamp@ops.ietf.org
> Subject: RE: Need to close on signaling solution for graceful
> shutdown (Follow-up on our Action Item)
>
> Hi Dimitri,
>
> There is a difference between expected operations in graceful
> restart and graceful shutdown; hence my previous email. The
> draft already lists Max Metric as a possible solution with
> motivation for selecting link attribute based solution. If
> the WG agrees that use of Max Metric suffices, we can fall
> back to the use of the Max Metric/ zero bw. We will be
> posting an updated version later tonight.
>
> Thanks
>
> Regards... Zafar
>
> > -----Original Message-----
> > From: Dimitri.Papadimitriou@alcatel.be
> > [mailto:Dimitri.Papadimitriou@alcatel.be]
> > Sent: Friday, March 03, 2006 6:46 PM
> > To: Zafar Ali (zali)
> > Cc: Adrian Farrel; Anca Zamfir (ancaz); ccamp@ops.ietf.org;
> > dpapadimitriou@psg.com; Jean Philippe Vasseur (jvasseur); Kireeti
> > Kompella; owner-ccamp@ops.ietf.org
> > Subject: RE: Need to close on signaling solution for
> graceful shutdown
> > (Follow-up on our Action Item)
> >
> > hi zafar
> >
> > then i will express my concern in the other way around
> concerning the
> > "routing" part of this document: we have clean procedures
> for planned
> > node restart in RFC4203; hence, the reason for having a "cleaner"
> > procedure is totally unclear to me both in terms of motivation and
> > applicability
> >
> > much thanks,
> > - dimitri.
> >
> >
> >
> >
> >
> >
> >
> >
> > "Zafar Ali \(zali\)" <zali@cisco.com>
> > Sent by: owner-ccamp@ops.ietf.org
> > 02/03/2006 07:06
> >
> >         To:     <dpapadimitriou@psg.com>, Dimitri
> > PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> >         cc:     <ccamp@ops.ietf.org>, "Adrian Farrel"
> > <adrian@olddog.co.uk>, "Anca Zamfir \(ancaz\)"
> > <ancaz@cisco.com>, "Jean Philippe Vasseur \(jvasseur\)"
> > <jvasseur@cisco.com>, "Kireeti Kompella"
> > <kireeti@juniper.net>
> >         Subject:        RE: Need to close on signaling solution for
> > graceful shutdown (Follow-up on our Action Item)
> >
> >
> > Hi Dimitri,
> >
> > Sorry for the delay in replying. Please see reply in-line.
> >
> > All,
> >
> > I am assuming the WG is ok with the signaling part of the
> solution. If
> > you have any comments, please reply to my original email.
> We plan to
> > refresh the ID before the flood gate closes.
> >
> > Thanks
> >
> > Regards... Zafar
> >
> > > -----Original Message-----
> > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com]
> > > Sent: Monday, February 20, 2006 2:01 AM
> > > To: Zafar Ali (zali)
> > > Cc: ccamp@ops.ietf.org; Adrian Farrel; Anca Zamfir (ancaz); Jean
> > > Philippe Vasseur (jvasseur); Kireeti Kompella
> > > Subject: Re: Need to close on signaling solution for graceful
> > > shutdown (Follow-up on our Action Item)
> > >
> > >
> > > zafar - thanks for the summary ... but i don't understand the
> > > following sentence
> > >
> > > "The IGP based solution is also based on an existing framework."
> > >
> > > to which framework are you referring to ?
> > >
> > > i am more concerned with section 4.2, for three reasons
> > >
> > > o) the document seems to say that such links could be
> used as last
> > > resort link for zero bandwidth LSP - note that this
> applies only to
> > > PSC links because non-PSC would not make use of such
> links - let's
> > > assume this may be the case, as you are dealing with a "planned
> > > outage" i am not sure you are going to make a lot of
> operations such
> > > as new path computations during such event (and risk further
> > > degradation)
> > >
> >
> > A link may end-up with max metric for multiple reasons and
> without the
> > link attribute there is no way a node can tell what the reason is,
> > e.g.
> > a restarting node may advertises the max matrices.
> Furthermore, if the
> > resource under graceful deletion is the last resort then the node
> > hosting the graceful deletion resource will not receive new
> signaling
> > messages. Also, graceful deletion is not the main
> motivation for the
> > introduction of the link attribute sub-TLV; we are just overloading
> > the use of link attribute to provide a cleaner
> specification. Hence, I
> > mention "existing framework". We can enhance the text in
> the ID to be
> > more specific in this notification.
> >
> > > o) the document makes use of a link attribute (but where is this
> > > attribute defined ?)
> > >
> >
> > The link attribute ID-es needs to be refreshed.
> >
> > > o) this section forces to have to have two different
> procedures (as
> > > planned restarting nodes advertise their link with these
> attributes
> > > making them unusable before the restart occurs, section 2 of
> > > RFC4203)
> > >
> >
> > See my comment above.
> >
> > > thanks,
> > > - dimitri.
> > >
> > >
> > > Zafar Ali (zali) wrote:
> > >
> > > > Dear Ccampers:
> > > >
> > > >
> > > >
> > > > This is a follow-up on our action item from the last IETF
> > > meeting to
> > > > send an email to close the signaling solution for
> > graceful shutdown
> > > > procedure proposed in
> > > >
> > >
> >
> http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shut
> > > > do
> > > > wn-02.txt
> > > >
> > >
> >
> <http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shu
> > > > td
> > > > own-02.txt> .
> > > >
> > > >
> > > >
> > > > During the meeting it was clear that we have an
> agreement on the
> > > > requirement front. We also have an agreement that we need
> > > both routing
> > > > and signaling based solutions. This is because an IGP
> only based
> > > > solution is not applicable when dealing with Inter-area and
> > > Inter-AS
> > > > traffic engineering, as LSA or LSP flooding is
> restricted to IGP
> > > > areas/levels. Consequently, RSVP based mechanisms are
> > > required to cope
> > > > with TE LSPs spanning multiple domains. The draft presents
> > > > complementary mechanisms for RSVP-TE and IGP for Graceful
> > Shutdown.
> > > > The IGP based solution is also based on an existing
> > framework. Our
> > > > action item is to close on the signaling based counterpart.
> > > >
> > > >
> > > >
> > > > Before we compare the candidate solution, let's discuss and
> > > agree on
> > > > general requirement for a signaling based graceful shutdown
> > > mechanism.
> > > > In graceful shutdown procedure, as the Ingress LSR is
> expected to
> > > > perform make-before-break for the LSP (using the
> resource that is
> > > > being shutdown), we should be able to specify the TE
> > > resource (link/
> > > > node) under graceful shutdown.  Furthermore, conveying
> signaling
> > > > message to the Ingress LSR suffices. I.e., we can make use
> > > of the Notify Message.
> > > >
> > > >
> > > >
> > > > One of the solutions proposed during these discussions is
> > > to make use
> > > > of the admin status object. However, admin status
> cannot contain
> > > > information about TE resource under Graceful Shutdown.
> > > Hence, we did
> > > > not consider use of admin status object as a possible solution.
> > > >
> > > >
> > > >
> > > > Another alternate that was put forward is the use ALARM_
> > > SPEC Objects.
> > > > While ALARM_ SPEC Objects has ability to Signal Info about
> > > TE resource
> > > > under Graceful shutdown, use of this object in the notify
> > > message is
> > > > not defined. We also feel use of the ALARM_ SPEC Objects is
> > > heavy duty
> > > > for signaling simple Graceful Shutdown condition.
> > > >
> > > >
> > > >
> > > > We propose to overload "TE link maintenance required"
> > > sub-code of the
> > > > Notify Error Code (24) of the ERROR_SPEC. We believe
> this is the
> > > > simplest solution with existing/ well used way to signal
> > > information
> > > > about TE resource under Graceful Shutdown. Furthermore, the
> > > ERROR_SPEC
> > > > with code 24/ sub-code TBD can then be carried in either
> > PathErr or
> > > > Notify message to signal graceful condition.
> > > >
> > > >
> > > >
> > > > Can you please send your comments to this by the end of
> > > this week so
> > > > we can update the ID, if needed?
> > > >
> > > >
> > > >
> > > > Thanks
> > > >
> > > >
> > > >
> > > > Regards... Zafar
> > > >
> > > > This is a follow-up on our action item from the last IETF
> > > meeting to
> > > > send an email to close the signaling solution for
> > graceful shutdown
> > > > procedure proposed in
> > > >
> > >
> >
> http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shut
> > > > do
> > > > wn-02.txt.
> > > >
> > > >
> > > >
> > > > During the meeting it was clear that we have an
> agreement on the
> > > > requirement front. We also have an agreement that we need
> > > both routing
> > > > and signaling based solutions. This is because an IGP
> only based
> > > > solution is not applicable when dealing with Inter-area and
> > > Inter-AS
> > > > traffic engineering, as LSA or LSP flooding is
> restricted to IGP
> > > > areas/levels. Consequently, RSVP based mechanisms are
> > > required to cope
> > > > with TE LSPs spanning multiple domains. The draft presents
> > > > complementary mechanisms for RSVP-TE and IGP for Graceful
> > Shutdown.
> > > > The IGP based solution is also based on an existing
> > framework. Our
> > > > action item is to close on the signaling based counterpart.
> > > >
> > > >
> > > >
> > > > Before we compare the candidate solution, let's discuss and
> > > agree on
> > > > general requirement for a signaling based graceful shutdown
> > > mechanism.
> > > > In graceful shutdown procedure, as the Ingress LSR is
> expected to
> > > > perform make-before-break for the LSP (using the
> resource that is
> > > > being shutdown), we should be able to specify the TE
> > > resource (link/
> > > > node) under graceful shutdown.  Furthermore, conveying
> signaling
> > > > message to the Ingress LSR suffices. I.e., we can make use
> > > of the Notify Message.
> > > >
> > > >
> > > >
> > > > One of the solutions proposed during these discussions is
> > > to make use
> > > > of the admin status object. However, admin status
> cannot contain
> > > > information about TE resource under Graceful Shutdown.
> > > Hence, we did
> > > > not consider use of admin status object as a possible solution.
> > > >
> > > >
> > > >
> > > > Another alternate that was put forward is the use ALARM_
> > > SPEC Objects.
> > > > While ALARM_ SPEC Objects has ability to Signal Info about
> > > TE resource
> > > > under Graceful shutdown, use of this object in the notify
> > > message is
> > > > not defined. We also feel use of the ALARM_ SPEC Objects is
> > > heavy duty
> > > > for signaling simple Graceful Shutdown condition.
> > > >
> > > >
> > > >
> > > > We propose to overload "TE link maintenance required"
> > > sub-code of the
> > > > Notify Error Code (24) of the ERROR_SPEC. We believe
> this is the
> > > > simplest solution with existing/ well used way to signal
> > > information
> > > > about TE resource under Graceful Shutdown. Furthermore, the
> > > ERROR_SPEC
> > > > with code 24/ sub-code TBD can then be carried in either
> > PathErr or
> > > > Notify message to signal graceful condition.
> > > >
> > > >
> > > >
> > > > Can you please send your comments to this by the end of
> > > this week so
> > > > we can update the ID, if needed?
> > > >
> > > >
> > > >
> > > > Thanks
> > > >
> > > >
> > > >
> > > > Regards... Zafar
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
>
Prev by Date: RE: Need to close on signaling solution for graceful shutdown (Follow-up on our Action Item)
Next by Date: Re: New revision of GMPLS TE MIB
Previous by thread: RE: Need to close on signaling solution for graceful shutdown (Follow-up on our Action Item)
Next by thread: Fw: Last Call: draft-fenner-zinin-rtg-standard-reqts-01.txt
Index(es):
- Date
- Thread