The MPLS WG Archive

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

	Yes, I agree this is a good addition to the
text that makes complete sense.

	--Tom

	
> 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