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-sig-requirement-00.txt
Hi Neil, Thanks very much for the clarification! /Monique On 21/12/04 9:09 am, "neil.2.harrison@bt.com" <neil.2.harrison@bt.com> wrote: > Hi Tom/Monique, > > I agree with you on the assumption that the requirements are indeed > correct. When we are dealing with either of the co modes there is a > particularly important requirement on the base defect detection/handling > OAM (this is quite different to any ad hoc OAM for diagnostics or > Network Performance measurements say)....that is the OAM MUST: > - reside in the data-plane of the traffic it is > protecting/monitoring > - be unidirectional. > > The latter requirement is rather important for these reasons: > > 1 the consequent actions (such as traffic suppression, raising > local alarms, sending FDI to suppress higher layer network alarms, etc) > MUST be done at the trail sink. > 2 allows both p2p and p2mp cases to be handled scalably in a > similar manner. > > For p2p cases there is a further requirement: > > 3 Virtually all applications using p2p trails have a > bi-directional availability requirement, ie if either direction fails > then it is usual for the application to fail. This means unavailability > needs to be considered as an OR function of each direction. The > implication of this is that any Network Performance measurements that > are in force for SLA purposes MUST be suspended in both directions when > the unavailable state is entered (in EITHER direction). However, in the > available state Network Performance is a unidirectional measurement. > Note also here: > - that Net Perf measurements must also be coupled to the trail > sink and are clearly unidirectional themselves > - that there is a required 'ordering' of processes, viz: > * mode defines relevant defects and required OAM (they are > different in in each network mode); > * defects must be defined in terms of entry/exit criteria and > consequent actions; > * if we want to keep things simple (and I recommend we do), > entry/exit of the unavailable state should be based only on defect > persistency, ie don't include network performance metrics in this if > possible; > * once we have clearly defined available and unavailable 'time' > we have a correct basis for the measurement of network performance > SLAs....noting that both (un)availability and network performance SLAs > are important, but unless the above ordering is taken into account the > process of network performance measurements can be made either very > complex or meaningless. > > regards, Neil > >> -----Original Message----- >> From: mpls-bounces@lists.ietf.org >> [mailto:mpls-bounces@lists.ietf.org] On Behalf Of Monique Morrow >> Sent: 21 December 2004 12:55 >> To: Thomas D. Nadeau; mpls@ietf.org >> Subject: Re: [mpls] draft-ietf-mpls-p2mp-sig-requirement-00.txt >> >> >> I support this recommendation Tom -- this would be most efficent. >> >> /monique >> >> >> On 21/12/04 7:27 am, "Thomas D. Nadeau" <tnadeau@cisco.com> wrote: >> >>> >>> I have a comment on draft-ietf-mpls-p2mp-sig-requirement-00.txt. >>> The paragraph below seems to on the one hand, have no >> requirements as >>> is stated in the last paragraph, does give a requirement. I suggest >>> that this document simply refer to >>> draft-ietf-mpls-oam-requirements-05.txt, since the WG agreed to >>> include all MPLS OAM-related requirements in this draft. >>> >>> --Tom >>> >>> >>> 4.18 P2MP MPLS OAM >>> >>> Management of P2MP LSPs is as important as the management of P2P >>> LSPs. >>> >>> The MPLS and GMPLS MIB modules MUST be enhanced to >> provide P2MP TE >>> LSP management. >>> >>> In order to facilitate correct management, P2MP TE LSPs >> MUST have >>> unique identifiers. >>> >>> OAM facilities will have special demands in P2MP environments >>> especially within the context of tracing the paths and >> connectivity >>> of P2MP TE LSPs. The precise requirements and >> mechanisms for OAM are >>> out of the scope of this document. It is expected that >> a separate >>> document will cover these requirements. >>> >>> _______________________________________________ >>> 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
|
|