The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [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
|
|