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

[Huub van Helvoort <[e-mail]>]

Hello Loa,

You replied:

> Is this simply a matter of terminology.

I think it is.

> Each layer needs to perform its
> own protection switching, i.e. there has to be a *bridge function* and a
> *selector function* (on each layer depending on the implementation);

I f you want to refer to the functionality, then we should consequently
also use *protection switch function*.
A *protection switch* is also a physical entity...

> while *bridge* and *selector* are the physical layer entities?

Best regards. Huub.


> 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" <[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 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 <[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/
>>
>>
>> _______________________________________________
>> mpls mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>


-- 
*****************************************************************
               请记住，你是独一无二的，就像其他每一个人一样