RE: [PWE3] New PWE3 Charter Items: SPVC Interworking

[neil.2.harrison at bt.com]

Chris,

Chris Metz observed 27 February 2004 14:33

<snipped>
> - IETF does have too narrow a constitution.
NH=> I am not sure IETF has a useful constitution at all these days.  IMO (i) 'rough consensus and running code' and (ii) '1 man/woman 1 vote' worked fine back in the 60s/70s when the Internet was still a big experiment.  But we operators can't afford 'rough consensus and running code', we need network solutions that are properly architected up-front.  IETF does stds after stuff has been built.  Further, if one is a dominant vendor in that environment, then it could be argued that the IETF modus operandi starts to look more like a 'stds laundering service'.

<snip>
> - We want to get it right.
NH=> That is not the impression we get.  We get the impression of lumbering from one kludge to the next.

> To that extent, those working on 
> PWE3 should be 
> "forced" (bad choice of words, I know, how about encouraged) 
> to understand 
> the critical aspects of what is required to support a L2 
> service ... so 
> that it works as well as it can with the PWE3 stuff.
NH=> You make the assumption here that PWE3 is already 'right'.  It's not.  However, PWE3 stuff per se is not the real problem....it is a symptom of a deeper problem.....see later.
> 
> I can appreciate the arguments that say spvc iw does not 
> belong in the 
> IETF.
> But I also want to make sure that those building PWE3 
> boxes and the 
> operators who are
> and will deploy it have a solution  that works.
NH=> So do we.....so let's start with the right architectural mindset.

Now let me try and explain why you have seen certain views expressed by my colleagues here in BT on this thread....some of whom, it has to be said, would prefer the solution that PWE3 was shut down:

-	PWE3 is a symptom of a deeper issue.....MPLS is simply not IP.  Just like GMPLS (eg SDH) is not MPLS.  IP uses a cl-ps forwarding paradigm (ie each pkt must have network significant DA/SA), MPLS uses co-ps forwarding (ie pkts only contain a link-connection signficant label) and GMPLS uses co-cs forwarding (ie fixed BW labelled slots in time/frequency/space). If MPLS does not offer something different to IP then why on earth do we need it?

-	A mp2p construction and a PHP 'feature' breaks the arch rules of the co-ps mode....that is just a fact.  Add proprietary ECMP to the brew and one has now created a complex set of both technical and commercial traffic/fault/QoS problems for operators to try and deal with......and if any of you saw my recent posting (originally on the l3vpn list) to Chris Lewis regarding QoS in VPNs I explained some of the additional issues that need to be considered here.  Sure you can do mp2p and PHP but this does not make them a sensible thing to do.  Nearly all the problems with MPLS stem from these arch violations of the co-ps mode (though there are also some functional deficiences in MPLS as-is...see later)  If you want true any-any behaviour and if similiar less-strong traffic/perf-SLAs are acceptable then use a proper IP cl-ps server layer since this does not suffer from the problems LDP does.  When we use a co-ps mode we should ensure it adds real value and not just problems.  In any case, we must have conformance to G.805/809 func arch requirements, as ultimately these determine the efficacy of the management information models that one creates for a given technology. I can point you at our NMS/OSS folks if you want chapter/verse on why this is so critically important to us.

-	MPLS is not singular, ie each different method of signalling LSPs creates different MPLS networks.  MPLS has no consistent access point addressing.....and these don't belong to the IP layer network even if they are based on the same v4 (or v6) format.  To illustrate this, observe that one cannot 'legally' connect a LDP LSP access point to a RSVP-TE LSP access point.....though one can now have misconnectivity defects between such LSPs please note.  This is no different, in principle, to observing that one cannot connect a VC_4 access point to a VC_12 access point in SDH.....they simply belong to different layer networks.

-	It should be a no-brainer requirement for a serious network operator that all internal/sensitive control and management protocols must be logically (at least) OOB wrt to the customer traffic in the core network.  This aspect seems not to have been considered at all for MPLS.

-	The original intent of the PWE3 work was to allow a SP who was not able to offer native ATM and FR services to get a slice of the ATM and FR market.....the remit has expanded since then.  It was not written to facilitate network convergence *from* FR, ATM to MPLS for operators like BT.....noting that this is not even true any longer as the convergence seems to be to PWs (not MPLS) and these are not the same thing....see later.

-	Since MPLS is not the same as IP, then there is no forced requirement for the XoverMPLS and XoverIP adaptation functions to be the same.  Further, if we did XoverSDH for arguments sake, this would also require a different adaptation.

-	Most, if not all, the fields in the Martini CW are serving no useful purpose.  Let me elaborate on this (I will ignore the ECMP hack here, save to note this is also a consequence of breaking the arch rules, ie load-spreading should be constrained to lie within a single layer network).

If one compresses a client one loses client layer transparency.  This creates management problems.  If one drew out the G.805 func arch of what is going one here one would see artifical/partial trail termination functions created at the i/w point (and there are varying spins on this depending on the client involved and the degree of compression being used). When folks draw 'cloud diagrams' however they seem to overlook the fact that there is also a similar C/S relationship between MPLS (or whatever) and some underlying server layer like SDH, ie in G.805 terms, 'a client layer link-connection is formed by trails in a server layer'.  Fortunately the C/S relationships here respect the arch rules, so folks forget about them and they are taken for granted.....esp the fact that the server layer has well-defined and independent (of the client) OAM and defect handling, though this is invariably heavily relied on.  In principle however, the C/S relationhip between MPLS (as a client) say and SDH (as a server) is no different to that between ATM and MPLS say....and so the same arch rule should be used, ie G.805.

Seq Nos are not required in an architecturally valid co-ps technology. Moreover, they should not even occur in a generalised adaptation function (cf RTP and AAL1 which are *specific application* adaptation functions).  However, if Seq Nos remain then they cannot be left 'open-ended' wrt behaviour under persistent abberation, ie a defect condition must be specified with entry/exit criteria and consequent actions.  And as a more general observation here, there are no defects specified in any IETF drafts/rfcs for any of the flavours of MPLS....this may be consistent with the IETF mindset (ie 'we don't do services') but this is unacceptable to us.  Please see Y.1711 for what we want here.

The 'port-mode' that appears in some adaptations for some clients has no architectural meaning. This will create fault management problems, eg one cannot map a server layer defect to the appropriate FDI of all/each of the clients supported.  It should be removed from wherever it occurs.

-	PWs are not a sensible convergence network solution for operators......but that is where PWE3 seem to be heading now, ie a PW ignores its underlying transport....which can be IP (cl-ps) or MPLS (co-ps).  This is not acceptable as they have (or at least should have, if arch compliant) different behaviours.

-	A PW is a X/IP or X/MPLS client->server adaptation function.....it is *not* a networked entity whereas an LSP is.  Further, if 2 MPLS networks form a client/server (C/S) relationship and each network is owned by a different party, it is clear we have an LSPoverLSP case and not a PWoverPW case.  A key corollary of this is that all the stuff that defines a layer network must be associated with the LSP entity and *not* the PW enity, eg OAM, signalling, etc.

-	we need a simple adaptation to LSPs for the general C/S case.  The PID word could be used as a basis for this and the Martini CW deprecated.  

-	We know precisely what we require for C/S i/w.....this is implicitly embodied in G.805/809 already. We do not as yet have any agreed arch rules for peer-partition i/w.  We need these agreeing 1st before embarking on specific solutions. See my recent response to Mustapha Aissaoui on this where we give our best current view on what this should be.

I hope you can now see why we don't regard PWs as a suitable convergence solution.  There are arch problems with PWs per se, but there are also more fundamental arch problems with MPLS.  These things need fixing in our view, else it would seem that MPLS (not PWs) will not be able to assume a core convergence role that so many folks hoped it would......and IMO that would be a real pity and a lost opportunity.

regards, Neil

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