Subject: Re: no more milestones?

From: [email-masked]
Date: Mon, 18 Jul 2005 21:20:39 +0200

tom -

it seems to me to be the right time to wrap up and look after the base operation mechanisms to be put in place for the first phase of base GMPLS deployment as well - and leave the more advanced mechanisms to  "CCAMP-ING" like-WG(s) as indicated in a previous e-mail -

it is indeed difficult to understand why this is not coupled to the base protocol development as MIBs are otherwise GMPLS will appear like a wonderful and powerful toolbox developed by the IETF but without the appropriate user manual

i would nevertheless add we have also a strong need for more operational feedback otherwise the user manual will treat more about "how development community sees network operations" rather than practice "which mechanisms development community has to consider to meet user community needs" ... a way to achieve this is would be to "invite" the broad user community to express their views and concerns in terms of GMPLS deployment this may take the form of a survey ?

"Thomas D. Nadeau" <[email-masked]>
Sent by: [email-masked]
07/18/2005 09:06 AST

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: "Adrian Farrel" <[email-masked]>, <[email-masked]>, <[email-masked]>, "Bill Fenner" <[email-masked]>
bcc:
Subject: Re: no more milestones?

On Jul 18, 2005, at 9:00 AM, [email-masked] wrote:

>
> hi adrian
>
>
>> I would like to see:
>> - a refinement of the charter to focus the next work items
>> - a year's worth of milestones to ensure we stay focused.
>>
>> On the other hand, we should aim to close down CCAMP and move the
>> work to
>> other or new working groups.
>>
>
> coupling both sentences does it mean in your view
>
> 1) define several short-term milestones for refining topics that
> have been
> already initiated and requires further well scoped attention
>
> 2) (brand) new topics should target new working groups - as already
> initiated with L1VPN for inst. - or existing working groups
>
> nevertheless, i do not see why this automatically means CCAMP can not
> remain the focal point concerning *base* GMPLS signaling and routing
> protocols

I agree. 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.

--Tom

> thanks,
> - dimitri.

---

From: <[email-masked]>
Date: Tue, 19 Jul 2005 09:36:18 +0100

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
> 
>