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

From: Yaacov Weingarten <[email-masked]>
Date: Sun, 8 Dec 2013 13:01:37 +0200

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*

---

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Mon, 9 Dec 2013 20:04:46 +0000

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" <[email-masked]>
Sent : 2013-12-08 20:01:55 ( +09:00 )
To : [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
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

---

From: Yaacov Weingarten <[email-masked]>
Date: Tue, 10 Dec 2013 09:04:11 +0200

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 <[email-masked]> wrote:

> 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" <[email-masked]>
> *Sent : *2013-12-08 20:01:55 ( +09:00 )
> *To : [email-masked] <
> [email-masked]>, [email-masked] <[email-masked]>
> *Cc : *
> *Subject : *Question regarding SD protection in draft-ietf-mpls-tp-psc-itu
>
>
> Hi,
>
> 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

-- 
Thanx and BR,
yaacov

---

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Thu, 26 Dec 2013 04:51:13 +0000

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" <[email-masked]>
Sent : 2013-12-10 16:04:17 ( +09:00 )
To : Ryoo, Jeong-dong <[email-masked]>
Cc : [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
Yaacov,

Best regards,

Jeong-dong

________________________________
From : "Yaacov Weingarten" <[email-masked]<mailto:[email-masked]>>
Sent : 2013-12-08 20:01:55 ( +09:00 )
To : [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc :
Subject : Question regarding SD protection in draft-ietf-mpls-tp-psc-itu

Hi,

--
Thanx and BR,
yaacov

--
Thanx and BR,
yaacov

---

From: Loa Andersson <[email-masked]>
Date: Thu, 26 Dec 2013 15:07:09 +0800

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:
> 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.
>
> ------------------------------------------------------------------------
> *Sent : *2013-12-10 16:04:17 ( +09:00 )
> *To : *Ryoo, Jeong-dong <[email-masked]>
> *Cc : [email-masked]
> <[email-masked]>, [email-masked] <[email-masked]>
> *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.
>
> 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).
>
> 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.
>
> 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
>
>
>     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" <[email-masked]
>     <mailto:[email-masked]>>
>     *To : [email-masked]
>     <mailto:[email-masked]>
>     <[email-masked]
>     <mailto:[email-masked]>>, [email-masked]
>     <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
>     *Cc : *
>     After reading through your draft on the extensions to PSC to support
>     SD situations, I have a question for clarification -
>     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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Fri, 27 Dec 2013 02:41:05 +0000

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" <[email-masked]>
Sent : 2013-12-26 16:07:15 ( +09:00 )
To : Ryoo, Jeong-dong <[email-masked]>, Yaacov Weingarten <[email-masked]>
Cc : [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject : Re: [mpls] Question regarding SD protection in draft-ietf-mpls-tp-psc-itu

Jeong-dong,

/Loa

On 2013-12-26 12:51, Ryoo, Jeong-dong wrote:
> *From : *"Yaacov Weingarten"
> *To : *Ryoo, Jeong-dong
> , [email-masked]
> On Mon, Dec 9, 2013 at 10:04 PM, Ryoo, Jeong-dong > > wrote:
>
> Yaacov,
>
> *From : *"Yaacov Weingarten" > >
> > >, [email-masked]

--

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 27 Dec 2013 14:25:37 +0100

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

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.

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

---

From: Loa Andersson <[email-masked]>
Date: Sun, 29 Dec 2013 18:04:27 +0800

Jeong-dong,

I got conflicting answers you and Huub. I don't immediately want to
change the text in the document, but rather understand if it needs to
be changed to give a context to resolve Yaacov's comments.

The point I was trying to make was that you and Yaacov stand on two
different mountains (network layering models) and can't agree if you
see the sun set or not. You say you can, but Yaaco don't agree, since
the sun disappeared behind the mountain you are standing on more than
an hour ago.

What I think happens is that you think about protection switching,
selector and bridge in the terms of the model you are used to.

When Yaacov hear that he thinks about them the way he is used to use
them from his model.

Neither model is "right or wrong" (both mountains are real) but the are
different.

What I tried to say was that when Yaacov thinks about as physical
objects, while you seem to use them as a class name, performing the
same function for any layer, but also implemented differently on
each layer.

I think this was what Huub agreed to, right?

Yaacov step of this train here if you don't agree!

So what I intended to to was to keep the class name (for every existing
bridge and selector, calling them just that) and zoom om on e.g. one
network layering instance of the class, talking about "mpls selector
function" and "mpls bridge function".

Please note that I'm not suggesting names or terminology, just trying
to figure out it if this is the why you don't seem to agree.

If we agree what the problem is then it is fairly easy to find the
text that needs to go into the document.

/Loa

On 2013-12-27 10:41, Ryoo, Jeong-dong wrote:
> 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".
> *From : *"Loa Andersson" <[email-masked]>
> *Sent : *2013-12-26 16:07:15 ( +09:00 )
> *To : *Ryoo, Jeong-dong <[email-masked]>, Yaacov Weingarten
> <[email-masked]>
> *Cc : [email-masked] <[email-masked]>,
> [email-masked]
> <[email-masked]>
> *Subject : *Re: [mpls] Question regarding SD protection in

--

---

From: Qin Wu <[email-masked]>
Date: Mon, 30 Dec 2013 03:48:20 +0000

Sorry to interrupt in.
I am a little bit surprised this draft has not any reference to ITU document.
I am wondering how much this draft is compliant with G.8031? Is there any tweak or optimization to G.831?
What is the concern of G.831 this draft is dealing with?
If anything is from G.831 or any other ITU document, I think it is fine, however G.831 or some other ITU documents are worth being referenced.

If this draft is focusing on addressing G.831, it is better to clarify this a little bit in this draft.

My feeling is this draft seems to introduce combination of 1+1 and 1:1 protection architecture when I read
“
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.

”,
I tend to agree Yaccov that SD protection is not agnostic to the method used for the detection.
Also I am interested to know how to position bridge and selector in the MPLS architecture?

Regards!
-Qin

From: mpls [mailto:[email-masked]] On Behalf Of Ryoo, Jeong-dong
Sent: Thursday, December 26, 2013 12:51 PM
To: Yaacov Weingarten
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Question regarding SD protection in draft-ietf-mpls-tp-psc-itu

Best regards,

Jeong-dong

Thank you,
yaacov

Best regards,

Jeong-dong

Hi,

--
Thanx and BR,
yaacov

--
Thanx and BR,
yaacov

---

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Mon, 30 Dec 2013 05:19:41 +0000

Qin,

This draft is based on RFC6378 for the protocol message format and the basic operational priciples, which are different from G.8031.
The intention of this draft is to make RFC6378 be aligned with G.8031 (or other ITU protection technologies) in the aspects of "network operation". In other words, it looks like G.8031 (or other ITU protection technologies) to the network operators, but the actual protocol operations and the bits on the wire are different.

I mentioned G.8031 in my previous email to Yaacov just for better explanation, and I don't think this document needs G.8031 as a reference.
But, if you find any part in this document that needs a reference to G.8031, please let us know.

You and Yaacov might be right on the sentence "SD protecton is not agnostic to the detection method".
But, as I said, my original intention and what we wanted to achieve in this document are that the protection specified in this document covers SD no matter what kind of SD detection methods shoud be used.
By the way, this draft does not have a word "agnostic".

Best regards,

Jeong-dong

________________________________
From : "Qin Wu" <[email-masked]>
Sent : 2013-12-30 12:48:27 ( +09:00 )
To : Ryoo, Jeong-dong <[email-masked]>, Yaacov Weingarten <[email-masked]>
Cc : [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject : RE: [mpls] Question regarding SD protection in draft-ietf-mpls-tp-psc-itu

Sorry to interrupt in.

”,

Regards!
-Qin

From:mpls [mailto:[email-masked]] On Behalf Of Ryoo, Jeong-dong
Sent: Thursday, December 26, 2013 12:51 PM
To: Yaacov Weingarten
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Question regarding SD protection in draft-ietf-mpls-tp-psc-itu

Best regards,

Jeong-dong

Thank you,
yaacov

Best regards,

Jeong-dong

Hi,

--
Thanx and BR,
yaacov

--
Thanx and BR,
yaacov

---

From: Qin Wu <[email-masked]>
Date: Mon, 30 Dec 2013 07:14:15 +0000

Hi Jeong-dong:
Thank for your clarification.

The title of your draft is “MPLS Transport Profile (MPLS-TP) Linear Protection in Support of ITU-T's Requirements”

It is obvious your draft is compliant with RFC6378.

However I am wondering what ITU-T’s requirements are? Are these requirements from ITU-T document G.8031 or some other ITU-T documents?

From this perspective, I think one ITU-T document describing these requirements needs to mentioned in this draft, e.g., in the introduction section?

For agnostic issue, I think this issue is applied to section 7.3, as you clarified earlier, the selector is not really bridge selector but optimized bridge selector.

I am wondering whether it is combination of permanent bridge and selector bridge (Two terms are defined in RFC6378).

If it is, my question is can we apply 1:1 protection architecture and 1+1 protection architecture to linear protection mechanism at the same time or

We should use these permanent bridge and selector bridge separately?

Please correct me if I am wrong or miss something.

Regards!
-Qin
From: Ryoo, Jeong-dong [mailto:[email-masked]]
Sent: Monday, December 30, 2013 1:20 PM
To: Qin Wu; Yaacov Weingarten
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls] Question regarding SD protection in draft-ietf-mpls-tp-psc-itu

Qin,

Best regards,

Jeong-dong

”,

Regards!
-Qin

Best regards,

Jeong-dong

Thank you,
yaacov

Best regards,

Jeong-dong

Hi,

--
Thanx and BR,
yaacov

--
Thanx and BR,
yaacov

---

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Mon, 30 Dec 2013 07:49:12 +0000

Qin,

The same arguement on the ITU-T's requirements has been raised at the previous conversations with WG chairs.
The arguement is valid, and the next version of this draft will clarify it.
Regarding the bridge, yes, your understanding is correct. It is a combination of those two bridges defined in RFC6378.
However, I am not sure if we need to introduce any new architecture, because G.8031 uses the broadcast bridge and does not define any other architecture than 1+1 or 1:1. According to G.8031, 1+1 is for permanent bridge and 1:1 is for non permanent bridge. I guess that we can think the same way. I will also try to find appropriate text and place to clarify this.

Best regards,

Jeong-dong

Sent : 2013-12-30 16:14:23 ( +09:00 )

Hi Jeong-dong:

Regards!
-Qin

Qin,

Best regards,

Jeong-dong

”,

Regards!
-Qin

Best regards,

Jeong-dong

Thank you,
yaacov

Best regards,

Jeong-dong

Hi,

--
Thanx and BR,
yaacov

--
Thanx and BR,
yaacov