RE: draft-harrison-mpls-oam-req-00.txt

[neil.2.harrison@bt.com]

Thanks for your comments Bob.....here a response on behalf of Shahram and
the rest of the authors:
Natale, Robert C (Bob) wrote 29 May 2001 22:56

> Hello Shahram and the rest of the authors of this ID,
> 
> First, I do applaud the initiative and the effort invested in
> this work...I think it is a very important topic for the WG to
> address.
NH=> Thanks.  We think so too, and something like this will be needed by
operators if MPLS is to 1-day realise it full potential.

>  However, I do wish to offer some feedback -- hopefully
> you will see it as constructive -- for further consideration.
> 
> 1.  I am curious as to why you address "OAM" only, rather than
>     "OAM&P".  It seems to me that -- over and above being
>     important in its own right -- provisioning capabilities may
>     be extremely helpful to realizing some of the "motivations"
>     and satisfying some of the requirements you cite.
NH=> Can you help us out by providing some examples of what you mean by this
please Bob....I have my own interpretation but I would not wish to guess at
what you mean here.
> 
> 2.  I am somewhat skeptical about the focus on the user-plane
>     versus the control-plane, management-plane, and interface(s)
>     between the latter two.  Ensuring that we design control-
>     plan capabilities and functionality to proactively avoid
>     (minimize) the kinds of (legitimate) worries expressed in
>     your "Motivations" #3 and #4, for example, should be a
>     high priority for us.
NH=> Understand.  But the appropriate solutions depends on one's networking
scenario.  Things change as one moves from a pure CNLS mode to a pure CO
mode (and there are grey shades in between extreme examples of these).  In a
pure CNLS mode then user-plane = control-plane (or to be more precise, the
routing facet of the control-plane since there is no signalling facet).
MPLS LDP LSPs move 1 step closer to the CO mode and explicity routed (ie
signalled) RSVP/CR-LDP LSPs move a another step.  Once we consider GMPLS
then there is (an almost forced) decoupling between the *transport networks*
used for control-plane aspects and the user-plane.  The user-plane (of both
'external' customer trails and the 'internal' signalling/control-plane
trails) needs their own OAM.  Above this, the individual protocols that then
use the user-plane of the signalling/control-plane network (hope this makes
sense) also need their own OAM (to detect protocol failures, which are only
relevant to a given protocol maybe). I have seen some of the recent
discussion on RSVP Hellos vs LMP Hellos (etc) which I hope reinforces this
point, ie we need OAM for the basic links (which are formed from server
layer trails.....so we are talking about server layer trail path overhead
here for user-plane OAM) in a user-plane sense, and also OAM for the
individual protocols which use such user-plane links/trails since they are
functionality subject to additional processing and hence additional failure
modes.

As regards the point on (measuring) availability performance in #4, one has
to look at what the user is actually experiencing for an accurate
assessment.  As an example to illustrate my point, I could consider a case
where failures of the control-plane should not impact the user-plane, ie a
requirement that *existing* user-plane connections must not be affected
simply because the control-plane has failed (in some respect).  This is
quite an obvious requirement in the case of GMPLS for SDH/OTN
trails....perhaps less obvious/required in the case of MPLS LSPs maybe, but
if we ever had S-PVC-like LSPs here then this would be an important
requirement.  So my view is make sure the basic architecture is right from
the start so that all such scenraios can be catered for.
> 
> 3.  I am very skeptical about the focus on "tools" versus
>     "capabilities", "features", "protocols", "interfaces" and
>     so forth...you use "mechanisms" at one point and that is
>     ok with me.  "Tools" sound like things we let the marketplace
>     develop and deploy in response to the specs we design...?
NH=> I guess the key point here is that we were trying not to be too
prescriptive, ie every operator/vendor must not be forced to use all the
things we suggest.  Maybe the wording is not good enough?
> 
> 4.  For example, in your "Requirements" section, the concluding
>     sentence of #2 says: "It is necessary that be detected and
>     notified automatically without operator intervention for this
>     purpose."  I agree completely.  However, I read that as a
>     strong mandate for control-plane capabilities.
NH=> As I noted above, it depends on your network scenario.  The main points
intended here however run something like this:
-	need local user-plane defect detection (so these need clear
specification wrt entry/exit);
-	need to take appropriate actions in all relevant planes, eg tell
client layers of failure (to stop alarms being incorrectly raised in their
user-planes.....especially important in inter-domain/international cases);
raise local management-plane alarm; tell control-plane (if appropriate) to
invoke a prot-sw/restoration.
> 
> 5.  Wrt "Requirements" #4, scalability should mean "cost-
>     effectively in smaller-scale networks" as well as
>     "stably [or whatever] in large-scale networks".
NH=> I agree.  The wording here is not good enough, and something along the
lines you suggest would be more appropriate.
> 
> 6.  "Requirements" #6 sounds very close to app-level design
>     (as do some other parts of the document).  While I agree
>     with most of the objectives stated in this respect, it is
>     an area that the IETF traditionally leaves to others to
>     resolve.
NH=> The intention here was not to imply this is something that we wish to
see forced on everyone (depends on their network needs), but if someone
considers these functions useful then should be able to ask for them.
> 
> 7.  "Requirements" #7 *seems* to be written from the wrong
>     perspective.  That is, it is not that "LSRs that do not
>     support such functions must silently discard..." but
>     rather that any specified new protocol features must not
>     disrupt traffic processing in LSRs that do not support
>     the features.  The intended outcome is the same, I know...
>     but the suggested perspective will help to ensure that
>     no backwards-incompatible features are introduced --
>     unless they are consciously intended.
NH=> Understood.  The intention was to make sure that any solutions (to
these requirements) were indeed backwards compatible with equipments that
did not recognise them.
> 
> 8.  "Requirements" #8 (measurements) seems like another clear
>     example of control-plane functionality to me...ditto for
>     #13 (failure detection).
NH=> On #8 it depends on whether a reliance on (some aspect of) the
control-plane is sufficient.....as I noted above, things change as one moves
from a truly CNLS mode to a truly CO mode, especially with control/bearer
separation.  On #13 this was simply a statement of something that is all too
common today, ie awaiting for the complaint to roll in.  We see this on all
types of layer network we have deployed......some of these are down to
vendor 'bugs' others are down to inadequate OAM capabilities. 
> 
> 9.  I also found some of the general wording (e.g., the various
>     uses of "layer network") to be confusing, but that might
>     just reflect lack of familiarity on my part.
NH=> Layer network is a well understood term by most operators and major
vendors, and it is in common usage in ITU as described in G.805 on
functional modelling.  There are also a few text books dealing with this
powerful concept for describing networks....and I can recommend this one,
especially to anyone working on GMPLS:
Broadband Networking: ATM, SDH, and SONET, Andy Reid and Mike Sexton
Artech House; ISBN: 0890065780 
> 
> In sum, I think this is important work and that it needs to be
> expanded (to cover "OAM&P") and honed more toward control-plane
> features and the control-plane/management-plane interface(s).
NH=> Many thanks for your constructive remarks.
> 
> Thanks,
> 
> BobN
> 
> > -----Original Message-----
> > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> > Sent: Friday, May 18, 2001 6:32 PM
> > To: 'internet-drafts@ietf.org'
> > Cc: 'mpls@uu.net'; 'te-wg@ops.ietf.org'
> > Subject: draft-harrison-mpls-oam-req-00.txt
> > 
> > 
> > Hi,
> > 
> > Please post the attached draft.
> > 
> > Summary:
> > 
> > This draft provides motivation and requirements for user-plane OAM 
> > (Operation and Maintenance) functionality in MPLS networks.
> >  
> > Motivation for this recommendation rose from Network 
> operators' need 
> > or tools that ensure reliability and performance of MPLS LSPs 
> > (Label Switched Paths). User-plane OAM tools are required to verify 
> > that LSPs have been setup and are available to deliver 
> customer data 
> > to target destinations according to QoS (Quality of Service) 
> > guarantees given in SLAs (Service Level Agreements). 
> >     
> > Requirements presented in this draft include but are not 
> limited to: 
> >     
> >  . Tools to efficiently detect and localize defects in MPLS layer 
> >  . Mechanisms for fast defect notification 
> >  . Availability and performance criteria 
> >  . Trigger for corrective actions (e.g. protection switching) when 
> >      failures occur. 
> > 
> > 
> > Regards,
> > -Shahram Davari
> > 
> >  <<draft-harrison-mpls-oam-req-00.txt>> 
> > 
>