Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements

["Eric Osborne (eosborne)" <[e-mail]>]

Hi Tom-


  That's a good way to put it, and I think it captures the two opinions.  My concern with the boolean SD approach is that it's been a struggle to define SD at all for IP/MPLS networks.  I can echo Jeong-Dong's point here - SD could be server SD [SSD], it could be PM, it could be CCM.  Unless we actually define SD, it's not at all clear to me that IP SD will in fact be a simple yes/no thing.  What if we decide that both PM and SSD are valid, but that one of them is worse than the other?  

  Just so we're clear - I am not against the concept of SD in PSC.  I am against defining how we react to an event before we define the event itself.




eric


> -----Original Message-----
> From: Huber, Thomas J. [mailto:[e-mail]]
> Sent: Monday, July 22, 2013 3:04 PM
> To: Eric Osborne (eosborne); Ryoo, Jeong-dong; D'Alessandro Alessandro
> Gerardo; [e-mail]
> Cc: Huub helvoort ([e-mail]); [e-mail]
> Subject: RE: [mpls] proposed drafts for aligning MPLS-TP PSC linear
> protection protocol to transport requirements
> 
> Hi Eric,
> 
> You wrote:
> >EO#
> >I'm not sure what that would look like.  'Fail' is a pretty binary
> thing.  'Degrade' is a continuous variable, as it can be anything from
> 'a little bad' to a 'a whole lot of bad but not quite fail'.
> 
> I think this may be a fundamental difference in assumptions.  While it
> is certainly true that degradation of a signal is a continuous variable,
> in the context of protection switching in the transport network, there
> is a particular value of that continuous variable that defines the
> threshold at which the Boolean variable "signal degrade (SD)" becomes
> true.  It is for this reason that Jeong-dong and others are suggesting
> that it should be possible to incorporate the behavior of the SD state
> into the PSC definition without needing to have a precise definition of
> the mechanism for measuring the degradation of a signal.  Whatever the
> mechanism is, it will be converted to the binary SD indication.
> 
> Best regards,
> Tom
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Eric Osborne (eosborne)
> Sent: Monday, July 22, 2013 8:36 AM
> To: Ryoo, Jeong-dong; D'Alessandro Alessandro Gerardo; [e-mail]
> Cc: Huub helvoort ([e-mail]); [e-mail]
> Subject: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear
> protection protocol to transport requirements
> 
> Hi Jeong-dong,
> 
>   Thanks for the reply.  Please see inline with EO#.
> 
> > -----Original Message-----
> > From: Ryoo, Jeong-dong [mailto:[e-mail]]
> > Sent: Monday, July 22, 2013 4:15 AM
> > To: Eric Osborne (eosborne); D'Alessandro Alessandro Gerardo;
> > [e-mail]
> > Cc: Huub helvoort ([e-mail]); [e-mail]
> > Subject: RE: [mpls] proposed drafts for aligning MPLS-TP PSC linear
> > protection protocol to transport requirements
> >
> > Hi, Eric.
> >
> > Let me answer your 2nd question on SD.
> >
> > SD detection methods defined or proposed for packet transport networks
> > can be summarized as follows:
> > - By OAM performance monitoring tool:
> >   SD is raised if packet loss ratio exceeds a threshold during a
> > measurement period.
> >   Threshold value and measurement period are configured by an network
> > operator.
> >   This detection method is already defined in ITU-T G.8021 (Ethernet
> > equipment spec.)
> 
> 
> EO#  Where?  I'm not arguing that it's not in there, I'm just having a
> hard time finding it.  A search for ETH_CI_SSD doesn't yield much.  If I
> look for 'signal degrade' I see p. 131 which says that the algorithm is
> defined in G.8031.  G.8031 says ' How these defects are detected is the
> subject of the equipment Recommendations'.  I'm looking for something
> like "Signal Degrade is defined as $foo packet loss or CRC failure over
> $bar time"....what have I missed?
> 
> 
> >   and the equipment spec for MPLS-TP can easily follow the same
> > definition.
> > - By server layer indication:
> >   SD is raised if a server layer below MPLS-TP reports SD condition on
> > its own layer.
> > - By CCM packet counting:
> >   SD is raised if the loss ratio of CCM packets exceeds a threshold
> > during a measurement period.
> >
> > Regardless of how to detect SD, any protection switching documents
> > should describe the protection switching operation once such a SD is
> > declared.
> >
> ...
> > Regarding the multiple levels of SD:
> > It is certainly possible to define multiple levels of SD.
> > But, as far as the protection switching is concerned, it just needs to
> > know if SD is signaled to protection switching process or not.
> > It would be a network operator's choice at what level of SD he wants
> > his network protection to switchover.
> > In other words, what triggers protection switching is SD or no SD. It
> > is yes or no decision.
> 
> 
> EO#  I am not aware of any document which suggests that a server layer
> SD should be treated as a client layer SD.  In the IP world, if we have
> SD on a transport interface that is generally used to bring the
> interface down (i.e. SF).  This is the sort of thing I'd like to see in
> more detail, as SD in the packet world is a new concept and we can't
> just assume that it will work the same everywhere because we define
> state machine points for it.
> 
> The point about CCM is a good one.  Let's say we come up with a clever
> SD mechanism with two thresholds, call them major and minor.  For
> discussion purposes they could be simple error ratios, e.g. 1:10^6 and
> 1:10^9.  But they could be more powerful than that (flow type, flow
> length, error burst size, etc).
> 
> If we want to have SD-Major and SD-Minor inputs as separate triggers for
> PSC, we may want them at different points.  Perhaps  (leaving out the
> Working path for ease of reading)
> 
> LO
> FS
> SF-P
> SD-P-Major
> MS
> SD-P-Minor
> 
> 
> This seems like a perfectly reasonable thing to want.
> 
> 
> Even if we don't have multi-tier SD, even the single-tier SD needs to be
> defined before we can decide how to respond to it.
> 
> > The proposed draft covers SD-triggered protection no matter what kinds
> > of SD detection methods are used.
> >
> >
> > SF can also be viewed as having multiple levels of SF as the network
> > operator can also make a choice on the period/interval of CCM
> messages.
> 
> 
> EO#
> I'm not sure what that would look like.  'Fail' is a pretty binary
> thing.  'Degrade' is a continuous variable, as it can be anything from
> 'a little bad' to a 'a whole lot of bad but not quite fail'.
> 
> > If CCM is disabled, AIS from a server layer can be used as a trigger
> > for protection switching. So and so forth.
> 
> EO#  AIS from the server layer only gets you SD from the first hop of
> the underlying server path.
> 
> 
> 
> 
> eric
> 
> > However, protection switching document does not define how to detect
> > SF in anywhere.
> > Similary, protection switching document does not define how manual
> > switch and forced switch commands are initiated in a management system
> > and signaled to protection switching process.
> >
> > Again, in my opinion, the draft on SD protection can accommodate any
> > SD detection methods.
> >
> > Best regards,
> >
> > Jeong-dong
> >
> >
> >
> >
> >
> >
> > ________________________________
> >
> > From : "Eric Osborne (eosborne)" <[e-mail]> Sent :
> > 2013-07-20 02:48:28 ( +09:00 ) To : D'Alessandro Alessandro Gerardo
> > <[e-mail]>, [e-mail]
> > <[e-mail]> Cc : Huub helvoort ([e-mail])
> > <[e-mail]>, [e-mail]
> > <[e-mail]> Subject : Re: [mpls] proposed drafts for
> > aligning MPLS-TP PSC linear protection protocol to transport
> > requirements
> >
> >
> > Hi Alessandro-
> >
> > Thanks for this; the threads I started some time back seem to have
> > died down, it's good to get them going again.
> > I have two things I never quite understood, can you clarify them for
> me?
> >
> > i) can you explain EXER at a higher level? I'm not looking for a
> > description of the state machine changes, and I'm not looking for the
> > one line "It allows the FSM to be tested". We have all of that in the
> > draft and in the equivalent ITU specs.
> >
> > What I'd like to understand about EXER is where it came from. The ITU
> > specs that define it are pretty hard to follow, they seem to assume
> > the reader already knows what EXER is and what problem it solves. It
> > feels very much like a mechanism used to catch a very specific
> > implementation bug, back when transport gear was far less debuggable
> > than what we have today.
> >
> > No other state machines that I'm familiar with (RSVP, LDP, BGP, OSPF,
> > ISIS) have explicit signaling in them just to ask the neighbor whether
> > it *would* be broken if if were, in the future, to be given a
> > particular input. Part of my reluctance to get behind EXER has been
> > that I don't feel comfortable with the idea of keeping a 30-year-old
> > workaround in a protocol. Is there more to it than that? Have I
> > misread and misunderstood EXER? Does modern transport gear ever
> > actually detect a problem via EXER/RR that wasn't obvious to the
> > operator using other means?
> >
> >
> > ii) Why the push to standardize the SD state changes before we've
> > defined SD? I certainly agree that handling signal degrade is a good
> > idea, but coming up with a definition for it has been challenging.
> > What happens if we change the FSM to handle it, then come up with
> > something more sophisticated (say, multiple levels of SD) that doesn't
> > quite fit with the FSM changes?
> >
> >
> >
> > thanks!
> >
> >
> >
> >
> >
> > eric
> >
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] On Behalf
> > Of
> > > D'Alessandro Alessandro Gerardo
> > > Sent: Wednesday, July 17, 2013 3:23 PM
> > > To: [e-mail]
> > > Cc: Huub helvoort ([e-mail]);
> > > [e-mail]
> > > Subject: [mpls] proposed drafts for aligning MPLS-TP PSC linear
> > > protection protocol to transport requirements
> > >
> > > Dear all,
> > > we would like socializing the herebelow drafts that were submitted
> > some
> > > months ago with the aim to align PSC protocol (RFC 6378) to ITU-T
> > > transport requirements. I would appreciate your comments about the
> > > proposed mechanisms and behaviours.
> > >
> > > draft-rhd-mpls-tp-psc-priority-00
> > > draft-cdh-mpls-tp-psc-non-revertive-00
> > > draft-rhd-mpls-tp-psc-sd-00
> > > draft-dj-mpls-tp-exer-psc-01 / draft-osborne-mpls-psc-alive-00
> > >
> > > The above drafts cover most of items highlighted in ITU-T liaisons
> > about
> > > PSC and they propose solutions in line with MPLS-TP transport
> > > requirements.
> > > A list of main liaisons exchanged between ITU-T and IETF with the
> > > aim
> > to
> > > align PSC behavious with ITU-T transport requirements for linear
> > > protection are given below:
> > > https://datatracker.ietf.org/liaison/1162/ (June 2012)
> > > https://datatracker.ietf.org/liaison/1205/
> > > (October 2012)
> > > https://datatracker.ietf.org/liaison/1229/
> > > (January 2013)
> > > https://datatracker.ietf.org/liaison/1234/
> > > (February 2013)
> > > https://datatracker.ietf.org/liaison/1256/
> > > (May 2013)
> > >
> > > Some details abou the proposed drafts for align PSC behaviour with
> > > transport requirements:
> > >
> > > draft-rhd-mpls-tp-psc-priority-00 proposes swapping the priorities
> > > between FS and SF-P (see section 4.3.2 of rfc6378).
> > > Among the others, behaviors that will be fixed with the proposed
> > update
> > > are:
> > > Use case A) At first, working path(WP) and protection path(PP) are
> > > normal. Then, Forced Switch(FS) command is issued for maintenance on
> > the
> > > WP and the traffic moves from WP to PP. When Signal Fail occurs on
> > > PP, service cannot recover and is interrupted. This could occur for
> > example
> > > as a result of accidentally un-plugging a PP fiber.
> > > Use case B) If there is an existing signal fail on a protection path
> > > (SF-P),and FS command is issued by accident the traffic on WP will
> > move
> > > to PP. This results in an interruption of service from which you
> > > will not automatically recover, because PSC should not have switched
> > > the traffic from WP to PP.
> > > Discussion about this draft led to the proposal to modify RFC 4427
> > that
> > > was "written correctly though lacking in detail causing mis-
> > > interpretation" that led to the current PSC set of priority that the
> > > above draft is proposing to modified and to align to the required
> > > transport behavior. draft-helvoort-ccamp-fs-priority-00 has been
> > > submitted to CCAMP for clarifying the definitions related to Manual
> > > Switch and Forced Switch and their usage relative to priorities.
> > > The way this behavior has to be incorporated into the PSC has to be
> > > discussed. The text proposes to replace the current behavior with
> > > the new one. If there is consensus to procede in that way this can
> > > bring
> > to
> > > a simple and effective way to operate the protocol.
> > >
> > > --------------------------------------------------------------------
> > > --
> > > draft-cdh-mpls-tp-psc-non-revertive-00 contains the updates to
> > > RFC6378 to change non-revertive operations to behaves in the same
> > > way irrespectively of the trigger of protection switching (fault or
> > operator
> > > command FS, MS). Consequently an operator command, Manual Switch to
> > > Working (MS-W) a.k.a "Manual switch-over for recovery LSP/span" is
> > also
> > > added to enable this behavior. From an operational point of view, MS
> > to
> > > working path has also to be supported to be able to initially align
> > > at both sides in case of non-revertive switching mode. MS to working
> > > path is defined in RFC 5654, requirement 83.
> > >
> > > The proposed MS-W command is of equal priority to the existing MS-P
> > > command, and there is text to handle the simultaneous or sequential
> > > occurrence of two equal-priority commands. This behavior, already
> > > adopted in other transport network protection switching protocol,
> > > can
> > be
> > > used for other addition to the protocol in the future.
> > >
> > > --------------------------------------------------------------------
> > > --
> > > draft-rhd-mpls-tp-psc-sd-00 provides extensions to the PSC state
> > > machine to handle Signal Degrade (SD). It does not define SD or
> > provide
> > > scope around where or how SD may be used similarly as it already
> > happen
> > > in the draft in handling other defects like SF (Signal Failure).
> > > In MPLS-TP survivability framework [RFC6372], a fault condition
> > > includes both Signal Fail (SF) and Signal Degrade (SD) that can be
> > used
> > > to trigger protection switching.
> > > While the standardization lack of an SD definition and detection
> > > mechanisms, the relevant behaviors in terms of protection actions
> > > may already be defined.
> > >
> > > --------------------------------------------------------------------
> > > --
> > > draft-dj-mpls-tp-exer-psc-01 proposes adding the EXER/RR commands to
> > > test if the APS communication is operating correctly. In other words
> > > both APS process logic including state machine and APS channel on
> > > protection path, without service disruption and without affecting
> > > any protection operation, unless the protection transport entity is
> > > in
> > use.
> > > This command is documented in R84 of [RFC5654] and it is part of
> > > ITU-T transport requirements.
> > > An alternative proposal is documented in the Appendix B of RFC6378
> > that
> > > utilizes the Lockout of Protection (LO) or Forced Switch (FS) in
> > > combination of OAM functionalities. However, it has some functional
> > > limitation and has a potential risk of losing traffic as a signal
> > > failure might occur during the exercise operation. In that case, LO
> > > or FS has to be canceled to allow the PSC protocol to provide proper
> > > switching.
> > > A further alternative proposal is documented in draft-osborne-mpls-
> > psc-
> > > alive-00 that anyway show some functional limitations because cannot
> > > validate the PSC state machine status and probably the Local Request
> > > logic.
> > >
> > >
> > > The authors encourage the IETF experts to comment on these drafts,
> > > eventually proposing other options/mechanisms that can satisfy the
> > same
> > > requirements.
> > > Best regards,
> > > Alessandro, Huub, Jeong-dong, Taeksid Questo messaggio e i suoi
> > > allegati sono indirizzati esclusivamente
> > alle
> > > persone indicate. La diffusione, copia o qualsiasi altra azione
> > > derivante dalla conoscenza di queste informazioni sono rigorosamente
> > > vietate. Qualora abbiate ricevuto questo documento per errore siete
> > > cortesemente pregati di darne immediata comunicazione al mittente e
> > > di provvedere alla sua distruzione, Grazie.
> > >
> > > This e-mail and any attachments is confidential and may contain
> > > privileged information intended for the addressee(s) only.
> > > Dissemination, copying, printing or use by anybody else is
> > unauthorised.
> > > If you are not the intended recipient, please delete this message
> > > and any attachments and advise the sender by return e-mail, Thanks.
> > >
> > > rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se
> > non
> > > è necessario.
> >
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls