[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Please Clarify Doubts regarding RGT & RNC
Neil,
Is it your opinion, then, the the equipment providers that predominate the
IETF are missing the boat vis a vis OA&M?
Frank Hujber
fhujber@hotmail.com
----- Original Message -----
From: <neil.2.harrison@bt.com>
To: <Ben.Mack-Crane@tellabs.com>; <Juergen.Heiles@icn.siemens.de>
Cc: <sambu.mantha@usa.alcatel.com>; <vishal@JasmineNetworks.com>;
<manojkumarjuneja@hotmail.com>; <ccamp@ops.ietf.org>
Sent: Friday, March 30, 2001 1:09 AM
Subject: RE: Please Clarify Doubts regarding RGT & RNC
> 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>
>
>