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

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

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" <[e-mail]>
Sent : 2013-12-29 19:04:38 ( +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,

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 : *[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]

--


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