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

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

Yaacov,

Thank you so much for your review.
Before I go through your comments, which may take some time,
I would like to respond to the basic question regarding the version number in this email.

You have exactly the same thought on the version number as I have.
Also, changing the version number can eliminate all the hassles with the Capabilities TLVs in Section 9.

In the early stage of this work, there was an argument to treat each of those five capabilities individually,
so that any changes in RFC6378 can be seen as opional features,
This may sound ok in general,
but considering the nature of the protection switching, it does not make any sense.
Even though the idea of treating them as individuals is reflected in current draft.
I still believe that the change of version number is a far-better solution.

If somebody wants any one of priority modification capability and non-revertive behavior capability,
a totally different protocol implementation (priority logic and state machine) should be devised.
There is no way you can change the Capabilities set unless you have a different set of priority evaluation and state machine,
i.e., a different PSC process.
In the case an operator doesn't want to use any of SD, MS-W and EXER capabilities,
what the operator can simply do is just disabling the input trigger.
I don't see any value of introducing the Capabilities TLV, which just complicates the protocol operation.

If we decide to change the version number and eliminate Capabilities TLV,
there may be some editing job. But, it is well worth the change.

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