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

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

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.
#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"
#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.
#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]>
Sent : 2014-01-28 05:12:16 ( +09:00 )
To : Loa Andersson <[e-mail]>
Cc : [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

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