The MPLS WG Archive

[neil.2.harrison@bt.com]

Hi Robert....many thanks for swift turn-round response.  Have tried to
answer below (and snipped at end to shorten).

Regards, Neil

 
> A few follow up questions ...
> 
> 1.
> 
> >    The node in the layer network, which first detects a 
> defect (sourced 
> >    from within that layer), should apply a well-known 
> 'Forward Defect 
> 
> >    (1)  There should be a complimentary Backward Defect Indication 
> 
> If FDIs & BDIs are optional I think you should s/should/may/. On the
> other hand I think that those msg are costly in cpu but very usefull
> (especially in the diagnostic case). Making them optional 
> really changes
> the understanding of your draft.
NH=> I agree.....IMO FDI and BDI should be indicated as optional (esp in
intra-domain case *if* there is a decent NMS in place).    
> 2. 
> 
> Reg item 5.7 
> 
> ...
> 
> >    It is therefore required that a unique trail source 
> identifier be 
> >    periodically transmitted from the trail source to the 
> trail sink to 
> >    detect these types of defect. 
> 
> > But, why should you always want to tell the head-end?  If
> > you want to invoke prot-sw in a non 1+1 case from the head 
> end then yes you
> > would want some return information, but the absolute 
> minimum requirement is
> > (i) to detect all failures at the sink and (ii) to take appropriate
> > consequent actions at that point, eg raise a failure 
> indication at the sink
> > point, stop QoS agggretaion, etc. 
> 
> Here we seems to quite disagree. IMHO source needs to know about given
> LSP failure to take corective action and not the sink. Rasing failure
> indication at the sink and counting for either an offline 
> tool action or
> even worse human action to fix it is way too slow. 
> 
> If the LSP is broken source should immediately either shut 
> given LSP or
> switch the traffic to another path (if past protection is applied).
NH=> Well in principle I agree for *those* LSPs which require some form of
protection and that don't use 1+1 case.  However, any scheme requires that
one can detect the failure in the 1st place....so this does imply a
continuous detection process, and the Ping draft does not adequately address
this, nor does it cater for the mismerging case.  So even if we were to use
a control-plane technique to return the information (instead of BDI in a
returned data-plane sense, or via some OOB management-plane) we need to be
clear of about the independent integrity of the outgoing/return directions.
Note - In order to be sure one can differentiate outgoing/return status in
the Ping draft one needs to ensure diversity of the data-plane of both
directions (and in case of return direction, I am talking about the
data-plane aspect of the control-plane here....since even a control-plane
must have some data-plane).  Its not at all clear to me how practically one
can achieve this....especially if ownership of the duct network is under
some other domain, ie leased L1 capacity.  Something to think about
perhaps....though this can be generalised to more than the Ping draft, and
which is why it is usually important to sure make the data-plane of the
control-plane (or management-plane) only takes its survivability cues from
the duct network.
> 
> > Further, the Ping draft only seems
> > > to address simple breaks in connectivity (though it does 
> not even detect
> > > these, which is a primary requirement, and appears to 
> rely on customers to
> > > complain...which I would argue is unaccetable).
> 
> I will either let Ping address this or we can talk live ....
NH=> Let's discuss next week.  But as noted above, if you really want to
have fast restoration, you need proper defect detection....so this implies
some form of continuous conectivity verification in place for all cases.
> 
> Rgs,
> Robert
> 
> PS. It would be probably easier to get together next week and discuss
> this face to face. I will send an offline mail reg this.
NH=> Fine and thanks....hopefully we can now start to home in a mutually
satisfactory solution.