The MPLS WG Archive

[neil.2.harrison@bt.com]

Hi Adrian....sounds reasonable to me.  We have to separate out OAM into
the 'always-on' type and the 'on-demand' type.

The former is all about taking local actions to deal with defects
as/when they arise....so its needs to be simple and it also need to be
processed in a unidirectional sense when we are dealing with the co-ps
and co-cs modes as the initial key actions need taking at the sink trail
termination point.  This becomes esp important when p2mp trails are
considered.  

The 'on-demand' type of OAM is, as you have noted below, all about
diagnostics....though I'd also lump PM flows in here because in a
well-engineered network you only need this to investigate (hopefully
rare) rogue behaviour and its generally not cost-effective to process PM
flows on the vast majority of good systems.

regards, Neil

> -----Original Message-----
> From: mpls-bounces@lists.ietf.org 
> [mailto:mpls-bounces@lists.ietf.org] On Behalf Of Adrian Farrel
> Sent: 17 February 2006 10:41
> To: Niven-jenkins,B,Ben,XDE73 R; mpls@ietf.org
> Subject: Re: [mpls] draft-ietf-mpls-p2mp-oam-reqs
> 
> 
> Ben,
> 
> I am sympathetic to your concerns and proposal. But we should 
> try to separate requirements from solutions (even if the 
> solutions are obvious consequences of the requirements).
> 
> Your reasoning for unidirectional OAM is very strong, but 
> isn't the requirement actually that "LSRs or other network 
> resources MUST NOT be overwhelmed by the operation of normal 
> OAM procedures, and measures taken to protect LSRs and 
> network resources against being overwhelmed MUST NOT degrade 
> the operational value or responsiveness of proactive OAM procedures."
> 
> Presumably your (good) suggestion on the behaviour of an 
> egress LER that detects a fault is actually applicable to 
> *any* LER that detects a fault.
> 
> I would also like to point out that section 4.2 is intended 
> to refer to "diagnosis" not "detection". This means that 
> bi-directional mechanisms
> *are* in scope. I believe that your comments are more 
> applicable to section 4.1
> 
> Does that sound reasonable? If so I will fold these thoughts 
> into a new revision and bounce it off you before publication.
> 
> Cheers,
> Adrian
> 
> ----- Original Message ----- 
> From: <benjamin.niven-jenkins@bt.com>
> To: <mpls@ietf.org>
> Sent: Tuesday, February 14, 2006 10:43 AM
> Subject: [mpls] draft-ietf-mpls-p2mp-oam-reqs
> 
> 
> Colleagues,
> 
> Following discussions both inside and outside of BT I have 
> been giving P2MP OAM some thought and have come to the 
> conclusion that P2MP OAM must be unidirectional in nature.
> 
> P2MP LSPs are uni-directional in nature.
> 
> It is the tailend router that must take the appropriate 
> consequent actions in the first place - e.g. dropping traffic 
> if it is misconnected to a P2MP LSP that it should not be etc.
> 
> It is not practical for the headend of a P2MP LSP to receive 
> acknowledgements from every tailend router in response to a 
> Connectivity Verification (CV) probe because the number of 
> responses received could be very large (e.g. if there are 
> lots of tailends and/or lots of P2MP LSPs orginating from the 
> same headend router).  This is compounded if proactive CV is 
> performed and delaying responses to 'spread them out' is not 
> a practical solution for proactive CV IMO.  CV sweeps where 
> the connectivity between the headend and each tailend is 
> tested in turn is also not practical for proactive CV.
> 
> Therefore I would request that an appropriate requirement be 
> inserted into draft-ietf-mpls-p2mp-oam-reqs to reflect the 
> requirement that proactive P2MP OAM must be unidirectional.  
> Note: once a defect has been detected by the uni-directional 
> proactive OAM other OAM tools/techniques (which may be 
> bidirectional in nature) can be triggered such as route tracing etc.
> 
> Below is some suggested text for inclusion in section 4.2 
> that reflects this requirement.
> 
> "Continuous path connectivity and SLA measurement mechanisms 
> for P2MP LSPs MUST be unidirectional in nature so that the 
> ingress LER is not overwhelmed with responses from egress 
> LERs.  If a fault is detected by an egress LER the detecting 
> LER MUST take the appropriate consequent actions which MAY 
> include raising an alarm (e.g. an SNMP trap) and/or informing 
> the ingress LER of the fault."
> 
> The following text in section 4.2 may have to be modified to 
> align with the requirement I am suggesting in order to 
> clarify what timeouts it is referring to as by default the 
> headend LER will not expect responses from tailend LERs in 
> response to proactive CV or SLA measurement mechanisms.
> 
> "It must be possible for the operator (or an automated 
> process) to stipulate a timeout after which the failure to 
> see a response shall be flagged as an error."
> 
> 
> Ben
> 
> -- 
> Ben Niven-Jenkins
> Network Architect, BT Exact
> 
> E-mail: benjamin.niven-jenkins@bt.com
> Office: +44 (0)1473 648225
> Mobile: +44 (0)7918 077205
>    Fax: +44 (0)1332 578827
> 
> _______________________________________________
> mpls mailing list
> mpls@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/mpls
> 
> 
> 
> _______________________________________________
> mpls mailing list
> mpls@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/mpls
> 

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls