RE: [PWE3] Proposal to Progress draft-nadeau-pwe3-oam-msg-map-04.txt as a PWE3 WG Item

["Monique Morrow (mmorrow)" <mmorrow at cisco.com>]

Neil,

I would like to suggest that we focus on addressing the technical
concerns you may have for the draft itself - this seems most expedient
for all and defer the architecture discussion to the MPLS WG for
example. It may be that you might consider a draft pointing out what you
consider as architectural flaws with a technical proposal to address
these flaws. 

As for this particular draft, we would like to work with you to resolve
some of the specific technical issues.

Regards,

Monique

-----Original Message-----
From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] 
Sent: 02 March 2004 10:10
To: andymalis@comcast.net
Cc: busschbach@lucent.com; Monique Morrow (mmorrow); pwe3@ietf.org;
andy.bd.reid@bt.com; alan.mcguire@bt.com; peter.j.willis@bt.com;
richard.spencer@bt.com; benjamin.niven-jenkins@bt.com;
dave.milham@bt.com
Subject: RE: [PWE3] Proposal to Progress
draft-nadeau-pwe3-oam-msg-map-04.txt as a PWE3 WG Item


> Neil,
> 
> Without re-quoting the email exchange (to save us all some BW 
> and disk 
> space), it's clear that you have some technical problems with 
> this draft. 
> :-)  However, are you opposed to this becoming a working 
> group draft solely 
> on the technical grounds, or because you also feel that it's 
> not a valid WG 
> work item because it doesn't fit within the charter and/or 
> because you feel 
> that it's not a useful work item?  If your objection is 
> solely technical, 
> then it can still become a WG draft, and we can all work 
> towards correcting 
> the details.  Personally, I think this fits within the WG charter 
> (especially now since the interworking aspects have been removed) and 
> provides not just useful, but required, functionality.
> 
> Cheers,
> Andy

Hi Andy,

Our concerns are not whether: (i) this work in/out charter?, and/or (ii)
this draft is technically correct?, and/or(iii) this is useful work
anyway?  We have a more fundamental issue regarding the efficacy of the
architecture and the functional components of the underpinning
technologies concerned.

Let me try and explain this.  I work closely with some of the guys who
did a lot of the G.805/809 functional architecture stuff.  We have a
deep passion about getting the net arch right. Why?  Well, bitter
experience has taught us that bad net arch will hurt downstream in many
ways.....esp when its consequences play right through to NMS/OSS.  We
have been here far too many times in the past.  So any technology that
(i) breaks the arch rules of the network mode considered and/or (ii) has
significant functional deficiences is going to start ringing alarms
bells for us.

Now folks here would not get too upset if this stuff stayed niche, but
when things like MPLS start to get discussed as a key core convergence
technology then we are going to take a far stronger interest in it.

(To save your hard disc) I won't repeat the arguments about what is
wrong with MPLS as-is, PWs not being a proper layer network, etc.  We
are sure of our ground here, but we also know there is no point arguing
with folks you don't understand the func arch language (or perhaps have
other reasons for not wanting to accept our arguments). 

Currently we regard MPLS as not fit-for-purpose as a key convergence
technology.....and from discusssions we have had with engineers in
several other operators it seems we are not alone in this view (though
very few operators are active in standards these days, and even fewer
are prepared to say anything in public for various reasons).

You have heard me say in the past that we need all 3 networking modes,
and that the key challenge we have is working out how to make them work
together most optimally to deliver a full range of network services that
are fairly-priced, meaningful and secure in a future-proofed
architecture at min capex/opex.....and we have some ideas on how to do
this.  To us this starts with a good appreciation and respect of
G.805/809 principles (though its more than that).  We need some
technology to assume the co-ps role in this architecture, and in fact
this does not have to be MPLS.  But if MPLS can assume this role then
great.  But to do so the broken stuff needs to be deprecated over the
long-term and the missing stuff added (eg the need an OOB
control/management-plane that you/I briefly discussed a while ago when
you came to see us).  We would also like to see a simpler adaptation for
carrying clients over LSPs.  Put simply, we'd like to be able to do far
more with MPLS and *not* PWs.

Now let's get back to this draft.  Its not that long ago we tried to get
folks in IETF interested in adding an OAM functional component to MPLS.
Initially this idea was ridiculed......'go buy from a decent vendor and
don't fix bugs with more SW' was the gist of the initial rebuff. We then
tried running a BOF...little joy even then.  However, when deployed
stuff started breaking then suddenly MPLS OAM is back on the agenda.
And not only that, I am seeing stuff that looks like my own words being
played back now, eg don't use the control-plane to proxy for missing
data-plane OAM, mis-branch/merge defects need factoring-in (because its
a co-ps mode), etc.  Even Y.1710 requirements/principles is now getting
quoted.

So, in summary:
-	whether this draft is in/out of charter is irrelevant in our
view
-	the only thing that matters to us is whether MPLS is
architecturally fit-for-purpose or not as a key core convergence
technology, and this cannot be solved by any amount of tinkering with
this draft
-	I do have some technical concerns with the draft (and I have
already given some that Peter B has kindly responded to)......but fixing
these will still not address our deeper arch concerns over MPLS
-	we are pleased to see service i/w removed at least.....though
service i/w with PWs has no arch meaning IMO.

regards, Neil
 

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3