RE: Please Clarify Doubts regarding RGT & RNC

[neil.2.harrison@bt.com]

Ben....see below neil

> Jeurgen,
> 
> A few more comments below, 
> and a question for carriers, if any are listening.
> 
> Regards,
> Ben
> 
> Heiles Juergen wrote:
> > 
> > Ben,
> > 
> > see my comments below.
> > 
> > Regards
> > 
> > Juergen
> > 
> > > -----Original Message-----
> > > From: Ben Mack-Crane [SMTP:Ben.Mack-Crane@tellabs.com]
> > > Sent: Wednesday, March 28, 2001 5:36 PM
> > > To:   Heiles Juergen
> > > Cc:   sambasiva mantha; Vishal Sharma; 'manoj juneja'; 
> ccamp@ops.ietf.org
> > > Subject:      Re: Please Clarify Doubts regarding RGT & RNC
> > >
> > > Hello Jeurgen,
> > >
> > > I think we are in general agreement.  A few 
> clarifications are included below.
> > >
> > > Regards,
> > > Ben
> > >
> > > Heiles Juergen wrote:
> > > >
> > > > Ben,
> > > >
> > > > the characteristic information and the trail 
> termination function are directly related as the
> > > > characteristic infromation is generated/terminated by 
> the trail termination function. So I don't
> > > > see a need for additional trail termination information.
> > >
> > > Some trail termination information is not currently 
> included in the signaling,
> > > and probably should
> > > be.  For example, the Trail Trace Identifier should be 
> configured the same way
> > > at source and sink,
> > > but is not currently in the signaling spec (but certainly 
> not as part of Signal
> > > Type).
> >         [Juergen Heiles]  Configuration of the trail trace 
> is an open issue I agree.
> > Draft-harrison-mpls-oam-00.txt proposes a trail trace 
> (Connectivity verification CV OAM packets)
> > for MPLS and suggest that the configuration of the trace is 
> done via LSP signaling at LSP set-up.
> 
> In the MPLS (packet) case we have proposed that a standard 
> convention be used to
> create the TTSI (trail trace ID) from the Router ID of the 
> ingress LSR and the local
> ID for the LSP on that LSR.  We think this information is 
> already in the signaling
> messages (although the local ID should be 4 octets and only 2 
> are allocated in the
> current signaling drafts).  If this is also acceptable for 
> SONET/SDH trails, that
> would solve the problem, but I don't know if that is true.  
> Carriers may have other
> conventions already in use for assigning trail trace IDs and 
> may not want to change.
> 
> Do you have any insight into this?  
> 
> Would any carriers like to comment?
NH=>Carriers usually pay attention to differentiating the OAM required for
the user and control planes......since in CO networks they are usually
disjoint in both function and routing (and hence the failure modes are
different).  This is normal practice.  Hence, you will find in technologies
like SDH/Sonet, where carriers have had a large hand in the specification,
that these issues are attended to from the outset.  So there are trail trace
functions to ensure correct connectivity in SDH/Sonet.  There are not trail
trail functions in plain MPLS which, ironically, has a richer set of
potential failure modes.  The ID that you/I/others put together addresses
this and, perhaps just as importantly, goes on the demonstrate how we can
simply measure availability......which is perhaps *the* most important perf
metric for any carrier to measure.  This latter point is not trivial, and I
suspect many have not grasped the importance of what we put in this ID.  We
also look at consequent actions.....again something that is normally 2nd
nature for carriers in order to protect customers, stop alarm storms and
give Ops people useful diagnostic tools.  So, in summary, we don't need our
CV flow for SDH/Sonet but we do for plain MPLS.
> 
> > 
> > > Also Payload
> > > ID should be set properly, but this can be inferred 
> (translated) from the GPID
> > > that is signalled.
> >         [Juergen Heiles]  The payload ID/Signal lable is 
> not configurable as such, it is fixed
> > defined by the adaptation function. What is configurable is 
> the type of adaptation function itself
> > if the network element provides this flexibility. As you 
> noted the GPID is equivalent to the payload
> > ID/signal label.
> >         It should be noted that the LSP isn't necessarily 
> used to setup a network connection between
> > two trail terminations. I can also be used to setup 
> sub-network connections. In the later case you
> > don't know the payload ID and specific GPID.
> 
> Good point.  In fact, it may be that for many SNC cases the 
> GPID will be set to 0 (unknown)
> since the client layer may not be known (and is not relevant).
> 
> > 
> > >  I don't know if there is other trail termination info 
> that should be signalled
> > > between the endpoints.
> > > Do you have any thoughts on this?
> >         [Juergen Heiles]  Tandem Connection Monitoring and 
> setup of the TCM level might need some
> > thoughts. Do we want to setup TCM automatically via LSP 
> signaling at all?
> 
> It would be reasonable to support signaled setup of TCM, 
> particularly in the case of SNCs.
> For example, if the service is an SNC across a carrier's 
> network, TCM may be required
> to monitor the SLA for that SNC (the extent of the service 
> provided by the carrier).
NH=> TCM is very useful and should be considered as necessary *when* the
layered technology has a fixed hierarchy, eg ATM, SDH/Sonet.  This is not
true for plain MPLS (and this is one of its strengths).  If a carrier wants
to measure a 'SNC' that carrier can simply set up a new lower server LSP for
the SNC partition considered......however, unless it has proper OAM (and can
differentiate up/down-states to correctly assign availability and QoS metric
measurements) then its real value is diluted.  This ability (to set up
arbitrary levels of LSP trails) is also a very useful feature for prot-sw
for carriers....but again requires decent OAM.
<snipped to end NH>