RE: Comparison of restoration requirements between transport and packet networks

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

Neil,

Thanks for your explanation. I now understand better what you
were saying, and have some clarifications that I think may better
explain where the notification work sits.

-Vishal

> -----Original Message-----
> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
> Sent: Wednesday, September 17, 2003 3:22 PM
> To: v.sharma@ieee.org; rabbat@fla.fujitsu.com; ccamp@ops.ietf.org
> Subject: RE: Comparison of restoration requirements between transport
> and packet networks
>
>
> Vishal.....wrt to your question (snipped to it).  regards, Neil
>
> > > NH=> A laudable aim....but it will never be possible to set
> > hard bounds
> > > *unless* we fix the hierarchical client/server relationships for
> > > ever.  Let
> > > me give you and example for you to answer wrt to the activities
> > > in the PWE3
> > > group.  What is the protection speed requirments for
> > SDHoverMPLS in the
> > > client (SDH) and server (MPLS) case?  And now extend this to some
> > > arbitrary
> > > nested client/server stack where one operator may not own the
> > > layers below a
> > > certain point (and which he has no visibility of).......so what
> > > is there to
> > > control 'which' and 'how many' client/server transitions
> > exist below here?
> >
> > Perhaps a clarification here. Do you mean that client/server
> > relationships cannot be fixed for ever (because of structures
> > like SDHoverMPLS) or do you mean that SDHoverMPLS shouldn't be
> > defined?
> NH=> There are 3 network modes....cnls, co-ps and co-cs.  These have 9
> possible client/server permutations.  Some make far more sense
> architecturally than others.  I would *not* wish to be
> prescriptive on this
> if some people want to do 'odd things'.

Your characterization of network modes is certainly v. useful, but,
as you observed in your previous email, the focus of the notification
work is really at the transport/OTN network controlled by an IP
control plane.

Thus, how client layers recurse atop it (while an important topic), is
outside the scope of this work.
The reasonable assumption has to be that the provider (or
providers) setting up working relationships to use the transport
network would have to have thought about this during the service
planning exercise.

> However the point I was
> making was
> simply this....at some layer network one may not have
> control/sight of which
> lower layer trails support your link-connections.....and this behaviour
> recurses (ie link-connections in layer N are created by trails in
> layer N-1)
> to the duct.  So if (i) there is no control over the client/server
> relationships and (ii) one may not have control or visibilty of
> this anyway
> (ie leased capacity) then how can one set any sort of meaningful prot-sw
> timing bounds between layer networks?  The simple example I was giving was
> trying to illustrate this, eg assume SDH is designed to act
> faster than MPLS
> (because SDH is always assumed to be a lower server layer to
> MPLS) then what
> does this mean when carrying an SDH layer network over MPLS wrt to the
> prot-sw speed of the MPLS layer now?

In response to the two numbered points above:

For (i), I agree that if there is no control over client-server
relationships,
then prescribing timing bounds is difficult. However, a reasonable
assumption here would have to be, again, that the provider(s) setting up
the network and service would have (or impose) some control over what
client/server relationships they choose to allow in their network.

In that case, it seems to me that it makes a lot of sense for a client
layer to have some definite guarantees of how long its server layer will
take
to act in response to a legitimate fault (excluding self-correcting faults).

So would you agree that if one looks at the "classical" client/server
layer relationships, the notion of notification time bounds makes sense?

For (ii), when a carrier has no visibility into the
server layer, 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.

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.