The MPLS WG Archive

[neil.2.harrison@bt.com]

Giles Heron [mailto:giles@goneto.net] wrote 29 March 2001 22:27
> neil.2.harrison@bt.com wrote:
> > 
<snip>
> > 2       At the top of page 5 in section 2 it says:
> > " When a failure occurs and the backup comes into use,......"
> > 
> > All user-plane (and indeed control-plane) failure modes 
> must be identified
> > and specified in terms of entry/exit criteria and 
> consequent actions before
> > we can meaningfully proceed with this draft.
> > 
> > For the user-plane, the failure modes which must be 
> considered/defined are:
> > -       simple below MPLS fabric server layer connectivity breaks;
> > -       simple within MPLS fabric connectivity breaks (at 
> or below the LSP
> > level considered);
> 
> Both of these will be detected by the RSVP signalling, won't they?
NH=> Not necessarily.  The functionality/processing of the user-plane and
control-traffic is not identical......and they can be subject to different
failure modes.  Each needs its own OAM to handle defects relevant to its own
case.  Further, one would like to have SLAs for the user-plane (for
customers) that require specific and consistent measurement.  They also
require certain 'consequential actions' which are not currently specified
anywhere else but in our ID.  And in general, one should not look at just
'some' cases of defect in isolation.....they all require a harmonised
approach and, with careful up-front thought, this should also yield
simplicity of design.  If you don't think about these aspects at the outset
then things can get very complex later should you require to add such
functionality.
> 
> > -       swapped LSPs, ie instead of A1->A2 and B1->B2 a 
> defect creates
> > A1->B2 and B1->A2;
> > -       mismerged LSPs, eg instead of A1->A2 and B1->B2 a 
> defect creates
> > A1->A2 and A1+B1->B2 say (though there are potentially 
> several variations on
> > this).
> 
> Both of these would only occur (as far as I can tell) if the router
> software is buggy.  As I have stated before I don't really see the
> benefit of adding code to fix buggy code.
NH=> It can be HW as well as SW that is faulty.  The OAM has nothing to do
with 'fixing buggy code'....indeed it will not *fix* the defects, but only
allow correct handling should they occur to protect my customers and help my
Ops people diagnose the problem.  It is also there to ensure a consistent
(and indeed simple) method of measuring availability and QoS (the former is
*the* critical metric, and the latter is dependent on former since it only
applies to the up-state).  I have not seen any work (other than what is in
our ID) which shows how availability/QoS metrics can be consistently and
simply measured for all defect cases.  And as a carrier this is something I
want.  However, the overall purpose of the OAM is stated in the principles
section of the ID.  I refer people back to this rather than repeat here. 
> 
> > For the latter 2 defects it will be vital to suppress the 
> traffic due to
> > potential security/censorship/misbilling implications for 
> carriers and
> > customers.  Speaking as a carrier these issues are 
> requirements that must be
> > addressed.  This is not optional, and rigorous definitions 
> must be provided
> > (or referenced).
> 
> Speaking as another carrier I *don't* see these as requirements that
> must be addressed.  If software is buggy things go wrong.  So 
> let's fix
> the software rather than adding another layer to "manage" the bugs.
NH=> How are you going to decide/detect that the SW (or HW) is wrong in
order to fix it?  Are you really also telling me you have no requirements to
offer/measure availability/QoS SLAs for customers?......but if you do then I
would be interested to know how you are going to do this, ie do you have an
alternative proposal you can share with us for evaluation please?  It would
also be nice to hear from more carriers on this subject.....I know BT, FT,
DT, NTT and AT&T have an interest since they have seen/commented on what
appears in the work you have seen.  

<snipped to end NH>