The MPLS WG Archive

["Adrian Farrel" <adrian@olddog.co.uk>]

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