Hi Yaakov,
You wrote 16 October 2011 10:46
To: Harrison,N,Neil,DKQ7 R; huubatwork(_at_)gmail(_dot_)com;
ietf(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf