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

[neil.2.harrison at bt.com]

Peter...

> -----Original Message-----
> From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com]
> Sent: 27 February 2004 23:50
> To: Harrison,N,Neil,IKR2 R; mustapha.aissaoui@alcatel.com
> Cc: sbrim@cisco.com; Spencer,R,Richard,XGH5 R; pwe3@ietf.org
> Subject: RE: [PWE3] New PWE3 Charter Items: SPVC Interworking
> 
> 
> Neil,
> 
> I hope that you can help me understand what the practical 
> implictions are of some of your generic statements. Please see below.
NH=> I can try.....
> 
> Peter
> 
> 
> > 
> > NH=> In simple client/server i/w (aka network i/w) the 
> > control-planes of both the client and the server layers are 
> > independent with no i/w at all.  
> 
> Mustapha's email addressed control plane interworking between 
> ATM and MPLS. In that context, how should I interpret your 
> statement? Are you saying that the only valid way of carrying 
> ATM over MPLS is the following: establish a Pseudo Wire
NH=> PWs are not MPLS however....LSPs are networked entities PWs are adaptation functions.  All the functional components of a layer network should be associated with the networked entity....in MPLS this an LSP.  A PW can have either IP or MPLS as a server layer network.....these are not the same.  PWs therefore have no real networking context....other than the fact they are some form of adaptation.  This is not a good road PWE3 have set off down.  

> that 
> carries multiple VPs in such a way that ATM signaling and 
> routing information is carried transparently over that PW and 
> the establishment of new VPs or VCs through that PW should be 
> done in such a way that it doesn't require any additional 
> signaling in the MPLS plane? This would exclude any form of 
> 1-1 encapsulation where VC or VP setup necessarily triggers PW setup.
NH=> In a strict C/S case that is right.  If I carry ATM over SDH I would never expect an ATM SVC demand to trigger a VC4 set-up say in SDH. This principle is also why the GMPLS peer-model was never sensible (I assume its effectively dead now?).  I mean, even from the most simple case of different SPs owning the client and server layer networks one can see this is a nonsense.
> 
> 
> 
> > 	*  Because PWE3 does not recognise MPLS as a layer 
> > network in its own right we don't have i/w with MPLS LSPs 
> > directly but rather a forced client/server i/w with PWs on a 
> > client specific basis.  This is a mistake in our view for 
> > several reasons, but that is what has happened and is now 
> > something some folks are going to have to live with.  This 
> > means there will be (at least) O(N^2) possible mapping 
> > relationships in the data-plane
> 
> As a generic statement this sounds reasonable, but when you 
> look at the specifics of existing protocols, I don't think it holds.
NH=> We want to stop re-doing past mistakes.
> 
> The MPLS-FR Alliance has recently examined Service 
> Interworking in-depth. One of the conclusions was that you 
> can't do generic (i.e. payload-independent) service 
> interworking between Ethernet on the one hand and Frame Relay 
> or ATM on the other. (This was explained in detail in a 
> contribution by Rao Cherukuri and Ali Sajassi.) 
NH=> I know Rao and Ali and this is wise counsel.....and this is why I remarked in my previous mail that whilst we can do OAM mapping between I.610 ATM and Y.1711 OAM, this is only possible because both the semantics and syntax (and even their derived dependent defect definitions) are closely aligned (see Y.1712 where this is now specified).  This was not 'chance' either, it was designed it to be this way.....though Y.1711 is much simpler and superior to I.610 (despite the misinformation I keep seeing from some parties on Y.1711).  However, for the general case this will not be possible....and in fact you will end-up with a right lash-up IMO. 

> As a result, 
> the MPLS-FR Alliance decided that Service Interworking can 
> only be done in very specific cases:
Be very careful here.  We have been vigorously discussuing this topic in BT for some time.  Never forget that one of the things most operators want to get away from is the notion that 'service<=>technology'.  That is, we have sold FR services, we have sold ATM services, etc.  So to date we have ended-up selling features of specific technologies and we have also ended-up with lots of disjoint stovepipe networks.....and its not just these, but the whole NMS/OSS stack that goes with them....and that is a killer!  If you see the key point here then when you look at the peer-partition i/w rules I set down in my reply to Mustapha hopefully it will make more sense, ie terminate all CI at the IWF, eg no OAM mapping (so, for example, we would disagree with Tom's OAM message mapping draft....also see my previous comment above for the one possible MPLS_I.610/ATM_Y.1711 exception to this), no 'feature' (like CLP) mappings.

It may be that we *never* migrate existing stoveipes to a common core....simply because of the complexities this will create and the true costs of doing this migration (don't overlook the crucial NMS/OSS aspects in this).  However, we still need to get the basic C/S case right (and I implore folks to understand/respect G.805 here) and we also need to properly understand the peer-partition i/w case since there will be cases of interfacing different peer networking technologies (same or different modes).  As a long-term goal we have a concept I christened here of 'functional covergence'......and this is all about stopping replacing technology X with technology Y (and thus a wholesale functional component change out, inc NMS/OSS), but instead focussing on moving to best-of-breed functions for some target cl-ps, co-ps and co-cs technology.....the networking problem for each technology belonging to the same mode is largely the same.  We very strongly don't agree with folks who think all the services we need to offer can be done in a single mode....I tried to explain some of this in my response to Chris Lewis wrt 'QoS in VPNs', and these wider points really ought to be considered along side this stuff as its all related.  
> 
> 1) Between Frame Relay and ATM, according to FRF.8
NH=> Now, can you see that this is a product of an old mindset where 'technology=service'?  I can for sure understand *why* those who did this did it like this......it made sense then and still does where we sell 'FR and ATM services'.  But we want to get away from this notion of 'selling technology' over the long-term.  So continuing to foster this same view is not a good idea IMO.  Note also that in FRF8 there is the option *not* to do the 'feature mappings'......not sure who put that in there, but maybe they were way ahead of the game even back then.
> 
> 2) In case of end-to-end transport of Ethernet traffic (i.e. 
> where ATM and FR use bridge-mode encapsulation)
NH=> Yes, but this is pure C/S....this ought to be simple *if* you respect the rules.
> 
> 3) In case of end-to-end transport of IP traffic (i.e. where 
> ATM and FR use routed-mode encapsulation)
NH=> Again its simple clinet/server....here the client is IP.
> 
> Of these, (2) can hardly be considered as Service Interworing 
> in the traditional sense of the word. It is essentially a 
> variant of network interworking of Ethernet over ATM or FR. 
> (3) is more complicated due to IP specific issues that have 
> been identified by Himanshu Shah and Ali Sajassi in earlier 
> drafts, but still it is not Service Interworking in the 
> traditional sense of the word.
NH=> Agreed.
> 
> The same holds for MPLS: it would be possible to define SI 
> between FR and MPLS or ATM and MPLS. However, it is not 
> possible to define generic (payload-independent) Service 
> Interworking between Ethernet and MPLS.
NH=> Oh yes I know.....this one is really giving me headaches.  If you recall what I said to Mustapha there was one point that some folks may easily have missed (clearly you haven't) as to its true importance/significance...so let me repeat it.  *Before* one should even think about peer-partition i/w of the functional components of >=2 server layer networks, you have to have a very clear understanding of the 'thing' that is the common client layer entity of all the lower peer partitions.  Now this has some deep implications that I probably don't want to get into here.....and in any case we have not come to any firm views as to what this should be yet. However, its on our agenda to sort because it is pivotal to some of our other ideas for an alternative services arch. 
> 
> Therefore, your statement about the service interworking 
> between N different protocols reduces to a statement about 
> Frame Relay and ATM only. For N=2, it seems that PW emulation 
> of ATM (or FR) over MPLS in conjunction with FRF.8  is a more 
> pragmatic approach than the alternative that you propose: SI 
> between ATM and MPLS followed by SI of MPLS to FR.
NH=> Yes, I can see what you are saying, ie no SI for either ATM or FR with MPLS, just C/S case.  However, one still needs the right C/S approach here...and specically we do not need the notion of PWs for this at all if the server is only arch compliant MPLS and we have client transparency.  
> 
> Am I missing something?
NH=> Don't think so.
> 
> 

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