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

[neil.2.harrison@bt.com]

Hi Steven....many thanks for your comments.....I have tried to answer as
best I can below.

regards, Neil

steven wright observed 31 May 2001 19:05
> 
> A couple of Points....
> 1) Reqt#10
> I think there is a class of errors associated with us the use of LSP
> hierarchies that may not be covered here ?
> Consider that a provider may have several TE LSPs ( e.g. with 
> different QoS)
> across a core network  into which lower level LSPs are label 
> stacked. Even
> though they may get to the right destination, they may get 
> there through the
> "wrong"  label stacked path.
> unless you think this is covered under one of the other 
> topics, I's suggest
> adding  something like ...
>      "(e) Incorrect use of Label hierarchy"
NH=> Now that is a novel one...I think we need to think about that.  If this
ever happened it would be undetectable at present (in any technology I can
think of, not just MPLS)...and specifically here, since the trail
termination source identifier (TTSI) is only checked at the *peer* trail
termination sink point in CV packets, then everything would seem OK.  It
would be possible to detect this if at every LSP trail termination point the
immediate client layer CV flows were all checked against some database of
what is supposed to be going through that egress point.  In other words, at
the LSP layer N we check:
-	CV flow for layer N LSP
-	CV flow for all layer N-1 LSPs supported by the server LSP at layer
N (no need to go higher...proving this mechanism recurses)
This solution may, on reflection, be OK.  Shahram/Ben...have you any views
on this (noting that some record of clients is needed anyway to forward FDI
correctly)?

You could also possibly discover such a defect via some form of
route-trace....but this would have some other complications and, by
definition, would not detect the effect anyway.....so some other method of
knowing when/where to look would be needed anyway to trigger such a search.
> 
> 2) A missing Requirement on the "scope" of OAM mechanisms?
>  The other OAM requirements result in a need to insert some 
> packets into the
> LSP in order to measure continuity, performance etc.
> We need to ensure that such packets are :
> (i) restricted to the service provider's network i.e do. not 
> pass beyond the
> egress of the LSP into a customer network
> ( I'll let braver souls debate what that means with respect 
> to penultimate
> hop popping ! 8^} )
> (ii) not spoofed by customer traffic in the LSP data plane.
> 
> I'm not sure how you would meet the security requirements 
> stated ins section
> 5 without this.
> I believe the mechanisms proposed in 
> draft-harrison-mpls-oam-00.txt did
> attempt to do this..
> 
NH=> Yes you are correct, I have thought about this and some suggestions
were given in the 'solutions' ID that you mention.
> 
> 3) This is editorial ...
> I'd be tempted to refer to "mechanisms" rather than "tools" in a
> requirements document. "Tools" sound like products. 
> "mechanisms" may have a
> variety of implementations including   protocol extensions as well as
> specific tools.
NH=> OK.
> 
> Motivations #7 and #10 seem to be saying the same thing to me 
> (and one I'd
> agree with!). I'd suggest either merging them or rephrasing 
> to explain why
> they are different...
NH=> I agree....I have already pointed this out to the team (as well as a
load of other changes I feel are needed)
> 
> 
> regards
> Steven Wright
> 
> 
> > -----Original Message-----
> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf 
> Of Shahram
> > Davari
> > 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>>
> >
> 
>