RE: no more milestones?

[<neil.2.harrison@bt.com>]

Thanks Adrian,
> 
> Hi Neil and Tom,
> 
> >> There are for instance, ops/management-related items
> >> for "base" CCAMP items that need to be worked on.  The 
> question for 
> >> me is why can't we continue to work on these?  I thought 
> these things 
> >> were automatic chartered items, and thus should be ongoing work 
> >> items.
> >
> >You are right Tom to raise the point about the importance of network 
> >management here.  When we are dealing with large BW 
> granularity co-cs 
> >mode technologies then virtually all the really important issues are 
> >concerned with the efficacy of the management-plane solution....the 
> >control-plane plays a minor support role (for a whole raft of 
> >technical/commercial/operational reasons). This is of course 
> quite the 
> >opposite to a cl-ps layer network like IP.  We look to TMF for 
> >expertise here in developing the required management 
> information models 
> >which are based on functional architecture.
> 
> I think you are right, Neil, that we would largely look 
> outside the IETF for management plane solutions.
NH=> I know some folks must think 'why does he keep banging about stuff
like functional architecture, 3 network modes, client/server
relationships,  etc'....well, its for sound practical reasons, and one
of them being the importance of the management information models we
operators need if we are going to get the right equipment specifications
and maximally effective downstream NMS/OSS.  These facets can only be as
good as the base networking specification of the data and control
planes, ie if these violate architectural rules of the mode concerned or
have functional deficiencies then no amount of effort/money subsequently
thrown at the management piece can really recover the situation.  And
speaking as an operator I am very concerned about whole-life costs and
this is why the above stuff is important to me......esp noting there is
a significant time-constant between cause and effect, so its often very
easy to make mistakes early on that don't become apparent wrt
implications until several years later.....and then its invariably too
late to fix easily.

So if there is one key message I'd like folks to get it's this:  We must
strive to get the networking aspects of the data-plane and control-plane
right/complete for the mode we are considering from t=0....if we don't,
the NMS/OSS folks who pick this up later cannot recover the situation.
Folks involved in any aspect of networking (esp those creating
standards) should therefore try and make the effort to better understand
functional architecture stuff. 
> 
> What Tom is referring to, of course, is the management 
> aspects necessary as part of the control plane solutions. 
> Aspects such as MIB modules, PIBs, OAM etc.
NH=> Understood and agreed Adrian.....and I'm glad to note here you
mention OAM as a 'for instance' here.  This is a good example of what I
was referring to above, ie this needs to be an integral part of the
trail's characteristic information specification at t=0.  Some folks may
remember that ~3-4 years ago I spent a futile year or so trying to
convince the MPLS crowd that they must consider this aspect AND that it
must not be proxied by a control-plane solution (this becomes very
obviously true when the data-plane and control-plane protocols run on
logically distinct layer networks within the SAME networking system, as
indeed they are forced to in the co-cs mode).  However, I should also
mention that if one breaks the connectivity rules of the co mode (ie
merging as we find with LDP and PHP in some spins of MPLS) then there
are no good/simple solutions to OAM/fault management (or indeed traffic
or performance management).....this is just a consequence you now have
to accept and live with.
> 
> I'm sure that I don't have to remind you that GMPLS is a 
> control plane technology not a data plane technology. The 
> applicability of GMPLS is to any co data plane technology and 
> therefore it embraces both co-cs and co-ps.
NH=> No you don't have to remind me of this.....and you are mentioning a
really important thing here that, if I may, I'd like to amplify a
little:

-	all technologies map to one of the 3 networking modes.....the
exact behaviour of a given technology is then dependent on
well/completely it is functionally specified for its target environment,
and how well it respects modal networking constraints.  In terms of what
this means practically, then (i) it makes huge amounts of sense to seek
convergence within each mode but it is not sensible to think exactly the
same approach can be applied across all 3 modes, and (ii) each mode has
very important behavioural differences that we should seek to exploit as
these are the key to addressing what are otherwise very hard networking
problems.  {Aside - There is actually a unifying model based on
Shannon's Information Theory which brings the G.805 (co) and G.809 (cl)
func arch perspectives together which one of my colleagues is working on
(paper to be issued later this year), but in terms of what we see
manifested we simply need to note that its these differences that are
the key to tackling some otherwise very hard networking problems in the
areas of QoS/performance-inheritance/pricing/complexity/etc
management....I gave some hints on this in the thread 'End-to-end
L2-LSP' 15 July 05.}

-	the major difference between GMPLS and MPLS is, as you correctly
observe Adrian, that no data-plane structures have been specified for
the former in IETF whereas they have for the latter (and it is this that
is the source of the problems for MPLS as-is...we could actually fix
these if there was the will to let go of a few misplaced beliefs.....but
I am not sure that there is that will given how far some of this stuff
has now gone).

-	unlike the co-ps mode the co-cs mode is rather 'self-protecting'
of abuse, ie its very difficult to do bad things to it even if you
try....and the reasons why this is so is hidden-away in the underlying
Information Theory constraints of what 'labelling' means in this mode
(see also my rather detailed response to Igor Bryskin of recent,
'Network modes and layer network relationships' 13 July 05, which
explains why one can't have a single control-plane running 'IP to
Optics').  So in the co-cs mode:  OOB control/management is forced,
there are no 'QoS classes', we can always have proper client/server
functional decoupling (subject to my observations wrt the nonsense of
'topology on the fly', etc) one cannot merge co-cs trails and of course
trail must go from source to sink (ie can't prematurely stop at the
wrong place).  There are also some interesting consequential issues wrt
performance inheritance in nested client/server layer network
relationships if one thinks any mode can arbitrarily support any other
mode (eg PWE3 stuff).

-	it ought to be somewhat intuitively obvious that its a good idea
to try and re-use the same base control-plane components/design for the
co-ps mode as the co-cs mode.  And this is one reason (there are
actually lots of reasons) why I am supportive of the folks who also
advocate this view.....and I think you share this view Adrian.

regards, Neil
> 
> In answer to Tom's question, we are not prohibited from 
> working on these things, but we are rather adrift without any 
> milestones. i would certainly say that the right place to 
> bring drafts for discussion is the CCAMP list.
> 
> However, before committing the WG to any specific drafts the 
> chairs need to be guided by an up-to-date charter with real 
> milestones. I do hope that the discussions in Paris will lead 
> to these so that we can get on with the work that everyone is 
> so keen to do.
> 
> Cheers,
> Adrian
> 
>