Re: [mpls] working group last call draft-ietf-mpls-tp-psc-itu-01

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

Yaacov, again thanks for your comments.
Due to the luar New Year break, I was a little behind.
Please see my responses starting with [JR]
Jeong-dong


________________________________
From : "Yaacov Weingarten" <[e-mail]>
Sent : 2014-01-29 21:47:09 ( +09:00 )
To : Ryoo, Jeong-dong <[e-mail]>
Cc : Loa Andersson <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject : Re: [mpls] working group last call draft-ietf-mpls-tp-psc-itu-01

Jeong-dong, hi

Thank you for your detailed reply to my comments - some counter comments appear below prefixed by "yw>>".

In addition, I would like to add the following comment - regarding the notes on the State tables and especially note #1. In this note you state"Re-evaluate to determine final state as if the LER is in the Normal state." This needs more clarification, IMO, since this could be read as stating that if there is no currently active trigger then remain in the current state!
Therefore I think that you should explicitly state "Re-evaluate to determine final state as if the LER is in the Normal state. If there are no active triggers, the LER enters Normal State." (On the assumption that this is the intention!) Similar corrections should be considered for notes 2,3,5.
[JR] Yes, I agree with you. That was the intention, but current description is not complete. It should be corrected in next version as you suggested.


Thanx,
yaacov


On Tue, Jan 28, 2014 at 11:41 AM, Ryoo, Jeong-dong <[e-mail]<mailto:[e-mail]>> wrote:
Yaacov,
Again, thanks for the comments.
I really appreciate your help on this document.
The followings are my responses to your comments:
========
#1. Yes, you described the correct behavior of MS-W. As you indicated, MS and EXER are supposed to be ignored while MS-W is in effect.
yw>> I think that if this is the case that it be explicitly stated in the text.
[JR] The next version of draft should have this.

#2. This document does not modify the operation of the selector described in RFC6378. According to RFC6378, the selector selects the traffic from only one of the paths no matter if the protection architecture is 1:1 or 1+1. If you think it is appropriate to make this clear, then we can add something like:
“This document does not modify the operation of the selector at the sink LER described in RFC 6378. The selector at the sink LER chooses either the working or protection path from which to receive the normal traffic in both 1:1 and 1+1 architectures. The position of the selector, i.e., which path to receive the traffic, is determined by the PSC protocol in bidirectional switching or by the local input in unidirectional switching.”
As a matter of fact, according to RFC 4427 (and all the ITU-T protection documents), a selector refers to the entity at the sink node only. For the source node, a bridge is used to choose which path (one of two paths in 1:1, or both paths in 1+1) to transmit the traffic. Therefore, “the selector in the sink LER” is redundant and should have been replaced with just “the selector”. But, the descriptions of the selector and bridge in RFC 6378 are somewhat different. In RFC 6378, the selector is used for both transmitting and receiving the traffic, while the bridge is used for transmitting only. The descriptions in RFC 6378 are not quite aligned with RFC 4427 (and other ITU-T docs).
#3. Again, this is due to the different understanding on the selector. If you stick to the terminology defined in RFC 4427 and ITU-T, then you may not have the issue with current sentences. In the meantime, as I did in #2, I can add “in the sink LER” after every “the selector”. In other words, "the path from which the selector does not select the user data traffic" can be replaced with “"the path from which the selector at the sink LER does not select the user data traffic"
yw>> I did not have a problem with the "selector" terminology my problem was with the description of the SD protection behavior in section 7.3. You state there that the protection is provided by "a selector bridge duplicating user data traffic"  then later "the LER SHALL duplicate user data traffic and SHALL feed to both..." However, there is no description of what the selector at the receiving end is doing.
Therefore, my conclusion is that the receiving end selects incoming data traffic form either the working or protection path on a per-packet basis, i.e. packet#1-5 may be selected from the working path, while packet#6-7 may be selected from the protection path, and packet#8-10 from working, and so on. Is this correct? And if it is not correct could you please provide text that precludes this behavior.
The next step to my question is then - if this description is correct then there is no "standby" path since the selector (at the sink LER) may switch intermittently (based on the quality of the transmission at that point in time) between the two paths. So can you please clarify the definition?
[JR] The selector is the same as the one in RFC6378.
The position of the selector is determined by the PSC protocol in bidirectional switching.
When SD-W is detected in the Normal state, the local LER changes its selector position to the protection path, sends the traffic to both paths, and transmits SD-W message.
When the SD-W message arrives at the remote LER, the remote LER changes it selector position to the protection path, and sends the traffic to both paths.
Now, the behavior will continue until any new higher request occurs. I.e., no further change of the selector position until any new higher priority request comes in.

At the time SD-W occurred at the local LER, the standby path was the protection path as the traffic was selected from the working path in the Normal state.
After two LERs act on SD-W, the working path becomes the standby path as the traffic is selected from the protection path.

The operation you described with packet numbers is not the behavior in the document.
We actually wanted to avoid such a situation (traffic flapping) by using this bridge with packet duplication.
But, again the selector is the same as the one in RFC6378 and other ITU-T Recs.



#4. The action on which path the LER should send the traffic is the same, but the sink node should determine from which path the traffic should be received. In order to determine the position of the selector *at the sink node*, we need to resolve the conflict.
yw>> The problem with this is that it is only the receiving LER that can determine and generate the SD since the judgement of a degrade in the recption not in the transmission, isn't this true? And again this is related to the incomplete description of the behavior of the sink LER in the protection from SD behavior.
#5. I totally agree with you. Please see my earlier email on version number.
#6. Your impression on the linear protection is the same as mine. This section needs to be rewritten. In my opinion, we should not use the term, the life of PSC session. As I mentioned in my email responding to the AD Review comments, Section 9 should be rewritten (or removed if we can change the version number). In my opinion, your suggestion in #5 is also better than as is now.
#7. I totally agree with you on changing the version number.
#8. We followed the same grouping as in RFC 6378. In Section 4.3.3.2 of RFC 6378, the second paragraph says:
The protection domain will exit the Unavailable state and revert to
the Normal state when either the operator clears the Lockout command
or the protection path recovers from the signal fail or degraded
situation.
Based upon this, we put SD-P in Unavailable state. As you know, the name of the state does not affect the action taken by the PSC process. What affects the action is the extended state, which shows the request and the source of the request. If you want to suggest any other appropriate state, I am ready to hear.
===========
Best regards,

Jeong-dong



________________________________
From : "Yaacov Weingarten" <[e-mail]<mailto:[e-mail]>>
Sent : 2014-01-28 05:12:16 ( +09:00 )
To : Loa Andersson <[e-mail]<mailto:[e-mail]>>
Cc : [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>
Subject : Re: [mpls] working group last call draft-ietf-mpls-tp-psc-itu-01

Hi all,

I have read through the latest version of this draft and have a number of comments and questions regarding this document. While, in general, I feel that the extensions to the behavior of RFC6378 are appropriate, I find that this document is still in need of refinement in its language and clarity of the functionality. While some of the additional functionality is described, there are different cases of the functionality that is either not described or is rather confusing.

One basic question is - Considering that this draft is proposing changes to the basic operation of the PSC protocol, Local Request Logic, and the PSC Control Logic, I would have thought that the PSC Version number should change! Why then, is there no mention of changing the version to allow networks that support the functionality described in RFC6378 to continue to operate?

Regarding the functionality proposed in the draft, I have the following questions and comments -

  1.  (for clarification) Regarding the functionality of MS-W, what is the functionality if the data-traffic is currently on the working path? Since the purpose of the command is to move the traffic to the working path, shouldn't it be ignored? However, according to the State Transition Table in section 11.1 - if the MS-W is received by a LER in Normal State it transfers to Switching Administrative State! The main effect seems to be to cause the LER to ignore incoming MS and EXER requests (that are not ignored in Normal State).
  2.  Regarding the SD functionality - after a previous discussion on the mailing list the functionality when protecting for SD situations (described in Section 7.3) was changed to essentially switch over to the LER transmitting the packets on both the working and protection paths (essentially 1+1 transmission). However, there is very little discussion of how the receiving LER is supposed to select the incoming packets while avoiding duplication of data. Could please elaborate on this?
  3.  Regarding the SD functionality - as mentioned in the previous point, when protecting for SD, the transmitting LER duplicates the packets on both W & P and the receiving LER, presumably, reads the data from either path, and may choose differently for different packets. However, later in section 7.4 (and again in section 10.2) you introduce a new concept of "standby path" as "the path from which the selector does not select the user data traffic" in regard to determining the priority of "conflicting" SD-W and SD-P triggers. Can you clarify which of the two paths that are both carrying user data is the standby path?
  4.  Further regarding the point of "conflicting" SD triggers - since the protection functionality of SD is to duplicate the data on both W & P - why is this considered a conflict, since the action for both will be identical - continue transmitting on both W & P. Some more clarification would help.
  5.  Regarding the APS mode and sub-capabilities - You describe in section 9.1 how an LER can declare itself to support only some of the capabilities introduced in the draft, and then describe the APS "mode" (Section 9.2.2) as declaration of support for all of the capabilities, i.e. Flags = 0xF8000000. From this point on (in particular section 11), you describe the functionality for LER that declare Flags= either 0x0, or 0xF8000000, however, there is no explanation for paths that declare some other value of Flags (for example, 0x8000000 - supporting only the EXER functionality). Is there a reason for this? Are we assuming that all paths will either support PSC or APS modes only? If so, why not just have two values for Flags rather than this extensible bit map value?
  6.  Regarding "PSC sessions" - In section 9.3 you introduce a new concept of PSC session, without any definition of when this session begins or ends. Could you elaborate on what is meant by the "life of a PSC session"? Until now, I was under the impression that linear protection started with the creation of the protection domain and continued until the paths were torn down. Is this incorrect?
  7.  There is a statement in the second paragraph of section 9.3 that states "RFC6378 does not define how to handle an unrecognized TLV." Actually, what RFC6378 defines is "there are no TLV units defined for the basic PSC operation" and therefore the TLVs are ignored. Another reason, IMO, to change the version number of the protocol in this draft.
  8.  It is unclear to me - why when receiving a SD-P indication in Normal why you consider this to be "Unavaiable" since the action taken for an SD situation is to possibly transmit on both W & P.

I plan on submitting some editorial comments in a future post, but would like to get some clarification on these points before the draft advances to acceptance.

Thanx,
yaacov


On Mon, Jan 20, 2014 at 4:28 AM, Loa Andersson <[e-mail]<mailto:[e-mail]>> wrote:
Working Group,

This is to start a two week working group last call on
draft-ietf-mpls-tp-psc-itu.

Please find the document at:
https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-psc-itu/

The document editors has also supplied a "diff-list" between
version -00 and -01 at:
http://www.ietf.org/mail-archive/web/mpls/current/msg11338.html

ITU-T SG15 has advised us that this document is a necessary reference
for documents that is planned to go into the ITU-T approval process
from the SG15 meeting end of March / beginning of April. Editors,
authors and chairs has put in quite an effort to make this document
ready. The schedule is very tight.

We are now doing several review steps in parallel

- the normal working group last call, please send your comments to the
  mpls working group mailing list ([e-mail]<mailto:[e-mail]>)
- the working group chairs reviewed this document as part of the
  mpls-rt review, normally we do a wg chair review before starting the
  wglc, this review will now take place in parallel
- after the wglc and publication request there is an AD evaluation,
  this will now also take place in parallel with the wglc

The editors and authors are advised to try to resolve as many of the
comments as possible (on the mailing list) as they come in, but not to
post the new version of the draft until the wglc is closed and the
comments are resolved.

This working group last call ends February 3rd.

/Loa
for the MPLS WG co-chairs
--


Loa Andersson                        email: [e-mail]<mailto:[e-mail]>
Senior MPLS Expert                          [e-mail]<mailto:[e-mail]>
Huawei Technologies (consultant)     phone: [phone]<tel:%2B46%20739%2081%2021%2064>
_______________________________________________
mpls mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mpls



--
Thanx and BR,
yaacov

Still looking for new opportunity



--
Thanx and BR,
yaacov

Still looking for new opportunity