The MPLS WG Archive

["Tom Nadeau \(tnadeau\)" <tnadeau@cisco.com>]

Title: Re: [mpls] draft-ietf-mpls-p2mp-oam-reqs

Indeed.  Will use the correct term.


 -----Original Message-----
From:   Tom Petch [mailto:nwnetworks@dial.pipex.com]
Sent:   Wed Feb 15 04:05:39 2006
To:     Tom Nadeau (tnadeau); benjamin.niven-jenkins@bt.com
Cc:     mpls@ietf.org
Subject:        Re: [mpls] draft-ietf-mpls-p2mp-oam-reqs

One tiny quibble; the current, SNMP preferred term is notification rather than
trap.

Tom Petch

----- Original Message -----
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
To: <benjamin.niven-jenkins@bt.com>
Cc: <mpls@ietf.org>
Sent: Tuesday, February 14, 2006 4:13 PM
Subject: Re: [mpls] draft-ietf-mpls-p2mp-oam-reqs


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

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