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

["Ryoo, Jeong-dong" <[e-mail]>]

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" <[e-mail]>
Sent : 2013-12-10 16:04:17 ( +09:00 )
To : Ryoo, Jeong-dong <[e-mail]>
Cc : [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
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 and SDH 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 <[e-mail]<mailto:[e-mail]>> 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" <[e-mail]<mailto:[e-mail]>>
Sent : 2013-12-08 20:01:55 ( +09:00 )
To : [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
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