RE: [PWE3] BFD for MPLS PWs

[<neil.2.harrison at bt.com>]

Peter,

Please see below.

<snipped>

> I wrote that there is strong consensus that the use of PW
> Status does not imply that PW Status must be used for *every* 
> single AC and PW defect. E.g. in the case of ATM 
> encapsulation, an AC defect will result in AIS insertion. On 
> the other hand, in the case of FR encapsulation, an AC defect 
> will result in a PW Status message. The OAM message mapping 
> draft defines precisely when PW Status should be sent and when not.

NH=> It's one thing having to retrospectively cater for the way folks
have done things in the past (ie things we now understand as wrong or at
least non-optimal), but we also ought to also be learning from this and
producing a view of what the correct architecture/behaviour is and thus
attempting to move in that direction over time.  And one thing I am
still not seeing enough recognition of is that there is NOT a single
functional solution (this is more than OAM) that can correctly be
applied to all 3 network modes.  For example, let us take the OAM case
of applying AIS/FDI in the traffic data-plane:

-	AIS/FDI is absolutely the right response to failures in a co-cs
mode layer network.  {I'll spare the details here as to why this is
required, save to observe that it is yet another consequence (from the
unified modelling work) of the way resource partitions are labelled and
how these are forced to be coupled to real resource in this mode.}  The
reason AIS is traditionally coded as a stream of binary all 1s in the
co-cs mode is simply because the TTL logic used in the early PDH layer
networks floated to a +5v logic '1' under failures.

-	AIS/FDI should NEVER be used in a cl-ps mode layer network since
we do not have connections.....and this includes ethernet (I do not
agree with what has been done in Y.1731 in this respect).

-	The value of AIS/FDI is debateable in a co-ps mode layer
network.  One MUST have pukka connections to even consider it (ie single
source, connectivity=1, no internal routing choice once connection
created).


> 
> I have not made any statements about the WG's view on the use
> of BFD. There are two options: (1) use BFD for fault 
> detection only and use PW Status for fault notification 
> (within the bounds of the OAM message mapping draft, i.e. 
> recognizing that for specific defects AIS insertion will be 
> used instead of PW Status); (2) use BFD for both fault 
> detection and fault notification.
> 
> I am not aware of any WG consensus about a preferred
> approach. My personal preference is (1), because I believe 
> that for protocols with well-defined OAM (i.e. ATM and 
> Ethernet w/Y.1731), an AC failure will result in AIS 
> insertion at which point BFD fault notification is 
> unnecessary. However, in my opinion it is up to the service 
> provider to decide which approach to use.
NH=> I wish!  Seems to me its more down to the vendors who either
provide zero OAM (I can clearly remember being told MPLS did not need
OAM many years ago when we ran a BOF on this topic....and look at what
has happened since!) or, almost as bad, bloated and inappropriate
OAM.....Y.1731 is very much of that ilk IMO.  To be fair however, we
operators almost get what we deserve because we don't input sufficiently
(quantity and esp quality) to the stds fora IMO.

OAM needs to be carefully thought about up-front....and here are some
general rules:
-	one OAM solution is NOT appropriate for all 3 network modes
-	client/server relationships should NOT have 'OAM mappings' in
both directions......the only valid/possible mapping is AIS/FDI upwards
on server failure.....but this should NEVER apply to a cl-ps client
-	separate 'always-on' defect detection/handling OAM from
'on-demand' diagnostics and PM OAM
-	former must be as sparse and simple as possible, and must remove
as much human config as possible....why?....because it has to be
super-reliable (this is also one reason why lots of complex/configured
nested TCM levels in Y.1731 is a very bad thing, but there are many more
things wrong with nested TCM levels in a single layer network, esp a
cl-ps one)
-	if a network needs loads of OAM running to keep it working you
are already dead as an operator......further, we can't afford to process
lots of OAM anyway in normal operation (if you come and look at our
well-engineered/designed networks you will find most of the OAM normally
turned off)....ergo why we need to keep 'always-on' OAM very
simple/sparse....but we still need the ability to invoke good diagnostic
tools on a rare 'on-demand' basis
-	having correct/appropriate architectural design for the network
mode considered (ie no arch violations) in the 1st place will mitigate
the need for running unnecessary levels of complex OAM.

regards, Neil

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