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

[Yaacov Weingarten <[e-mail]>]

Alessandro, hi

I guess I was not very clear in my presentation - my point had very little
to do with how to detect or measure SD but rather with what is the purpose
of performing a protection switch.

My understanding of the purpose is to guarantee a certain quality of
service.  Therefore, in the case of SF you switch to the protection path
that is working to continue the service.  The question in the SD case is
(and was back when it was first discussed) - how do I know that the
protection path will give a better quality of service when I switch over?
Could I be switching to a path that is providing lower quality? And if so,
why am I performing the switchover?

Hope this clarifies,
yaacov


On Wed, Jul 24, 2013 at 10:11 AM, D'Alessandro Alessandro Gerardo <
[e-mail]> wrote:

>  Dear Yacov,
> I understand your points but we are again moving the discussion to the
> problems in defining sd and the method to detect sd neglecting the costs
> that carriers have to face with in introducing such functionality later on
> in the network.
> Best regards
> Alessandro
>
>
> Inviato da Samsung Mobile
>
>
>
> -------- Messaggio originale --------
> Oggetto:Re: [mpls] 回复： proposed drafts for aligning MPLS-TP PSC linear
> protection protocol to transport requirements
> Da:Yaacov Weingarten <[e-mail]>
> A:"[e-mail]" <[e-mail]>
> Cc:"Eric Osborne (eosborne)" <[e-mail]>,"Ryoo, Jeong-dong" <
> [e-mail]>,D'Alessandro Alessandro Gerardo <
> [e-mail]>,"Huub helvoort (
> [e-mail])" <[e-mail]>
>
>
>
>  Hi all,
>
> While I personally support the idea of including the SD support in the
> Linear Protection protocol, if only for compatibility with other comparable
> tools, I feel there is a need to add the context that caused it to be
> "downgraded" to place-holder status in PSC.
>
> In the original draft versions of the PSC definition, we included SD
> messages and described the switching operation when the system triggered an
> SD situation. On the assumption that there would be a way to detect some
> kind of SD. There were even some drafts that were proposed by different
> members on how to define SD and detect it for MPLS. None of these latter
> drafts were, however, accepted by the WG based upon the belief that SD is
> not relevant at the MPLS level, it is more a system-layer or physical layer
> issue and should be solved by those layers.
>
> In addition, regarding the idea of switching the traffic from the working
> to the protection path based on an SD situation on the working path was
> frowned upon. This was based on the question of how do we assure that the
> protection path is a better medium for the packet transport. Because even
> if you could measure and identify an SD situation on the working path,
> there is no way to measure it on the protection path, since it is most
> probably affected by the load factors involved in the packet sizes.
> Therefore, you are switching to a path that, at least in theory, could be a
> worse choice!
>
> This was the reasoning behind the downgrade of the SD signal and the note
> that this is for further study.  I have not seen anyone in this discussion
> address this issue, and therefore I think it is important that we hear some
> justification for switching away from a working path to one that we have no
> better information on! I think that the justifications given until now -
> i.e. "this is the way it has always been done in physical layer systems"
> - are not sufficient to add functionality that may cause poorer performance!
>
> Hope this helps focus the discussion,
> yaacov weingarten
>
>
> On Wed, Jul 24, 2013 at 4:46 AM, Larry <[e-mail]> wrote:
>
>>  Hi all,
>>
>>  I agree with Tom and Jeong-dong. There are different reasons to cause
>> SD, but the result is the transport performance degrade and it is important
>> to let operators set a threshold to trigger protection switch. During the
>> trouble shooting, operators need tools to do fault localization. Althought
>> "degrade" is a continous variable behaviour, it is a "0/1" problem after
>> defining the threshold.
>>  Thank you!
>>
>> *************************************************************************
>> Han Li, Ph.D
>> China Mobile Research Institute
>> 32 Xuanwumen West Street, Xicheng District, Beijing 100053, China
>> Fax: [phone]
>> MOBILE: [phone]
>> *************************************************************************
>>   ------------------------------
>> *发件人：* "Huber, Thomas J." <[e-mail]>
>> *收件人：* Eric Osborne (eosborne) <[e-mail]>; "Ryoo, Jeong-dong" <
>> [e-mail]>; D'Alessandro Alessandro Gerardo <
>> [e-mail]>; "[e-mail]" <[e-mail]>
>>
>> *抄送：* "Huub helvoort ([e-mail])" <
>> [e-mail]>; "[e-mail]" <
>> [e-mail]>
>> *发送日期：* 2013年7月23日, 星期二, 3:03 上午
>> *主题:* 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
>> _______________________________________________
>> mpls mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>>
>>
>> _______________________________________________
>> mpls mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>>
>
>
> --
> Thanx and BR,
> yaacov
>
>  *Still looking for new opportunity*
>     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.*
> *[image: rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa
> mail se non è necessario.*
>
>


-- 
Thanx and BR,
yaacov

*Still looking for new opportunity*