Subject: RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-01.txt]

From: [email-masked]
Date: Sun, 5 Aug 2001 10:15:45 +0100

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.

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 05 Aug 2001 02:45:26 -0700

Hi Neil,

> continuous detection process, 

Agree !

> and the Ping draft does not adequately address
> this, 

Why not ? The continutiy of detection is provided by a continues regular
ICMP msg on all tested LSPs.

> nor does it cater for the mismerging case.

Yes, but I believe that this is due to the preference of the least cpu
consumption as much as possible. It is not so rear that icmp can be even
processedon the line cards these days. Dealing with mpls deployments for
a last few years I have never seen a mismerged LSP ;). Broken -- yes but
not mismerged. So I am not sure how important that case is.

> must have some data-plane).

That is in fact the good trick of ping's draft :). As the LSP under test
is up (the LSP-ping packets has arrived at the tail/sink of an LSP and
intial ICMP failed) the failure is in the return data path somewhere
from tail to head. So if the LSP is up the path taken by RSVP RESV msg
must be up. Therefor appending the LSP_ECHO object into the RESV msg for
me seems as a quite clever way of making sure that the head will be
notified of successful delivery of LSP-ping to the tail and therefor
about OK condition for the LSP.

> NH=> Fine and thanks....hopefully we can now start to home in a mutually

Would be too great to happen ! My goal would be to at least understand
well all of the proposals on the plate ;).

R.

> [email-masked] wrote:
>