[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Summary [was: RE: Starting a discussion on graceful shutdown]
Hi Adrian,
This time it's crystal clear on what you were referring to
in your comments. Please see my reply in-line.
Thanks
Regards...
Zafar
Hi,
Thanks for answers. Snipped down to just one
point.
> > > > 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.
> >
> > Let me rephrase the question.
> > If I know that the
control plane is going OOS and I want to
> > continue to be able to
manage my LSPs I will want to move
> > them to LSRs that will
continue to have an active control
> > plane. The data plane through
the impacted LSRs may continue
> > to be active (and therefore could
continue to carry traffic).
>
> I am not sure if I understood
your comment completely. However,
> the ID mentions about Grace Period
and Removal of data plane
> associated with the LSP under mb4b.
I'll try again.
The draft talks about cases where the data
plane is going to be removed. No problem there.
I am asking about cases where we know that the
control plane is going to be removed, but where we know that the data plane is
going to stay up.
Examples include:
- going to take the software components down
(perhaps for upgrade)
- going to remove the control plane CPU (to
replace it, dust it, or fit nerw tires)
- going to take down the control channel
(e.g. decommission the OSC laser)
Yes, most
certainly, this is one of the motivations behind this draft. In fact
the -00 version of the ID had
following statement in the Introduction section.
"a Service Provider may desire to gracefully (temporarily or definitely)
remove a TE Link, a group of TE Links or an entire node for administrative
reasons such as link maintenance or LSR software/hardware
upgrade. "
The
revised version of the ID (-01), already in draft queue have this as one of the
main requirements.
" - Graceful shutdown mechanisms are applicable to
removal a TE
resource (e.g., link, a group of TE Links or an
entire node). Trigger
for the graceful shutdown event is a
local matter at the node
initiating the graceful shutdown.
Typically graceful shutdown is
triggered for administrative
reasons, such as link maintenance or
software/hardware upgrade at a node.
"
In these cases, we have put a lot of
effort into GMPLS to ensure that the LSP is capable of continuing to exist
even when the control plane is down.
Certainly, but as you know these
are for unplanned outages, aka graceful restart (GR) mechanisms. This ID talks
about planned outages: Graceful Shutdown (GS), like to one you mentioned
above.
I am asking whether we want to give the ingress
due warning that the LSP is about to enter this state (i.e. data plane
up, but control plane disconnected). The reason why the ingress might be
interested is that, once in this state, the LSP is not fully
manageable.
An option is to provide an error value
that says "Data plane OK, but control plane about to go away". This would
allow the ingress to re-route (mb4b) if it cared.
The
ID assumes that Graceful Shutdown mechanisms are agnostic to control vs. data plan reasons for the planned outage. IMO we don't
need specific codes for one vs. the other failure. Do you or anyone else feels
that we need to have different cause code for the data vs. control plane
failures (for e.g., some admin reasons).
So the question for you and the WG
is: Is this an important case?
Yes, as mentioned above.
Does the ingress ever care about this
loss of control plane connectivity?
Yes, for the reasons you listed
above, e.g., software upgrades.
Cheers,
Adrian