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

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Thu, 2 Jan 2014 01:39:33 +0000

Loa, thanks for the email.

I got the point now.
As you mentioned in the last part of your email, we'd better find the text.
Do you have any text to propose?

Best regards,

Jeong-dong

________________________________
From : "Loa Andersson" <[email-masked]>
Sent : 2013-12-29 19:04:38 ( +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,

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:
> 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"
> *Sent : *2013-12-26 16:07:15 ( +09:00 )
> *To : *Ryoo, Jeong-dong , Yaacov Weingarten
>
> *Cc : [email-masked] ,
> [email-masked]
>
> *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 : [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 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 : [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/
> >
> >
> >
> >
> > --
> > 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

--

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

---

From: Loa Andersson <[email-masked]>
Date: Thu, 02 Jan 2014 18:24:17 +0800

Jeong-dong,

I could try, but that would be a novice stumbling around.

I'd like Yaaco and Huub to take at spin at this first, I believe
that they have a better chance to zoom in on what is crucial from
the beginning.

/Loa

On 2014-01-02 09:39, Ryoo, Jeong-dong wrote:
> *From : *"Loa Andersson" <[email-masked]>
> *Sent : *2013-12-29 19:04:38 ( +09:00 )
> *To : *Ryoo, Jeong-dong <[email-masked]>, Yaacov Weingarten
> <[email-masked]>
> *Cc : [email-masked] <[email-masked]>,
> <[email-masked]>

--

---

From: 류정동 <[email-masked]>
Date: Wed, 15 Jan 2014 01:30:23 +0000

Dear all,

This email is to summarize the issue with the SD protection and to propose a resolution.

The issue with the SD protection has been raised by Yaacov a month ago.
His main argument was that current description on SD protection described in Section 7.3 seemed to indicate the behavior is dependent upon the SD detection method.

Even after a few email exchanges to clarify the operation of SD protection, especially the operation of the bridge used in SD protection, I was not able to recognize the main source of the issue until some of people, Yaacov, Huub, Loa and myself, discussed in private off the WG list (sorry for being off the WG list).

Finally, we agreed on the following text to replace the fourth paragraph, starting with "If the detection of a SD depends on the presence of user data packets ..." in Section 7.3:
------
Protection switching against SD is always provided by a selector bridge duplicating user data traffic and feeding it to both working and protection paths under SD condition. In revertive mode, when the WTR timer expires the packet duplication SHALL be stopped and the user data traffic SHALL be transported on the working path only. In non-revertive mode, when SD is cleared the packet duplication SHALL be stopped and the user data traffic SHALL be transported on the protection path only.
------

However, in the discussion about the text with Eric Gray, he further made the comments on the operation of the bridge, and I am now proposing the following text:
------
Protection switching against SD is always provided by a selector bridge duplicating user data traffic and feeding it to both the working path and the protection path under SD condition. When a local or remote SD occurs on either the working path or the protection path, the LER SHALL duplicate user data traffic and SHALL feed to both the working path and the protection path. The packet duplication SHALL continue as long as any SD condition exists in the protected domain, and SHALL stop when there is no SD condition. Additionally, the packet duplication SHALL continue in the WTR state in revertive mode. In non-revertive mode, the packet duplication SHALL stop when there is no SD condition.
------
If you have any comments on this proposal, please let us know.
Otherwise, I will put the proposed text in the revision of the draft.

Best regards,

________________________________
From : "Loa Andersson" <[email-masked]>
Sent : 2014-01-02 19:24:28 ( +09:00 )
To : 류정동 <[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

--