[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Summary [was: RE: Starting a discussion on graceful shutdown]
Dear Richard,
Please see my reply in-line.
Thanks a lot for your review and detailed comments,
Regards... Zafar
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Richard Rabbat
> Sent: Thursday, February 17, 2005 5:35 PM
> To: 'Zafar Ali'; 'Adrian Farrel'; ccamp@ops.ietf.org
> Subject: RE: Summary [was: RE: Starting a discussion on
> graceful shutdown]
>
> Hi Zafar,
> First, I'd like to point out that your draft has expired;
> thought you might want to put a quick version up.
You will see a copy of draft reflecting all comments received thus far petty
soon.
> Some comments inline and more generally about the draft.
> Thanks a lot,
> Richard.
> --
> - in the text, you say: MAY NOT. This is not defined.
Good catch, in the new version you will see revised text.
>
> - Discussing PCE in this draft seems to be out of place. This
> draft is sent to ccamp and should not specify what a PCE node
> has to do.
>
> - This is especially confusing since you say that a PCE is
> receiving RSVP Path error messages. This implies somebody
> sent it to the PCE. But you have defined communication from
> the node where shutdown occurs to the ingress.
> How does the PCE know about this message?
Via PCC,
There are places where document lists set of roles that any entity computing
a path should follow, i.e., Ingress node, intermediate nodes performing ERO
extensions or PCE. Certainly specification of (related) PCE-PCC
communication is beyond the scope of this document and in the revision we
have clearly stated that.
>
> - You talk in the draft about FRR but FRR does not apply to
> all types of switching in GMPLS. Please reflect that in your
> text to say: "In the case of PSC, ..."
Done,
>
> - You mention FSC, LSC and PSC. Is it your objective not to
> address L2SC and TDM?
No, nothing intentional to avoid L2SC, TDM. We have modified the text
accordingly.
>
> - I'd also like to ask you how you decommission a bundle?
> Does the headend of that bundle have the responsibility of
> telling each headend of each component about the shutdown?
Yes, and ID talks about this. When all component links of the bundle are
being decommissioned, its like graceful shutdown of a TE link. However, if
only a subset of component links are decommissioned, procedure for graceful
shutdown of the component links applies (as listed in section 4.2 of the
last version of the ID).
> E.g. let's say I'm shutting down a link in a SONET box that
> has a server-layer circuit (say an STS-3c) that is carrying
> Ethernet as the client layer. Who tells the Ethernet
> "headend" about the shutdown?
The box/ node upstream to the link under graceful shutdown. I.e., the box/
node which is using the link under graceful shutdown as an Egress link for
the affected flows.
>
> > -----Original Message-----
> > From: owner-ccamp@ops.ietf.org
> > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Zafar Ali
> > Sent: Tuesday, February 15, 2005 10:34 PM
> > To: 'Adrian Farrel'; ccamp@ops.ietf.org
> > Subject: Summary [was: RE: Starting a discussion on
> graceful shutdown]
> >
> >
> > Hi Adrian,
> >
> > Thanks for putting this email together. In the following I
> have tried
> > to summarize the discussion we had on this thread and next steps.
> >
> > Thanks
> >
> > Regards... Zafar
> >
> > > -----Original Message-----
> > > From: owner-ccamp@ops.ietf.org
> > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel
> > > Sent: Tuesday, December 07, 2004 10:39 AM
> > > To: ccamp@ops.ietf.org
> > > Subject: Starting a discussion on graceful shutdown
> > >
> > > Hi,
> > >
> > > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-grace
> > > ful-shutdown-00.txt was discussed at the meeting in
> Washington DC,
> > > and one of the questions raised was whether or not we already had
> > > (multiple!) mechanisms capable of performing the function
> described
> > > in the draft.
> > >
> > > Kireeti quite rightly suggested that we step back and
> make sure we
> > > understand the requirements. This is my take on those
> requirements
> > > and I would appreciate it if the authors of the draft
> joined in and
> > > other people on the list commented.
> > >
> > > We wish to manage a link that needs to be taken out of service in
> > > some way (data plane and/or control plane will be disrupted). The
> > > link concerned has active LSPs and we wish to offer upstream LSRs
> > > (in particular the ingress) the opportunity to use
> make-before-break
> > > to re-route the LSPs.
> > >
> > > In order to achieve this, we need to communicate to the upstream
> > > nodes. Should we choose signaling or routing? Are there benefits
> > > that mean we should use both, or should we limit to just one?
> >
> > Yes, we need both.
> >
> Can you explain to me the justification for both?
> I don't think there is no need for routing extensions, since
> the routing protocol will stop advertising decommissioned links.
>
> Can you also explain the difference between your method and
> the available SONET mechanisms for shutting down resources?
>
> In section 4, you talk about OSPF/ISIS. Do you mean OSPF-TE/ISIS-TE?
>
> > >
> > > There is another aspect to be considered. Should we also
> attempt to
> > > protect new path computations from selecting the link
> that will be
> > > taken out of service?
> >
> > Yes,
>
> There is a balance between (1) telling ingress LSR's vs. (2)
> ingress LSR's receiving notification through usual updates.
> Authors need to justify need and advantage for (1).
> >
> > >
> > > How should we consider the case of a node (data plane
> and/or control
> > > plane) being taken out of service?
> >
> > Yes,
> >
> > >Is a node simply a
> > > collection of links?
> >
> > Yes, during graceful shutdown period.
> >
> > >
> > > If a component link of a bundle is being taken out of
> service (and
> > > assuming other component links are available) is this
> just an issue
> > > for the adjacent nodes or does it need to be communicated more
> > > widely?
> >
> > Let head end do the mb4b,
> >
> > > If the downstream node decides to
> > > take the component link out of service, how does it inform the
> > > upstream node?
> > >
> > > Does it matter whether it is the control plane or the data plane
> > > that will be taken out of service?
> >
> > Yes, if data plane is going OOS, we are loosing traffic and
> motivation
> > behind mb4b to reduce traffic hit is lost.
> >
> > >
> > > Opinions please.
> > >
> > > I would like to see these issues and their answers
> captured clearly
> > > in a requirements section of any draft. Would the authors of
> > > draft-ali-ccamp-mpls-graceful-shutdown-00.txt
> > > be willing to take that on even though the end result
> might be that
> > > procedures other than those they suggest will be selected?
> >
> > Sure, we plan to revised the ID based on this survey as well as
> > comments from the WG for the upcoming IETF.
> >
> > Thanks again Adrian for your suggestion and putting this together.
> >
> > Thanks
> >
> > Regards... Zafar
> >
>
> > >
> > > Adrian
> > >
> > >
> >
> >
>