Hi Yaakov, You wrote 16 October 2011 10:46 > To: Harrison,N,Neil,DKQ7 R; huubatwork@xxxxxxxxx; ietf@xxxxxxxx > Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon) > Subject: RE: Last Call: <draft-sprecher-mpls-tp-oam-considerations- > 01.txt> (The Reasons for Selecting a Single Solution for MPLS-TP OAM) > to Informational RFC > > >> In transport networks we *never* have peer-2-peer OAM interworking. > >> If it was required it would have explicitly been mentioned in > >> the MPLS-TP requirements RFC. > > >Indeed, to have any peer to peer OAM simply removes the ability of the > OAM to do its job. > > Neither of these statements is completely accurate. NH=> Actually the latter is if the OAM is to do its job to the most simple/optimal/reliable level....but we can of course ignore and overrule such a requirement. > > For example, the ITU produced Y.1712 that details the peer-peer > interworking > of ATM OAM per I.610 with the MPLS OAM described in Y.171. NH=> Indeed so. Dave Allan and I wrote Y.1712. I only realised later what a waste of time it was...and on 2 counts: - Andy Reid made me aware of just what a bad and unnecessary idea an AIS/FDI signal was in a co-ps mode layer network (its obviously silly for a cl-ps mode layer network); - I sat down and thought much more deeply about what peer interworking really means... noting that DP OAM I/W is only one small facet of the whole DP/CP I/W vista anyway. The key revelation for me was understanding that since the whole purpose of *all* networking scenarios is to allow message/file/stream applications that are external to the network(s) to communicate over large geographic distance, then the only place peer I/W is of any relevance is in the TOS layer networks (like IP, the PSTN and (potentially) ATM) that have the required message/file/stream external application adaptations functions. Any non-TOS layer peer I/W (and this is for all the DP/CP components, not just the DP OAM bit) is just generating unnecessary work/problems/costs for the sake of it...because we still need to terminate the non-TOS layer network(s) and expose the real E2E TOS layer network case that must always be present! Simple and blindingly obvious when pointed out. I wrote a paper on thi s that goes into a little more detail. I'll send you a copy of it if you like...just ask. Note - The physical interconnection of BOS guided EM wave media (metallic or optical) components is *not* peer I/W. This is how we physically plug together different boxes at the BOS. Here we are only interested (for many reasons) in the transparent transfer of the DP symbols. > > I think that the accurate statement is that OAM interworking is perhaps > undesirable > but trivial when the OAM semantics matches so that the interworking is > syntactic translation, > but very challenging (and perhaps sometimes impossible) when the > semantics are different. > (For "semantics to be different" it is enough for timer values to be > different, > let alone different fault states.) NH=> This is true. When Dave/I penned Y.1712 our main thought was we could sensibly do this because of the close alignment of the OAM. Only later did I fully realise what a waste of time doing this was anyway. But you are right that peer interworking becomes even more daft/harder when we have (in increasing order of daftness/hardness): (i) the same mode but quite different DP/CP functional specifications in each technology (wrt traffic unit structure and fields therein, addressing of access points, routing, signalling, OAM, etc...all these components must be interworked) or (ii) different modes...here we can have very significant functional mismatch, and some functions simply don't exist or align at all, eg - co-cs/ps signalling (esp OOB) is not relevant to the cl-ps mode - co-cs DP AIS/FDI is obviously not relevant to the cl-ps mode and (less obviously so) to the co-ps mode - a cl-ps mode traffic unit TTL function should never appear in a co-cs or co-ps mode layer network traffic unit - the short-cuts in traffic unit labelling that can be applied to the co-ps and co-cs modes (they are not the same) cannot be applied at all to the cl-ps mode - etc. > > However, there are many cases where several OAM types co-exist in a > single deployment. > Perhaps the most relevant case is the widespread use of both EFM OAM > (802.3 Section 57) with Y.1731 OAM. NH=> Of course we can this...just like we can do all sorts of wrong/unnecessary things. The key issue with co-ps mode OAM of course is that when it arrives at any DP trail termination point that trail termination point must be able to make sense of it if we are not only to detect misconnectivity but diagnose the offending source. If there are N spins of OAM in some layer network then each trail termination point needs to be able to handle N types of OAM arriving due to misconnectivity. This is hardly a sensible situation to allow to happen however. Aside=> The above is *per layer network*. We never nested different layer network instances of the same (wrt DP/CP functions and traffic unit structures) co-ps technology before...so inter-layer misconnectivity was simply not possible. In MPLS-TP we can have both cases of intra- and inter-layer misconnectivity...and that means we have to pay attention to the structure of the SA ID we use in the CV PDUs. regards, Neil > > Y(J)S > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf