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

Tom,

<snipped>
Tom N said 21 December 2004 21:25
> > 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.
> 
> 	I don't see why the second or third sentences need to 
> be a MUST, especially since they have no corresponding justification.

NH=> One of the things that has concerned me for a long time is that we
do not have a consistent way of addressing the access points of MPLS
LSPs......their addressing is currently a function of the signalling
used.  This is wrong.  The access point addresses of the traffic
data-plane trails should have nothing to do with the control-plane, and
they should be the SAME no matter how the trail is instantiated, ie by
signalling protocol X, Y or Z or by management provisioning.  Why?
Because a CV OAM function is a common theme to all network modes.  This
'comes for free' in the cl-ps mode as each pkt constains a SA, but we
have to consciously add this CV function to the co modes. Using the SA
is an obvious and natural way to provide this CV function.  Thus, if 2
trails interfere with each other (eg swaps or misbranch/mismerge) one
wants a consistent and simple method of defect detection across the
whole trail population no matter how the trail was instantiated.

Now I am not sure what whoever wrote the above had in mind, but in my
view the above point is relevant and provides a strong justification.
In the case of a p2mp construction one is obviously sending the SAME SA
in a CV function to all the sinks....which is indeed the correct
behaviour.

Providing we have the SAME CV mechanism on both p2p and p2mp
constructions AND it is unidirectional (for the reasons I gave in my
previous mail) then we can clearly handle defects BETWEEN p2p and p2mp
constructions in a similar manner.  Surely that has to be a
good/simplifying property.
> 
> >    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.
> 
> 	This sentence seems to indicate that precise OAM 
> requirements are out of the scope of this document -- so why 
> then do the preceding two sentences provide requirements for 
> OAM for p2mp TE LSPs?! Based on this, the preceding two 
> sentences should be removed from this document and put into a 
> place where there are in the scope of the document (i.e.: 
> MPLS OAM Requirements). :P

NH=> Fair point PROVIDING the requirements clearly address the right
behaviour.  I think we have to differentiate the 2 cases of OAM:
-	simple 'always-on' defect detection/handling stuff.....the base
requirement being the CV and FDI (higher layer alarm suppression)
functions;
-	the more complex 'on-demand' diagnostic and PM functions....and
whilst the former defect detection/handling OAM can (and should) be
harmonised across both p2p and p2mp cases for the reasons I gave above,
I can imagine that diagnostics and PM OAM requirements are going to be
somewhat different (generally more complex for the p2mp case).

regards, Neil

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