Re: [mpls] Question regarding SD protection in draft-ietf-mpls-tp-psc-itu

Jeong-dong,

Is this simply a matter of terminology. Each layer needs to perform its
own protection switching, i.e. there has to be a *bridge funtion* and a
*selector function* (on each layer depending on the implementation);
while *bridge* and *selector* are the physical layer entities?

/Loa

On 2013-12-26 12:51, Ryoo, Jeong-dong wrote:
> Yaacov, thanks for your email. Somehow, I forgot to respond and am sorry
> for the delay.
>
> First of all, Yaacov, it is not true that the protection switching of
> Ethernet or SDH describes the operation of any layer below. Rather, each
> layer is supposed to operate independently. However, there are a few
> exceptions, such as hold-off timer and AIS (as a trigger from lower
> layer). Even though there exist some proprietary implementations that
> use other information from lower layer, most of them are not recommended
> in ITU-T standards.
>
> Bridge and selector are not in the physical layer, but they are part of
> protection switching. One of the important output actions from the PSC
> control logic is coordinating the positions of bridge and selector.
> Also, the bridge operation responding to the PSC control logic is also
> part of protection switching. However, how to realize the bridge and
> selector (for example, how to manipulate a packet forwarding mechanism)
> is an implementation matter.
>
> When we mention 1+1 or 1:1 in protection architecture, we deal with the
> operation of bridge. For 1+1 architecture, the traffic needs to be
> duplicated at the sender and sent to both paths all the time, which is
> the same description as the “permanent bridge”. For 1:1 architecture,
> “selector bridge” is used to send the traffic only one of the paths. As
> the protection path can be used by best traffic in packet networks and
> the packet duplication takes much more effort/internal bandwidth inside
> a switch than the time slot copy of circuit networks. 1:1 is considered
> as preferable architecture in packet networks.
>
> As you might recall from G.8031 – Ethernet linear protection, the
> selector bridge is not recommended due to the traffic flapping under SD
> conditions on both paths. Instead “broadcast bridge” is introduced to
> support protection switching against SD. But, this broadcast bridge is
> not recommended in non-revertive mode as the working path needs to be
> occupied by traffic all the time. Also the broadcast bridge is not
> efficient, since by definition, the packet duplication should occur
> during not only SD but also SF, FS, MS, etc. In this document, we are
> introducing an improved bridge mechanism, which behaves like a selector
> bridge but duplicates the traffic only under SD condition, and we
> believe that it addresses all the issues with existing bridges.
>
> What we mean by SD protection is agnostic to the SD detection method is
> that the proposed SD protection method (again how to operate a bridge or
> what brige is used is a part of protection switching) can be used no
> matter what kind of SD detection methods (data packet counting, CCM
> packet counting, or even proprietary server layer SD detection) is used.
>
> I think I answered all the questions on your email.
>
> Yaacov, if you have any further concerns or questions, please let me know.
>
> Best regards,
>
> Jeong-dong
>
>
>
>
> ------------------------------------------------------------------------
> *From : *"Yaacov Weingarten" <wyaacov@gmail.com>
> *Sent : *2013-12-10 16:04:17 ( +09:00 )
> *To : *Ryoo, Jeong-dong <ryoo@etri.re.kr>
> *Cc : *draft-ietf-mpls-tp-psc-itu@tools.ietf.org
> <draft-ietf-mpls-tp-psc-itu@tools.ietf.org>, mpls@ietf.org <mpls@ietf.org>
> *Subject : *Re: Question regarding SD protection in
> draft-ietf-mpls-tp-psc-itu
>
> Jeong-dong, hi
>
> Thank you for your reply. Your answer seems to be an appropriate answer
> for other SDOs, not sure that it is true for the context of MPLS and
> IETF work.
>
> 1. You wrote "any protection switching (including PSC) is supposed to
> describe the operation of bridge and selector." - this may be true for
> Ethernet andSDH and for documents that are describing the operation of
> the physical layer. However, the IETF (to my understanding - and I am
> certainly willing to be corrected on this point) is concerned with the
> protocol and leave the lower layers to implementation. Also, I am not
> sure that the concepts of Bridge and Selector really apply to MPLS
> (although I admit that we did mention them in the original PSC definition).
>
> 2. You cite what was written in G8031 as justification for including
> content into your draft. Again it is hard to transfer methodology from
> one SDO to another and therefore, while I highly respect the work of the
> ITU, I do not feel that this is a very clear justification for inclusion
> into an internet-draft. Even when the draft states that its purpose is
> to address the concerns of the ITU.
>
> 3. To the actual point of my earlier comment, that you do not seem to
> address - the paragraph in Section 7.3 seems to state that SD protection
> changes according to the method that is used to detect the SD. This
> means that SD protection is not agnostic to the method used for the
> detection.
> Alternatively, we could break this dependence and state that SD
> protection is always provided by changing the transmission of the data
> to 1+1 protection in cases of SD detection, which is what the paragraph
> is suggesting to do for some cases.
>
> I hope this formulation make my comment clearer and we are able to
> discuss the technological approach rather than the philosophical
> differences.
>
> Thank you,
> yaacov
>
>
> On Mon, Dec 9, 2013 at 10:04 PM, Ryoo, Jeong-dong <ryoo@etri.re.kr
> <mailto:ryoo@etri.re.kr>> wrote:
>
>     Yaacov,
>
>     Yes, PSC is supposed to be agnostic to the method used for the
>     detection of SF/SD.
>
>     It is also true that any protection switching (including PSC) is
>     supposed to describe the operation of bridge and selector.
>
>     As there are multiple options for detecting SD, we needed to
>     describe the behavior of the bridge to cover all the possible
>     detection methods. Describing the operation of bridge for SD
>     protection is not a new thing. For example, G.8031 - Ethernet linear
>     protection also describes what bridge can be used in order to
>     provide protection against SD.
>
>     Best regards,
>
>     Jeong-dong
>
>
>
>
>     ------------------------------------------------------------------------
>     *From : *"Yaacov Weingarten" <wyaacov@gmail.com
>     <mailto:wyaacov@gmail.com>>
>     *Sent : *2013-12-08 20:01:55 ( +09:00 )
>     *To : *draft-ietf-mpls-tp-psc-itu@tools.ietf.org
>     <mailto:draft-ietf-mpls-tp-psc-itu@tools.ietf.org>
>     <draft-ietf-mpls-tp-psc-itu@tools.ietf.org
>     <mailto:draft-ietf-mpls-tp-psc-itu@tools.ietf.org>>, mpls@ietf.org
>     <mailto:mpls@ietf.org> <mpls@ietf.org <mailto:mpls@ietf.org>>
>     *Cc : *
>     *Subject : *Question regarding SD protection in
>     draft-ietf-mpls-tp-psc-itu
>
>
>     Hi,
>
>     After reading through your draft on the extensions to PSC to support
>     SD situations, I have a question for clarification -
>     In your introduction - you state that the method used to detect SD
>     situations is out-of-scope of the document. Does this mean that PSC
>     is supposed to be agnostic to the method used for this detection? It
>     should react only to the indication, similarly to the reaction and
>     relationship to the method for detecting and declaring a SF situation.
>     However, when you explain the behavior of the SD protection in
>     section 7.3 you have a paragraph that starts with "If the detection
>     of a SD depends on the presence of user data packets ..."  that
>     seems to indicate that the behavior of the system is dependent upon
>     the detection method! Clarification would be appreciated.
>
>     --
>     Thanx and BR,
>     yaacov
>
>     /Still looking for new opportunity/
>
>
>
>
> --
> Thanx and BR,
> yaacov
>
> /Still looking for new opportunity/
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>

-- 

Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64