|
Re: Review of draft-ietf-mpls-residence-time-12
2017-01-18 12:46:24
We need to be clear that you only need to be consistent within a node.
There is no requirement for any two nodes along the path use the same
bit in the packet as an epoch, nor do the input and output need to
physically use the same bit in the packet as the epoch provided they
know and account for the wire delay that corresponds to those bits. So
long as we accurately measure the local variable delay that is all that
is required.
- Stewart
On 18/01/2017 18:34, Robert Sparks wrote:
The changes all look good.
I still think you should say something in the document about what "the
time of packet arrival" and "transmission" means, and call out the
point you made about being careful to not introduce apparent jitter by
not making those measurements consistently. (The definitions you point
to in your earlier mail from G.8013 don't really help - they just say
"time of packet arrival". Again, the first and last bit are likely to
be several nanoseconds apart so I think it matters. Perhaps you're
saying it doesn't matter as long as each node is consistent (there
will be error in the residence time measurement, but it will be
constant at each node, so the sum of errors will be constant, and the
clocks will be ok?)
Please look at the new first paragraph of section 2 - there's a mix of
"as case" and "in case" that should be made consistent. I suspect it
would be easiest to simply say "referred to as using a one-step clock"
and "referred to as using a two-step clock" or similar.
RjS
On 1/18/17 12:03 PM, Greg Mirsky wrote:
Hi Robert,
Sasha Vainshtein came with elegant idea to address disconnection
between discussion of one-step and two-step modes that you've pointed
out. We've moved Section 7 as sub-section into Section 2 now.
Attached are updated diff and the proposed new version -13.
Regards,
Greg
On Wed, Jan 18, 2017 at 8:13 AM, Greg Mirsky <gregimirsky(_at_)gmail(_dot_)com
<mailto:gregimirsky(_at_)gmail(_dot_)com>> wrote:
Hi Robert,
once again, thank you for your thorough review and the most
detailed comments. I've prepared updated version and would
greatly appreciate if you review the changes and let us know
whether your comments been addressed. Attached are diff and the
new version.
Regards,
Greg
On Wed, Jan 11, 2017 at 7:48 AM, Robert Sparks
<rjsparks(_at_)nostrum(_dot_)com <mailto:rjsparks(_at_)nostrum(_dot_)com>>
wrote:
Reviewer: Robert Sparks
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The
General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>>.
Document: draft-ietf-mpls-residence-time-12
Reviewer: Robert Sparks
Review Date: 2017-01-10
IETF LC End Date: 2017-01-17
IESG Telechat date: 2017-02-02
Summary: Ready (with nits) for publication as a Proposed Standard
I have two primary comments. I expect both are rooted in the
authors
and working group knowing what the document means instead of
seeing
what
it says or doesn't say:
1) The document is loose with its use of 'packet', and where TTLs
appear when
they are discussed. It might be helpful to rephrase the text that
speaks
of RTM packets in terms of RTM messages that are encoded as G-ACh
messages and
not refer to packets unless you mean the whole encapsulated
packet
with MPLS
header, ACH, and G-ACh message.
2) Since this new mechanic speaks in terms of fractional
nanoseconds,
some
discussion of what trigger-point you intend people to use for
taking
the
precise time of a packet's arrival or departure seems
warranted. (The
first and
last bit of the whole encapsulated packet above are going to
appear at
the
physical layer many nanoseconds apart at OC192 speeds if I've
done the
math
right). It may be obvious to the folks discussing this, but
it's not
obvious
from the document. If it's _not_ obvious and variation in
technique
is
expected, then some discussion about issues that might arise from
different
implementation choices would be welcome.
The rest of these are editorial nits:
It would help to pull an overview description of the difference
between
one-step and two-step much earlier in the document. I suggest
in the
overview
in section 2. Otherwise, the reader really has to jump
forward and
read section
7 before section 3's 5th bullet makes any sense.
In section 3, "IANA will be asked" should be made active. Say
"This
document
asks IANA to" and point to the IANA consideration section. Apply
similar
treatment to the other places where you talk about future IANA
actions.
There are several places where there are missing words (typically
articles or
prepositions). You're less likely to end up with
misinterpretations
during the
RFC Editor phase if you provide them before the document gets
that far
in the
process. The spots I found most disruptive were these (this
is not
intended to
be exhaustive):
Section 3: "set 1 according" -> "set to 1 according"
Section 3: "the Table 19 [IEEE..." -> "Table 19 of [IEEE..."
Section 4.2: "Detailed discussion of ... modes in Section 7."
-> "Detailed discussion of ... modes
appears
in Section 7."
Section 10: "most of" -> "most of all"
In Setion 3.1 at "identity of the source port", please point
into the
document
that defines this identity and its representation. I suspect
this is a
pointer
into a specific section in IEEE.1588.2008].
|
|