Re: [mpls-tp] [mpls] MPLS WG slides from CMCC

[<[e-mail]>]

Hi Christopher,  I have several remarks in-line as there are some misconceptions here IMO: 

Christopher LILJENSTOLPE wrote 15 December 2010 05:16
<snipped>

> > 
> > [hvh] another reason for the selection was the availability of a 
> > solution.
> 
> To be sure, this is a "emotional" issue for both sides.  
> However, there are outstanding concerns on this draft on 
> multiple levels (interoperability with the  "standard" MPLS 
> stack, a number of issues raised in various reviews, 
> including a routing area review, etc.).

NH=> This is a key point, but not in the manner I believe you imply or may expect.  The reason for doing MPLS-TP in the first place was to produce a transparent transport network solution.  This, almost by definition, could not be a profile (sub-set of) MPLS as-is but needed new behaviours (eg an OOB CP) and, in particular, it should have paid very close attention to what transparency really means...because this is *the* fundamental DP service that a  transport network provides to its clients.

Now, as I have pointed out previously, transparency demands that the server treats all clients and each of their symbols equally...in particular the server must make no attempt to understand the meaning of and/or modify a client's symbols.  One less obvious consequence of this is that all client symbols MUST be treated equally wrt to 'urgency' and 'importance', as these requirements are only known to message/file/stream applications in the TOS layer network and a transport network is not TOS by definition => thus one cannot have meaningful multiple QoS (sic) classes in the connections of a truly transparent transport network.  However, when we look at MPLS-TP we see we have retained:

-	sublayering => which implies MPLS LSPs are treated differently to other clients.  Further, sublayering is quite unnecessary and creates problems in a transport network per se.  For example, one can have misconnectivity not only between different layers (which is something I suspect most folks have not looked at yet) but also between different sublayers (both intra and inter layer).  A further consequence of traditional MPLS sublayering is that the traffic units do not have consistent characteristic information, eg in true sublayering the label should always have a forwarding semantic...this is not true in MPLS and I suspect this problem will also apply to MPLS-TP.

-	PWs => carrying this mistake over into MPLS-TP is almost unforgivable IMO because it is well known as such and for many years.  PWs are a direct consequence of LDP LSP merging which is an obviously banned behaviour in a transport network.  In the MPLS LDP world a PW label is SA proxy to effect demerging since we cannot rely on having a cl-ps client layer, such as IP, where the SA is absolute/explicit in the client traffic unit.  Although 1-hop PWs are plain wrong in MPLS-TP, MS PWs are staggeringly so....since these create a new layer network above MPLS(TP) which now requires a ful set of its own layer network components, eg the PW layer network has its own 'unusual' (I'm trying to be polite) AII etc style of address structuring and signalling.

> I also am personally 
> concerned about re-use of existing technology and standards, 
> where possible.

NH=> Then you should agree with me at least wrt PWs...these don't use the same addressing, signalling, etc components as MPLS-TP....indeed they represent a wholly unnecessary layer network.

Having said that, the idea of re-use without thinking through all its consequences is a mistake in itself.  It is not optimal to try and make one thing try and do every job....we would not build a single type of ship as a river ferry, for carrying oil, for carrying ocean cruise passengers, to do a defence job, etc.  Networking technologies have efficacy limits of scale/scope.  Indeed the 'rule of minimum' in networks is: 3 modes (cl-ps/co-ps/co-cs), 3 external TOS layer network application adaptations (message/file/stream), 2 layer network relationships (client/server and peer-partition) and a BOS section layer that can modulate an EM wave (metallic/optical/radio media).  One needs all these basic components in a networking role that covers the full range of public and private networking services.

On can also observe that since the TOS and BOS layer networks must always be present in all network scenarios, then the real goal for operators is to optimise cost and reliability by removing as many other layer networks that lie between these as possible.  Now observe that MPLS and MPLS-TP are neither TOS nor BOS....so I can compellingly argue they are not even relevant to a transport role since they cannot modulate an EM wave directly and instead always require a proper (usually co-cs mode) BOS layer network technology under them that can....thus it is this layer network that is the transport network and not MPLS-TP....just a fact.

So we need to be quite clear when we talk of reuse wrt its context within the 'rule of minimum' components I pointed out above.  Aside=> I do actually agree with your remark below that there are too many protocols and complexities in networking these days, eg we don't need N different technologies in each network mode.  However, unnecessary complexity and cost can also be a consequence of not recognising the 'rule of minimum', and thus not recognising the efficient limits of scale/scope of one specific technology and trying to make it do things it is not suitable for.


 
  I believe I am not the only one with those 
> concerns (the amount of protocols running around in the 
> network today is a nightmare, I would prefer not to add to 
> that stack if I don't have to).  I am also concerned about 
> the propagation of two completely separate approaches to 
> answer 5860 that could both be considered "MPLS-TP OAM" 
> solutions.  Interoperation would become "interesting"

NH=> If MPLS and MPLS-TP are considered as peers and need to 'interoperate' then we have clearly not understood what providing a transport network is about...I'll come back on this point later when considering peer interworking of non-TOS layer networks.
> 
> > 
> >> However, if CMCC (or any other carrier) have decided to deploy 
> >> draft-bhh based on an understanding that draft-bhh WOULD become a 
> >> standard, that would be an unfortunate misunderstanding.
> > 
> > [hvh] the fact that they are really interested in this solution is 
> > proven by the standardisation of this solution in CCSA.
> 
> This is a real concern.  There is a reason why network 
> standards (and their organizations) are International in 
> scope (i.e. the ITU and IETF).

NH=> I agree.  And the main reason is to provide peer level interconnects between different parties in the same layer network.  It is technically quite trivial to prove that the only networks that need this are TOS ones (ie ones that interfaces directly with external message/file/stream applications)....IP and the PSTN are like this, ATM could have been like this....all other technologies are not like this...and this includes MPLS(TP).  We can create peer interconnects in any non-TOS mode/technology if we want of course (and technology pressure group do push for this wrt their favoured technology).  Indeed we can do all manner of quite unnecessary/wrong things 'just because we can' (if the network mode allows it).  However, I would suggest we should try and be a little more wise in spotting such cases and not wasting our time/money on these unnecessary activities.  

>  In the days of very little 
> cross-border connectivity, we could get away with "national" 
> or "regional" standards.  However, even in those days, they 
> caused issues.  How many people remember the fun of T1/E1/J1 
> or the early days of SONET/SDH interworking?  How about the 
> joys of the North American GSM frequencies vs. the ROW?

NH=> I remember it well, indeed I was responsible for some of the design aspects of the E1 frame (eg I designed CRC4 and its multiframe structure)....but this is something different to TOS E-NNI peer interconnects.  We *physically* have to connect even TOS layer networks together at a BOS section layer....but if you really grok what that means we are simply passing a binary bit stream transparently across the DP here, eg we must preserve bit ordering as we cannot make any judgement on the urgency/importance or meaning of higher layer client symbols (ie groups of bits) and there is no CP/MP interoperability.   These are not at all like the E-NNI peer interconnects of the TOS layer networks that define public services like the Internet and the PSTN.

However, I do agree that we should minimise the number of layer network variants (in fact the old co-cs PDH/SDH fixed hierarchy models are bad news, we should be moving to a digital wrapper approach here)...but this is quite different to requiring their peer interworking (being quite careful wrt to what this really means as I noted above).

regards, Neil
<snipped to end>