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

From: Loa Andersson <[email-masked]>
Date: Mon, 20 Jan 2014 10:28:19 +0800

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 ([email-masked])
- 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: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Loa Andersson <[email-masked]>
Date: Mon, 27 Jan 2014 19:32:44 +0800

Working Group,

When this wglc were started we did not know of any IPR disclosures
against this document.

Now we have an IPR disclosure:

http://www.ietf.org/mail-archive/web/mpls/current/msg11469.html

I will also start an IPR poll on this document.

/Loa
mpls wg co-chair

--

---

From: Yaacov Weingarten <[email-masked]>
Date: Mon, 27 Jan 2014 22:11:59 +0200

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 <[email-masked]> wrote:

> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

-- 
Thanx and BR,
yaacov

*Still looking for new opportunity*

---

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Tue, 28 Jan 2014 02:17:20 +0000

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" <[email-masked]>
Sent : 2014-01-28 05:12:16 ( +09:00 )
To : Loa Andersson <[email-masked]>
Cc : [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
Working Group,

  mpls working group mailing list ([email-masked]<mailto:[email-masked]>)

/Loa

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

--
Thanx and BR,
yaacov

Still looking for new opportunity

---

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Tue, 28 Jan 2014 09:41:01 +0000

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

Hi all,

Thanx,
yaacov

/Loa

--
Thanx and BR,
yaacov

---

From: Loa Andersson <[email-masked]>
Date: Tue, 28 Jan 2014 21:57:51 +0800

Folks,

I've reviewed this document (actually fourth or fifth time) and I have
very few comments, I think Adrian covered  all mine in his review.

I had something that I thought were spelling errors, but turns out to
be differences between UK and US English. I'm pretty sure that the
RFC Editor will set that right (if it isn't already).

There is one thing that sometimes makes hard to parse the document,
the abbreviation WTR stands for "Wait to restore", the thing is that
WTR can be a state, a message or a timer (given that I understand it
correctly).  When I discussed this earlier the answer has been "Well
it is confusing, but that is how it is done!"

I think at places where it necessary e.g. WTR are qualified  with
state, message or timer. I found one place where want to add a
clarifying "state", "message" or "timer".

page 13 last line - s/WTR expires/WTR timer expires

page 20 3rd line from the - s/WTR expires/WTR timer expires

page 25 Note 4 s/WTR/WTR state

page 25 Note 6 s/WTR/WTR state

page 27 Note 11 s/WTR/WTR state

DNR may be a state or a message, for clarification

page 27 note 11 s/DNR./DNR state.

The same exercise maybe be done for EXER [command, message] (actually
I think that for EXER this is done correctly), but it might valuable
to check for all abbreviations that has double meaning.

I don't think it is necessary or even motivated to do more about
this, but it might be a good if readers of the document were aware of
this.

I think the document - modulo addressing comments in wglc - is ready
to go.

/Loa

--

---

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Wed, 29 Jan 2014 04:24:38 +0000

Loa, thanks for the comments.

Yes, we need to clarify state/message(/timer) for WTR and others.

One minor concern is that "WTR Expires" is used as the name of a local request in RFC 6378.
I am not sure if it would be ok to change it to "WTR Timer Expires" in this document.
More specifically, the proposal of the following two items needs the change of "WTR Expires" to "WTR timer expires" in the priority list
in page 19:
- page 13 last line - s/WTR expires/WTR timer expires (This item would disapprear once we take Adrian's proposal to change whole sentence.)
- page 20 3rd line from the - s/WTR expires/WTR timer expires

Best regards,

Jeong-dong

________________________________
From : "Loa Andersson" <[email-masked]>
Sent : 2014-01-28 22:58:10 ( +09:00 )
To : [email-masked] <[email-masked]>
Cc : [email-masked] <[email-masked]>, <[email-masked]>, [email-masked] <[email-masked]>, VIGOUREUX, MARTIN (MARTIN) <[email-masked]>
Subject : Re: working group last call draft-ietf-mpls-tp-psc-itu-01

Folks,

/Loa

--

---

From: Loa Andersson <[email-masked]>
Date: Wed, 29 Jan 2014 14:49:57 +0800

Jeong-dong,

I think we are in agreement. For "WTR Expires" I think you understand
my concern, do what you think is useful and necessary. Maybe there is
Adrian's comment on the page 13 last line could be used to clarify
page 20 3rd line also.

/Loa

On 2014-01-29 12:24, Ryoo, Jeong-dong wrote:
> More specifically, the proposal of the following two items needs the
> change of "WTR Expires" to "WTR timer expires" in the priority list
> in page 19:
> - page 13 last line - s/WTR expires/WTR timer expires (This item would
> disapprear once we take Adrian's proposal to change whole sentence.)
> ------------------------------------------------------------------------
> *From : *"Loa Andersson" <[email-masked]>
> *Sent : *2014-01-28 22:58:10 ( +09:00 )
> *To : [email-masked] <[email-masked]>
> *Cc : [email-masked] <[email-masked]>,
> <[email-masked]>, [email-masked]
> <[email-masked]>, VIGOUREUX, MARTIN (MARTIN)
> <[email-masked]>
> *Subject : *Re: working group last call draft-ietf-mpls-tp-psc-itu-01
>
> Folks,
>

--

---

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Wed, 29 Jan 2014 07:18:15 +0000

Loa, thanks.

Jeong-dong

________________________________
From : "Loa Andersson" <[email-masked]>
Sent : 2014-01-29 15:50:07 ( +09:00 )
To : Ryoo, Jeong-dong <[email-masked]>, [email-masked] <[email-masked]>
Cc : [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, VIGOUREUX, MARTIN (MARTIN) <[email-masked]>
Subject : Re: working group last call draft-ietf-mpls-tp-psc-itu-01

Jeong-dong,

/Loa

On 2014-01-29 12:24, Ryoo, Jeong-dong wrote:
> *From : *"Loa Andersson"
> *To : [email-masked]
> *Cc : [email-masked] ,
> , [email-masked]
> , VIGOUREUX, MARTIN (MARTIN)
>

--

---

From: Yaacov Weingarten <[email-masked]>
Date: Wed, 29 Jan 2014 14:47:03 +0200

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.

Thanx,
yaacov

On Tue, Jan 28, 2014 at 11:41 AM, Ryoo, Jeong-dong <[email-masked]> wrote:

> #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.

> #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?

#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.

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

-- 
Thanx and BR,
yaacov