Re: [Teas] Review on draft-ietf-teas-yang-te-21

[Igor Bryskin <[e-mail]>]

Hi Haomian,

Please, see in-line.

Igor


From: Teas [mailto:[e-mail]] On Behalf Of Zhenghaomian (Zhenghaomian, Optical Technology Research Dept)
Sent: Wednesday, April 10, 2019 6:13 AM
To: [e-mail]
Cc: '[e-mail]'
Subject: [Teas] Review on draft-ietf-teas-yang-te-21

Hi, Tarek, Authors,

I have reviewed the latest version of draft-ietf-teas-yang-te (-21) with following considerations, please take a look and decide whether to address in future work.


1.      Status Consideration: Currently we are having two parameters describing the status: operational-state and provisioning-state. By using the current states we can specify whether an LSP has been successfully planned or established, but cannot specify whether an LSP has been successfully revised or tear down. Refer more details to https://mailarchive.ietf.org/arch/msg/teas/iKL2TYV9M3B5z825EzCZnMMnFWg; BTW, I don¡¯t quite understand why we change the ¡®administrative-state¡¯ into ¡®operational-state¡¯ but still keep the description as ¡®TE tunnel administrative state¡¯ in page 72. And the description on P68 about provisioning-state is also misleading.



IB>> provisioning state is under client control and allows the client to control when a (possibly pre-provisioned) tunnel should be actually (de-)provisioned in the data plane. On the contrary, operational-state is a read-only parameter and allows for the server to indicate in which state the tunnel actually is. Torn down LSP (successfully or unsuccessfully) is removed from the LSP container. If there was a problem with the deletion, It is expected that a record of the problem will appear in the tunnel¡¯s error container.  This is how the client can learn whether or not there was a problem with LSP deletion or modification


2.      Renaming ¡®tp-¡¯ with ¡®ttp¡¯ for some cases: Now we are having te-tp-id to describe the LTP information, and having src-tp-id, dst-tp-id describing the TTP information. The abbreviation ¡®tp-¡¯ is confusing. The proposal is to keep ¡®tp-¡¯ stand for LTP and use ¡¯ttp-¡¯ to indicating TTP, i.e., rename the ¡®src-tp-id¡¯ to ¡®src-ttp-id¡¯ and ¡®dst-tp-id¡¯ to ¡®dst-ttp-id¡¯.
IB>> Totally agree. We have discussed this and will provide the change in the next revision



3.      About WTR: currently we are having two different WTRs both referencing RFC4427. The ¡®wait-to-revert¡¯ is used for protection, while the ¡®wait-to-revert¡¯ and the ¡®wait-to-restore¡¯ are used for restoration. However in RFC 4427, there is only definition for wait-to-restore as a part of protection (the definition for wait-to-restore is also consistent with ITU-T G.808.1), therefore it is suggested to use ¡®wait-to-restore¡¯ rather than ¡®wait-to-revert¡¯ under protection. Moreover, it is not clear why there are two different WTR for restoration and how they are used in different ways, shall we combine them into one?

IB>> Wait-to-restore in the context of protection is confusing because it has nothing to do with the restoration and everything to do with the reversion of traffic onto working LSP.
We need two timers for the restoration ¨C one to wait before the restoration procedures to be started, another one for reversion procedures to be started. Note that the first timer is necessary because in case of restoration the fault localization is important (to replace the LSP away from the broken link). Fault localization may take a while, hence the timer. In case of protection the fault localization is not important (protection LSP is supposed to be sufficiently disjoint from the working LSP). Hence protection procedures could be started right away and the timer is not needed



Thank you.

Best wishes,
Haomian

Network Research Department
Fixed Network Business Unit
Huawei Technologies Co., LTD.
Xiliu Beipo Village, Huanhu Road,
Songshan Lake, Dongguan, 523808 P.R.China
Tel: [phone]

________________________________
»ªÎª¼¼ÊõÓÐÏÞ¹«Ë¾ Huawei Technologies Co., Ltd.
[cid:image001.png@01D4EF7F.208F3C10]