RE: Comparison of restoration requirements between transport and packet networks

["Vishal Sharma" <v.sharma@ieee.org>]

Hi Neil,

Thanks for your note. A few follow-up comments in-line.

Regards,
-Vishal

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> Behalf Of neil.2.harrison@bt.com
> Sent: Friday, September 19, 2003 9:36 AM
> To: v.sharma@ieee.org; rabbat@fla.fujitsu.com; ccamp@ops.ietf.org
> Subject: RE: Comparison of restoration requirements between transport
> and packet networks

<snip>
> > So would you agree that if one looks at the "classical" client/server
> > layer relationships, the notion of notification time bounds
> > makes sense?
> NH=> Yes in principle.....the basic rule is 'as fast as sensible, as close
> to the duct as possible;  as slow as reasonable, as close to the
> application
> as possible'.

Great. We have also been postulating that the exact time bounds would
depend on the carrier providing the transport, inter-carrier agreements,
applications supported, etc. However, the notion of providing time
bounds seems to us also to be a sound one.

> > For (ii), when a carrier has no visibility into the
> > server layer,
> NH=> very common

Thanks. I would expect though that in this situation, there
must surely be inter-carrier agreements between the carrier owning
the server layer and that having the client layer. Otherwise,
it would seem to be very difficult for carriers to plan service.
Yes?

> > it seems to me that it is perhaps _even more
> > important_ that
> > the server layer guarantee notification timing bounds (and,
> > by extension,
> > some
> > reasonable protection switching timing bounds), so that these
> > can be built
> > into the SLAs that the client-layer provider and server-layer provider
> > sign with each other.
> NH=> Nice idea in principle...and if there are only 2 parties
> involved where
> the 'server' party owns all layers to the duct it might work.  However, it
> does, as you noted previously, require some notional agreement on the
> 'allowed' X/Y client server relationships.

Actually, the idea works even if this recurses. That is, there is nothing
in principle from preventing such agreements between pairs of carriers,
owning different (adjacent) network layers.

However, there would obviously be some practical limits to how far
this can recurse.
Perhaps you (and some other carrier experts) can shed some light on
how many carriers are typically involved in such a client-server situation?
In other words, how deep does such a recursion run, on average?

> > This would allow the carrier operating the client layer to make some
> > definite assumptions about the reaction time of its server layer, and
> > build its service based on that.
> >
> > The notification work, in fact, makes no assumption that the
> > same carrier
> > has to have control of the complete layered network.
> >
> > Hope this helps to clarify a bit the thinking behind the notification
> > work.
> NH=> Yes.....but your call (with Richard) today explained a piece of the
> puzzle I had not properly appreciated until then.....and that is you are
> postulating a case where the *protection route* between 2 nodes, A and B
> say, carries 'extra' traffic that is from >=2 disjoint trails, eg extra
> traffic trail 1 say A->N->O, and extra traffic trail 2 say
> O->P->B......and
> this is why you need to inform (at least) node O of the failure on the
> working path (to co-ordinate removal of the 2 extra traffic trails).
> Clearly FDI/BDI would tell A and B from the failed working path.

Indeed. We have been postulating a shared restoration model, where the
sharing is possible all the way from 1:1 restoration to more general
M:N restoration.
The moment we allow for that, and the nature of the transport trails
(which requires that the switches en route not be cross-connected a priori),
we need a way to inform the intermediate nodes on the protection path (node
O
in your example above) of the failure on the working path, so they can
reconfigure themselves.

We will make this clearer in an applicability statement and in the
document (we're working on) that explains the expedited notification ideas
in an
implementation independent way.

> I guess providing the extra traffic once 'dumped' stays dumped the system
> ought to be stable.  I am not in favour of multiple class
> pre-emption/bumping schemes.

Thanks for the observation, glad to hear that.
Actually, the draft on the notification protocol neither
proposes(nor rules out) complex bumping/pre-emption schemes. As you observe
(and
I agree with you), it does seem practical for a carrier using extra-traffic
to
not have a pre-emption setup that is susceptible to a domino effect.

We will also call this out in the applicability statement.