|
Thanks Greg for feedback, please see my reply inline below. 发件人: Greg Mirsky [mailto:gregimirsky@xxxxxxxxx]
Hi Qin, thank you for your expedient and careful consideration of my comments. I'm glad that we've already in agreement on so many. I've added notes on those that, in my view, need some more discussions. Please find them in-line
tagged GIM>>. Regards, Greg On Sun, Oct 22, 2017 at 8:31 PM, Qin Wu <bill.wu@xxxxxxxxxx> wrote: Thanks Greg for providing additional input to help make the model more extensible and
reusable. Please see my reply inline below. -Qin 发件人: Greg Mirsky [mailto:gregimirsky@xxxxxxxxx]
Dear All, please kindly consider my comments on draft-ietf-lime-yang-connectionless-oam
presented below:
[Qin]: I believe RFC7276 and G.800 share the similar paradigms but capture the different aspect of the key difference between CO and CL, I would suggest to harmonize
the different aspect of these key differences together and add another reference to G.800 as follows:
NEW TEXT:
“
In connection-oriented technologies, a connection is established prior to the transmission of data. After connection is established, no additional control information such as signaling or operations and maintenance information is required to transmit the data. In connectionless technologies, data is typically sent between end points without prior arrangement, but control information is required to identify destination [G.800][RFC7276].
” GIM>> If we consider, for example, MPLS-TP domain and L3VPN over IP/MPLS domain, then the configuration aspect, in my opinion, becomes less distinct while the forwarding paradigm is invariant, remains the same. [Qin]: Thanks.
GIM>> I think that if we concentrate on OAM on particular network layer, then reference to multi-layer character of modern networks is unnecessary and somewhat artificial. As for test points in the same layer, then traceroute
suppose to return ordered list of Test Points between the Sender and Receiver. Because there could be ECMP sub-domains along the path, model should be able to differentiate with some entropy key. OAM visibility into other administrative domains obviously brings
security consideration issues and, I'd expect, be carefully controlled and try to hide identity of the domain. Hence, I think that 'position' is hardly usable parameter. [Qin]: Thanks for your comments on this, yes recording test point list in the same layer is not good use case, harmonizing with your comments and
Gen-art review comments, we have removed same layer and rewrite this section based on Gen-art reviewer’s input and suggestions. Thanks again.
GIM>> Packet loss and, as result, loss ratio in modern networks is very low. I suggest changing loss-ratio type from uint8 to new type percentage, defined as: typedef percentage { type decimal64 { fraction-digits 5; } description "Percentage"; } [Qin]: Good proposal, accepted. GIM>> I think that counter overrun case indicator requires separate parameter. Using
4294967295 may produce negative false when running in forever mode. [Qin]: Note that counter is unsigned integer, it will not produce negative false, in my understanding. I doubt we should add such complexity to
data model by introducing another parameter, we can leave this to implementation details.
|