Re: [mpls] draft-ietf-mpls-p2mp-sig-requirement-00.txt

[Monique Morrow <[e-mail]>]

Hi Neil,

Thanks very much for the clarification!

/Monique


On 21/12/04 9:09 am, "[e-mail]" <[e-mail]>
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: [e-mail]
>> [mailto:[e-mail]] On Behalf Of Monique Morrow
>> Sent: 21 December 2004 12:55
>> To: Thomas D. Nadeau; [e-mail]
>> 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" <[e-mail]> 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
>>> [e-mail] https://www1.ietf.org/mailman/listinfo/mpls
>> 
>> _______________________________________________
>> mpls mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/mpls
>> 

_______________________________________________
mpls mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mpls