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

[neil.2.harrison at bt.com]

Monique....We have been discussing how to respond to you wrt this mail and your last mail; where you invited us to submit a draft with our proposals in it.....so sorry for the small delay in responding.

I am happy to work on the technical detail of this draft (in fact I have already submitted some comments that Peter B kindly responded to).  However, this assumes this draft is based on the right solution already.....and that is probably not the case.  In fact, the draft already shows that our main concern is true (ie that an adaptation of X to MPLS requires a different treatment to an adaptation of X to IP) by the various areas in the draft where different behaviours are noted both for the different defect types that can occur (ie MPLS server case different to IP server case) and how these may impact the different signalling cases.

Once we have concluded our internal discussions we will try and post something with our ideas in it....some will relate to MPLS per se and some will relate to the adaptation of clients into MPLS, so I am not sure where this best fits.  We'll think on it.

regards, Neil

> -----Original Message-----
> From: Monique Morrow (mmorrow) [mailto:mmorrow@cisco.com]
> Sent: 02 March 2004 14:43
> To: Harrison,N,Neil,IKR2 R
> Cc: busschbach@lucent.com; pwe3@ietf.org; Reid,ABD,Andy,NUJ91 R;
> Mcguire,A,Alan,XGH6 MCGUIRA R; Willis,PJ,Peter,CD WILLISPJ R;
> Spencer,R,Richard,XGH5 R; Niven-Jenkins,B,Ben,XGH5 R;
> Milham,DJ,Dave,XGJ1 MILHAMDJ R; andymalis@comcast.net
> Subject: RE: [PWE3] Proposal to Progress
> draft-nadeau-pwe3-oam-msg-map-04.txt as a PWE3 WG Item
> 
> 
> 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