RE: draft-bonica-tunneltrace-02

[neil.2.harrison@bt.com]

Tom...please see below.  Regards, Neil
>>If you noted in some of my earlier mails I was very 
> careful to refer to
> >'simple breaks' when using trail-trace type of mechanisms for defect
> >diagnosis.  If you ever get a misbranching/mismerging defect then:
> >-       you need to know it exists in the 1st place (not 
> obvious how this
> >can be done....with CV it's trivial, as you see the source ID of any
> >offending LSP at the sink of the offended LSP, so you both 
> detect/diagnose
> >immediately)....I'll ignore the fact that a whole raft of 
> consequent actions
> >are also missing;
> 
>          Please clarify.
NH=> I provided info in earlier mails on this but you may have missed them,
also a read of Y.1710 and Y.1711 may not go amiss (BTW Cisco has 4 delegates
to the last SG13 where these Recs where agreed so they should be able to
provide you with copies, and I also noted Bian Moore recently flagged a URL
where copies of SG13 Recs should be available soon)....however, in summary:
-	need to raise an alarm relevant to the defect
-	need to suppress alarms in higher layer networks.....we all take FDI
(from networks like SDH/ATM/OTN) for granted.....some additonal features in
MPLS FDI which are defined are DL (Defect Location) and DT (Defect
Type)......former gives AS of original defect (but no lower level detail)
and latter indicates nature of original defect;
-	need to squelch traffic if misdelivered;
-	need to provide BDI if single-ended monitoring of availability
and/or 1:N-type of prot-sw used.....also replicates DL/DT fields from FDI;
-	need to suppress any QoS aggregation (into long-term registers of
such, eg pkt loss) when entering unavailable state.....but this pre-supposes
we have agreed/standardised (and in order) (i) defect entry/exit citeria
(ii) unavailable state entry/exit criteria.

<snipped>
> >NH=> Asking ICMP to proxy for missing defect handling in MPLS is a
> >possibility....and as Geroge hints in an earlier mail is 
> actually an example
> >of a layer violation, but so be it.  However, this should 
> not be used in
> >XoverMPLS....you need a solution here that is self-contained 
> within the MPLS
> >network.
> 
>          What is a "self-contained MPLS network"? MPLS 
> networks require IP 
> networks.
> When running X over MPLS why does that requirement change at all?
NH=> See my response to George S on this who raised the same point.
Note:  small point re above....I did not say 'self-contained MPLS network' I
said 'self-contained within the MPLS network', ie wrt the defect handling
behaviour.