Subject: RE: Re: I-D ACTION:draft-martini-pwe3-MH-PW-requirements-00.txt

From: David McDysan <[email-masked]>
Date: Tue, 01 Feb 2005 12:10:37 -0500

Neil,

Good to see that the thread is now related to (general) requirements.

A few responses in line below trying to get to more specifics relevant to
the subject at hand.

Regards,

Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Friday, January 28, 2005 5:22 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [PWE3] Re: I-D 
> ACTION:draft-martini-pwe3-MH-PW-requirements-00.txt
> 
> 
> Tom...
> 
> Wrt your mail 28 January 2005 06:49
> 
> <snipped>
> > >
> > > If you mean using (something like) VCCV to confirm data plane 
> > > "liveliness" state of the PW and comparing this with the state 
> > > determined by the control
> > > signaling protocol then I agree. I think there are some additional
> > > requirements related to MH-PW that were mentioned on this 
> > thread that
> > > relate
> > > to being able do this on a SH PW segment basis of a MH PW
> > in support
> > > of at
> > > least diagnostics and also performance measurement that I believe
> > > should be
> > > stated as a requirement.
> > 
> > 	This is something we should talk about when we
> > can get together next (with Luca).  We figured out
> > how to do a lot of this already, just haven't
> > released it.
> > 
> > 	--Tom
> NH=>  Well, I'm not convinced this has been 'figured out' to 
> what I think are the key requirements to be met.  Let me list 
> some and you can tell me how well they are satisfied:
> 
> 1	In any client/server relationship (and PWs are for sure this)
> one wants the management of the server to be independent of 
> the client.....so that we can use the same (server) 
> processing in all cases. Note functional 
> re-use/simplification is a key goal to reduce complexity and 
> opex (noting this plays through from NE to NMS/OSS efficacy).  

As mentioned before, an Annex translating G.805 terminology to relevant IETF
terminology would be helpful. Approved documents communicate a message
better than Email archives. My translation of the above is: MH PW management
should be independent of PSN tunnel management.

> 
> 2	In any client/server relationship the most basic requirement of
> all is client (all planes) transparency over the server....or 
> putting it another way, complete functional decoupling of the 
> client and the server layer networks (this is NOT a specific 
> OAM issue of course, its the most basic yet most important 
> network arch requirement per se, but it does impact OAM).

I need some help translating this one.

> 
> 4	There are 2 major types of OAM:  (i) 'always on' defect
> detection/handling and (ii) 'on-demand' diagnostics, PM.  The 
> former must be sorted before we can sensibly consider the 
> latter, and the former must be simple/complete.....noting 
> that the requirements to be met are NOT identical for each 
> network mode.
> 
> 3	The defects that can affect each of the 3 network modes are
> different.  If we are dealing with MPLS as the server there 
> should be breaks, swaps and mismerging defects specified in 
> terms of clear entry/exit criteria and consequent 
> actions....see next item.
> 
> 4	Defect detection/handling needs to be in the traffic data-plane
> and unidirectional.  In particular, consequent actions need 
> to be taken at the trail sink.  This is vital so that p2p and 
> p2mp constructs can be handled similarly/scalably.  2 key 
> consequent actions (if the client is
> co) are (i) traffic suppression and (ii) FDI insertion to 
> stop alarm storms.  The precise syntax of FDI depends on the 
> client technology.
> 
> 5	The activation/deactivation of the defect detection/handling
> aspects of OAM must be done in concert with however the trail 
> is set-up/taken-down (this can be via signalling or management).
> 
> 6	Before we can progress to PM we must have a clear definition of
> the available state...as PM measurements (at least for any 
> SLA purposes) are only valid when the trail is in the available state.
> 
> Note - Defects, availability and PM need to be standardised 
> in order to have a common basis of specification for 
> interworking and apportionment (of impairments) to tandemed 
> operator domains.
> 

Is there anything incorrect or missing from section 6.6 of
draft-martini-pwe3-MH-PW-requirements-00.txt?

> 7	If either direction of a bi-directional trail enters the
> unavailable state any PM measurements should be stopped for 
> both directions.
> 
> 8	It should be possible to observe the defect/availability status
> of both directions from a single end.
> 
> Note that Y.1711 was designed to meet the above requirements 
> wrt basic defect detection/handling in the most simple way 
> possible IMO.  The above are not rocket-science nor are they 
> unreasonable IMO....in fact I think they are rather simple 
> and obvious requirements.  Can you assure me that all these 
> requirements can be met with some alternative OAM proposals?

draft-ietf-pwe3-oam-msg-map-01.txt does not specify Y.1711 but specifies LSP
Ping instead. IMO, Y.1711 does not provide a means to communication
detection of defects and associate them with the control protocol signaled
PW or PSN tunnel. 
 
> 
> Maybe Dave doesn't care about some/any of this in his 
> network....maybe others don't either, and I must admit I have 
> been rather disappointed with the inputs (mainly lack of) 
> that I have seen other operators on the topic of OAM in 
> general in this forum.  

To me it is a matter of practicality and priority. Coordinating control,
data and management is important in many services, and I do not believe that
approaching them independently is a good architectural approach. Control
protocols have detected a majority of faults in packet networks
(connectionless and connection-oriented) for decades. Additional OAM
protocols could detect some additional faults that control protocols do not.
In my experience with packet networks these OAM protocols would have
detected faults that the control protocol and would have reduced
unavailability on the order of 10^-6, if they were available. 

> This does seem to be a persistent 
> malaise of the operator community that they only seem to 
> get-wise about stuff like OAM 'after the event'...when its 
> usually too late to do much about it.  OAM considerations 
> should not be some afterthought, they should be designed-in 
> to the architecture from t=0.

The approach I prefer is to first (t=0) agree on the requirements of what is
to be done and then decide on the appropriate management approach at t>0. 

> regards, Neil

---

From: [email-masked]
Date: Wed, 2 Feb 2005 18:36:45 -0000

Dave....Thanks for the response.  But I'm not really sure where this is
heading as I believe there is a fundamental mismatch of
views/understanding of what network architecture is and why it is
important.  
<snipped to main points>

> > one wants the management of the server to be independent of the
> > client.....so that we can use the same (server) processing in all 
> > cases. Note functional re-use/simplification is a key goal to reduce

> > complexity and opex (noting this plays through from NE to NMS/OSS 
> > efficacy).
> 
> As mentioned before, an Annex translating G.805 terminology to 
> relevant IETF terminology would be helpful. Approved documents 
> communicate a message better than Email archives. My translation of 
> the above is: MH PW management should be independent of PSN tunnel 
> management.
NH=> Close in terms of what is required but sadly not possible.  You see
MPLS is a digital wrapper.  When we create a hierachy in MPLS all the
stacked LSPs belong to the same layer network. I have explained why this
is true before and why its a serious problem (MH PWs are simply exposing
it....trying to do client/server between operators will also expose it).
I can't translate G.805 to IETF arch because there isn't one.....not
that I think the effort would bring any benefit anyway
(wheel-reinvention). 
> > putting it another way, complete functional decoupling of the client

> > and the server layer networks (this is NOT a specific OAM issue of 
> > course, its the most basic yet most important network arch 
> > requirement per se, but it does impact OAM).
> 
NH=> OK....but its rather obvious, so please excuse me if it sounds like
I am teaching egg-sucking.  Suppose I want to build some layer
network...let's say an IP layer network though the choice of layer
network is incidental.  So I buy a load of routers say.  I'm going to
lease capacity of a several operators to connect these routers together.
I don't really care what technology each of them uses just so long as it
gives me the required BW, has reasonable delay/loss/errors and does not
fail very often (be nice to have SLAs, but that needs OAM, consistent
metrics, etc and I note you feel this is not important later).  I have
no interest in sharing any of my addressing, routing, whatever with any
of these operators.....in fact its a strong commercial/operating
requirement that I don't (and I can change suppliers at will this way).
Each link-connection (ie the thing that connects adjacent nodes in my
network) is provided by a trail (ie an end-end path) from some operator
in some technology....could be FR on one link, ATM on another, SDH on
another, PDH on another....can't be MPLS *directly* of course as MPLS
does not do a network builder service per se because its a digital
wrapper (though it carries others, ie I could get a 'ATM server trail
over a PW' say...as this terminates the wrapper behaviour).

This is the essence of G.805, ie client/server functional
decoupling....its also the essence of the phrase 'IP over everything'.
Indeed this phrase is *ONLY* true because we adopt a G.805 attitude to
client/server relationships and don't going screwing around with the IP
layer client.  So my network has absolutely no functional relationship
with any of the operator's networks from whom I lease capacity.  This is
the fundamantal essense of a network builder service and it is (and will
always be) a key service capability requirement for all major
operators....I suspect if you talk to your products guys they might have
a similar view on this too.  Hope that is clear now.
> > detection/handling and (ii) 'on-demand' diagnostics, PM.  The former
> > must be sorted before we can sensibly consider the latter, and the 
> > former must be simple/complete.....noting that the requirements to 
> > be met are NOT identical for each network mode.
> > 
> > different.  If we are dealing with MPLS as the server there should
> > be breaks, swaps and mismerging defects specified in terms of clear 
> > entry/exit criteria and consequent actions....see next item.
> > 
> > and unidirectional.  In particular, consequent actions need to be
> > taken at the trail sink.  This is vital so that p2p and p2mp 
> > constructs can be handled similarly/scalably.  2 key consequent 
> > actions (if the client is
> > aspects of OAM must be done in concert with however the trail is
> > set-up/taken-down (this can be via signalling or management).
> > 
> > the available state...as PM measurements (at least for any SLA
> > purposes) are only valid when the trail is in the
> available state.
> > 
> > Note - Defects, availability and PM need to be standardised in order
> > to have a common basis of specification for interworking and 
> > apportionment (of impairments) to tandemed operator domains.
> > 
> 
NH=> I must say Luca (and Nabil) have done a pretty good job in
capturing many of the requirements.  Where it all starts to fall apart a
bit however is when we get down to hard specifications and look at the
base arch of the technology we are dealing with.  Let's take the latter
point 1st:
-	Some spins of MPLS don't have any good OAM solutions at all, ie
LDP mp2p and PHP....these create a merging behaviour for which it is
simply not possible to specify any meaningful defect conditions/actions.
So I have to put these aside in a 'special' category;
-	Then we have some missing functional components.  For example an
OOB control/management plane ought to be an almost no-brainer
requirement in a carrier grade network for several reasons (its forced
in GMPLS, but that is property of the co-cs mode and its nmot a
conscious design decision).  This creates some important relationships
between the control-plane protocols and the traffic data-plane that have
to be dealt with.  Further, we don't have any consistent way of
addressing LSPs.  I'll come back on this shortly in the context of BFD
and the CV pkt of Y.1711.
-	Then we have the OAM indicate function.  The OAM pkts should
look just like traffic pkts between trail source and sink points and the
OAM should be the same no matter what the client is.....this is required
so that we can get as close as possible to monitoring what is happening
to the traffic, and we can use exactly the same processing in all cases.
This should have required 1 bit of the header (8 bits for TTL in a co-ps
technology that should not even need this is a bit wasted IMO).  Instead
we have to resort to kludges like adding an extra reserved label, or
using the CW or router alert in the case of PW clients.   
-	Finally we have the wrapper and its related issue of 'topology
on the fly'.  I have explained this in detail in past posts.  I actually
think this is the biggest problem with MPLS as this cannot be
fixed....whereas the others could with the right will.

Now let's look at some of the hard specification requirements.  If we
want to interoperate we ought to start with a basis of agreed defect
entry/exit criteria and consequent actions.  OK, we know we have to dump
LDP mp2p and PHP at this point as these create a merging behaviour that
cannot be specified in any meaningful manner.  So assuming we can only
have p2p and p2mp constructions let's look at their defects.  Breaks,
swaps, misbranching/mismerging.  If we are going detect these in a
consistent manner we need the same OAM on all LSPs.  Not only that
however, we need the same SA (Source Address) used in the CV function.
This is required in Y.1711.  Let me now contrast that with BFD.  This
uses a locally generated dicriminator field that looks a lot like a SA
CV function.  But as far as I understand it BFD only looks for
'expected' discrimiator fields and ignores any 'unexpected' ones...so it
can't detect swaps or misbranching/mismerging.  I also do not believe
any FDI is specified in BFD nor is there a requirement for traffic
suppression if dealing with any co mode clients.  Further, being a local
code the disciminator would not have immediate network relevance, ie is
it obvious where an offending traffic stream was sourced from?  Being a
bi-directional protocol its not clear how BFD would easily adapt/scale
to p2mp constructions either.

> > unavailable state any PM measurements should be stopped for both 
> > directions.
> > 
> > Note that Y.1711 was designed to meet the above requirements wrt 
> > basic defect detection/handling in the most simple way possible IMO.

> > The above are not rocket-science nor are they unreasonable IMO....in

> > fact I think they are rather simple and obvious requirements.  Can 
> > you assure me that all these requirements can be met with some 
> > alternative OAM proposals?
> 
> draft-ietf-pwe3-oam-msg-map-01.txt does not specify Y.1711 but 
> specifies LSP Ping instead.
NH=> Think it rather majors on BFD.  BFD is a Y.1711 lookalike (has to,
functional requirements are the same) for the simple 'always on' OAM
bit....LSP-Ping however is a 'on demand' diagnostic tool IMO.  So I
think you are making the wrong comparison here.

> IMO, Y.1711 does not provide a means to communication
NH=> Quite right....nor should it, as the OAM needs to be the same
whether signalling protocol X, Y or Z or NMS set up the trail.  The OAM
should be the same in all cases, and it primary task it take executive
action in the data-plane.  Of course one can then inform the
control-plane of this to effect prot-sw say.  So not sure what your
point is. 
> unavailability on the order of 10^-6, if they were available.
NH=> Hmm...seems not to tie up what what Tom say in earlier mail across
a sample of operators.  Misconfiguration problems can be human, HW or SW
in origin.  But if what you say is true however, then what do we need
BFD for either?  And why is there all the efforts we see on OAM, not
just here but also in other technologies, eg ethernet?  Is your advice
to all these folks 'pack-up as you are all wasting your time'?
 
> to be done and then decide on the appropriate management 
NH=> But your requirements would seem to exclude OAM at the outset...as
you seem to think it is of little value.  This means it would never be
designed in from t=0.  It was this type of argument we heard in a BOF on
MPLS OAM a few years OK, ie you simply don't need it.  Seems experience
of real networks has changed this view for many.  But thank goodness we
never followed this line of reasoning when SDH was defined....a big
lesson learnt from PDH was make sure you design OAM right from the
start.  And its amazing how many folks now rely so heavily on the fact
we did this.  Indeed, one of the reasons SDH worked so well 'out of the
box' is that the OAM that was built into it allowed a great deal of
vendor debugging *BEFORE* we deployed it.

regards, neil

---

From: David McDysan <[email-masked]>
Date: Wed, 02 Feb 2005 14:56:54 -0500

Neil,

Thanks for taking the time to translate terminology and respond.

It appears that you want to discuss architecture and not specific MH-PW
requirements. In the context of MH-PW requirments, G.805 codifies SDH/SONET
and ATM experience - but I question whether this is the right approach for
IP-based networks. When interworking with TDM and ATM networks as in PW,
then I agree that G.805 principles are applicable for at least PW endpoints.

I hope that we can work toward supporting an architecture that uses an
IP-based set of control and management protocols as well as the G.805
architectural basis that you propose. In the past, I believe that "manual"
provisioning or configuration has been used to support the existence of more
than one architecture and operational model in vendor implementations and
operator networks. Possibly this is a way forward?

A few responses in line below with respect to MH-PW requirements.

Regards,

Dave

> Sent: Wednesday, February 02, 2005 1:37 PM
> To: [email-masked]
> Cc: [email-masked]
> Dave....Thanks for the response.  But I'm not really sure 
> where this is heading as I believe there is a fundamental 
> mismatch of views/understanding of what network architecture 
> is and why it is important.  
> <snipped to main points>

<snipped to points related to MH-PW requirements>

> stop alarm 
> > > storms.  The precise syntax of FDI depends on the client 
> technology.
> > > 
> NH=> I must say Luca (and Nabil) have done a pretty good job 
> in capturing many of the requirements.  Where it all starts 
> to fall apart a bit however is when we get down to hard 
> specifications and look at the base arch of the technology we 
> are dealing with.  Let's take the latter point 1st:

<Snipped (general architecture)>
> 
> Now let's look at some of the hard specification 
> requirements.  If we want to interoperate we ought to start 
> with a basis of agreed defect entry/exit criteria and 
> consequent actions.  OK, we know we have to dump LDP mp2p and 
> PHP at this point as these create a merging behaviour that 
> cannot be specified in any meaningful manner.  So assuming we 
> can only have p2p and p2mp constructions let's look at their 
> defects.  Breaks, swaps, misbranching/mismerging.  If we are 
> going detect these in a consistent manner we need the same 
> OAM on all LSPs.  Not only that however, we need the same SA 
> (Source Address) used in the CV function. This is required in 
> Y.1711.  Let me now contrast that with BFD.  This uses a 
> locally generated dicriminator field that looks a lot like a 
> SA CV function.  But as far as I understand it BFD only looks 
> for 'expected' discrimiator fields and ignores any 
> 'unexpected' ones...so it can't detect swaps or 
> misbranching/mismerging.  I also do not believe any FDI is 
> specified in BFD nor is there a requirement for traffic 
> suppression if dealing with any co mode clients.  Further, 
> being a local code the disciminator would not have immediate 
> network relevance, ie is it obvious where an offending 
> traffic stream was sourced from?  Being a bi-directional 
> protocol its not clear how BFD would easily adapt/scale to 
> p2mp constructions either.

Seems like the following are missing from section 6.6 for MH-PW
	- detect (unintended) PW label swaps
	- detect PW label merging (should not occur for pt-pt)

These "defects" could be due to implementation errors, but I agree that it
would be desirable to detect them.

> NH=> Think it rather majors on BFD.  BFD is a Y.1711 
> lookalike (has to, functional requirements are the same) for 
> the simple 'always on' OAM bit....LSP-Ping however is a 'on 
> demand' diagnostic tool IMO.  So I think you are making the 
> wrong comparison here.
> 

Yes, looked at the referenced draft again and it does focus on bfd for
always on OAM.

> > IMO, Y.1711 does not provide a means to communication detection of 
> > defects and associate them with the control protocol signaled
> > PW or PSN tunnel.
> NH=> Quite right....nor should it, as the OAM needs to be the 
> same whether signalling protocol X, Y or Z or NMS set up the 
> trail.  

As stated above, I hope this is something upon which we can agree. I will be
focusing on X=IP-based control protocols.

> The OAM should be the same in all cases, and it 
> primary task it take executive action in the data-plane.  

Not sure what is meant by "executive action in the data-plane" in the above.

> Of 
> course one can then inform the control-plane of this to 
> effect prot-sw say.  So not sure what your point is. 

I believe this is a fundamental gap in the G.805 based approach for networks
that have a control protocol. The determination of the set of link
connections that make up a network connection is not specified in G.805, and
my experience is that IP-like control protocols fill this architectural
void. IMO, being able to correlate the OAM state with the desired state
communicated via a control protocol is an essential requirement.

> NH=> Hmm...seems not to tie up what what Tom say in earlier 
> mail across a sample of operators.  

Consider this another input to that sample.

> Misconfiguration problems 
> can be human, HW or SW in origin.  But if what you say is 
> true however, then what do we need BFD for either?  

See section 2.1 of draft-raggarwa-mpls-bfd-00.txt (could not find updated
version). Looks like bfd wg has no current active drafts.

> And why 
> is there all the efforts we see on OAM, not just here but 
> also in other technologies, eg ethernet?  Is your advice to 
> all these folks 'pack-up as you are all wasting your time'?
>  

No, my point was that control protocols detect many defects. The events
where it did not were quite painful (even if they did not contribute greatly
to unavailability). Getting the control and provisioning part correct though
is a prerequisite to minimizing the effects of manual configuration errors
and handling the most likely failure modes. 

> NH=> But your requirements would seem to exclude OAM at the 
> outset...as you seem to think it is of little value.  This 
> means it would never be designed in from t=0.  It was this 
> type of argument we heard in a BOF on MPLS OAM a few years 
> OK, ie you simply don't need it.  Seems experience of real 
> networks has changed this view for many.  But thank goodness 
> we never followed this line of reasoning when SDH was 
> defined....a big lesson learnt from PDH was make sure you 
> design OAM right from the start.  And its amazing how many 
> folks now rely so heavily on the fact we did this.  Indeed, 
> one of the reasons SDH worked so well 'out of the box' is 
> that the OAM that was built into it allowed a great deal of 

Well, we are advancing both simultaneously in the MH-PW requirements draft.

---

From: [email-masked]
Date: Thu, 3 Feb 2005 08:49:48 -0000

Dave....
> It appears that you want to discuss architecture and not 
> specific MH-PW requirements.
NH=> You can't do one without the other IMO.....when you do you often
get it wrong is my experience.  Is not the current situation not
evidence enough there is something quite awry here?  Ever thought 'why'
this is?

> In the context of MH-PW 
> requirments, G.805 codifies SDH/SONET and ATM experience -
NH=> Not at all....this statement suggests that you do not understand
what functional architecture is about or (more importantly) what its
for.  You may like to know that one of my colleagues has just completed
the functional arch modelling of MPLS in SG15.....just what it says on
the RFC tin.  We have already done ethernet and folks are using it.
 
> but I question whether this is the right approach for 
> IP-based networks.
NH=> You right, G.805 is not appropriate....that's why G.809 exists to
model the cl-ps mode.

> When interworking with TDM and ATM 
> networks as in PW, then I agree that G.805 principles are 
> applicable for at least PW endpoints.
NH=> The whole purpose of G.805/G.809 is to have a consistent/rigorous
way to define layer networks.  They only come in 3 basic modes and this
stuff covers them all at an abstract level...specific standards are then
produced per technology (and this shows up any weaknesses) and this is a
key precursor to sound equipment standards and management information
models.  If you want good networking standards, sound equipment Recs and
(most importantly of all) proper management information models you need
this stuff.
> 
> 
> I hope that we can work toward supporting an architecture 
> that uses an IP-based set of control and management protocols 
> as well as the G.805 architectural basis that you propose.
NH=> Yes we can.  But I am not sure here is the right place based on
experience to date.

> In 
> the past, I believe that "manual" provisioning or 
> configuration has been used to support the existence of more 
> than one architecture and operational model in vendor 
> implementations and operator networks. Possibly this is a way forward?
NH=> Dave, its nothing to do with 'manual provisioning'.  When we
defined SDH way back we wanted to develop a control-plane for it even
then (I am talking ~12+ years ago)......so the GMPLS idea is very
old-hat to us.  However, there was no strong commercial driver for this
(and there still isn't if folks are honest).....its useful, (esp for
operators who never developed strong NMS-based systems, and with an
S-PVC approach it saves developing a prot-sw solution in the management
plane in addition to a more UNI-based/SVC approach), but when you look
at the call/holding considerations, what this would mean in terms of
dimensioning (GoS), and (especially) how the 3 modes relate (which, if
you understand it, tells you there are some problems about the notion of
functionally crunching 'from IP to Optics') you realise its not such a
big deal.  We have a very good understanding of the relationships
between all of the 3 traffic/control/management planes in all 3
networking modes and I'd like to think we know what we are talking
about.
> These "defects" could be due to implementation errors, but I 
> agree that it would be desirable to detect them.
NH=> We should make the basic 'always on' OAM stuff very simple and
complete.....if you don't do it from the outset it won't get done later
(too costly to re-engineer).  Its not hard/difficult if you think it
through.  And I have been very disappointed at the tactics I have seen
used in the past by some folks to slur what is in Y.1711.
> detection of 
NH=> You shouldn't.  You need to focus on all 3 modes if you are a
full-service operator.  They are all important in different ways.....in
fact its the differences that are the key bits.  You simply cannot do
everything you need in a single mode.  The key issues are:
-	coming to terms with understanding the fundamental economic
problems of networking.....this is nothing to do with technology
directly (though the arch will either enable or disable your ability to
address it), its simply an understanding that:
	o	build/run costs of network are massive and almost
invariant of load, ie marginal usage costs are tiny.
	o	core networks are not the dominant cost/technical
driver....access is
	o	the only successful networks (not just telecoms) must
have a pricing regime that is based on the value of the goods carried
and not the resource used.....and if you are smart, you will then
quickly figure out that chasing QoS is the wrong goal
-	applications only come in message, file or stream spins....this
should also tell you you don't need lots of QoS/traffic classes
-	the arch must correctly address both public and private services
(and must, as a min, be able to do network builder services in the
private services space)

I could say lots more on this topic...and have in the past, esp how this
translates to modal arch requirements...so I'll stop here wrt the above
issues.  
> data-plane" in the above.
NH=> In essence, I mean the decision/action is a distributed function
that is executed at trail sink points.
> that have a control protocol.
NH=> Then you have not understood the purpose of G.805.  G.805 does not
deal with the control-plane arch (or indeed the management plane
arch/perspective).....the control-plane arch is addressed in the ASON
stuff.  I would suggest a read of chapters 3 and 4 of BB networking by
Reid/Sexton.  This is by far the best explanation of these topics I know
of.  

> The determination of the set of link
> void.
NH=> You are specifically talking of a routing function here.  I do not
dispute the fact we need this component (all WAN scalable modes do).
However, its execution is quite different in the 3 modes and you simply
cannot (despite what I have heard claimed in the past) run a single
instance of routing from IP to Optics.  There are many reasons why this
is a flawed idea (both technical and commercial).

> IMO, being able to correlate the OAM state with the 
> desired state
NH=> In the cl-ps mode you have no choice....a routing function is all
that is at your disposal and one does not have the trail entity.  So I
can fully understand the mind-set of folks coming at the networking
space from an IP-only background.  Its not like this (ie so restricted)
in the co-ps and co-cs modes.  In fact as you approach the duct
'routing' becomes a far less important component than say data-plane
OAM, ie the trail holding times must increase as one approaches the duct
and simple routing solutions are perfectly fine.....but there is an
increasing speed/accuracy requirement on the ability of OAM to react to
failures and take executive action (inc prot-sw).  And then there is the
issue of OOB control/management here.....very different issues indeed.
> No, my point was that control protocols detect many defects. 
NH=> I don't dispute this may be the case...esp in the cl-ps mode.  But
look at the co-cs mode, the routing protocol and signalling protocol is
running in a disjoint network (at least logical if not physical) to the
traffic...so this is plainly not true here.

I'm going drop-out of this dialogue here....thanks.  regards, Neil

> The events