The MPLS WG Archive

["Thomas D. Nadeau" <tnadeau@cisco.com>]

On Feb 17, 2006, at 5:40 AM, Adrian Farrel wrote:

> 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."

	It might also be a good idea to quantify just what
"overwhelmed" means in a little more precise terms.  I
had a number of comments on this WRT the p2p OAM
requirements from the IESG during the RFC review,
so I suspect the same questions will come up again
WRT this document.

	--Tom


> 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