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

[Yaacov Weingarten <[e-mail]>]

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]> 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])
> - 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]
> Senior MPLS Expert                          [e-mail]
> Huawei Technologies (consultant)     phone: [phone]
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>



-- 
Thanx and BR,
yaacov

*Still looking for new opportunity*