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

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

Loa,

I am not sure I understand your question correctly, but I would say that:
Each layer has its own bridge and selector for protection switching, so that each layer can perform protection switching of its own.
I am not sure what you mean by "bridge/selector function", but in ITU-T terminology, the bridge and selector are included in "connection function" of its own layer  (for example, MT_C for MPLS-TP connection function, which includes the bridge and the selector for the MPLS-TP layer).
For the PSC RFC, I don't think we need to introduce any new terminology such as the "bridge/selector function" or "connection function".
The bridge/selector have already been introduced in the RFC6378 (MPLS-TP linear protection).

Best regards,

Jeong-dong


________________________________
From : "Loa Andersson" <[e-mail]>
Sent : 2013-12-26 16:07:15 ( +09:00 )
To : Ryoo, Jeong-dong <[e-mail]>, Yaacov Weingarten <[e-mail]>
Cc : [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject : 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"
> *Sent : *2013-12-10 16:04:17 ( +09:00 )
> *To : *Ryoo, Jeong-dong
> *Cc : *[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 > > 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" > >
> *Sent : *2013-12-08 20:01:55 ( +09:00 )
> *To : *[e-mail]
>
> > >, [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
>

--


Loa Andersson email: [e-mail]
Senior MPLS Expert [e-mail]
Huawei Technologies (consultant) phone: [phone]