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

[Yaacov Weingarten <[e-mail]>]

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


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

>  #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]> 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*
>



-- 
Thanx and BR,
yaacov

*Still looking for new opportunity*