Re: Review of draft-ietf-mpls-residence-time-12
Stewart Bryant <stewart.bryant@gmail.com> Wed, 18 January 2017 18:45 UTC
Return-Path: <stewart.bryant@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD1F12944A; Wed, 18 Jan 2017 10:45:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYKPStZSoiKy; Wed, 18 Jan 2017 10:45:53 -0800 (PST)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 297091293E3; Wed, 18 Jan 2017 10:45:53 -0800 (PST)
Received: by mail-wm0-x232.google.com with SMTP id c85so256863546wmi.1; Wed, 18 Jan 2017 10:45:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=1286Dj1saa8gTSeljDaH3CxfVQN6r+hTtSbWMR+x4ZA=; b=pZcMWEPyMpVP+INNg0Ljvs/0xvvnKPz6CYuPodpbyAbuUkP3rCkPjjpqxADi3I70g8 ugH84yDa/jjfquiorM7dspVFH0oy3m6YzYGERO4LTSIs83KpP8ZFukS3torHLx/vWZu2 XeItd441+L1KzjklV86fgMxMz1BdPqalk/9YNv18aqsbFo+VCLKuezwHCnwtCnp0PYsX Rwp8LhH87VsKlLAHruR5oaOeeGkmIvoMn7egBucZ6ZEKPXhXIxwPw1vEJw+SG+cDp9X+ jU5nbzFs9gdVZo9u1Rd9GtrEC4iauHpmWIOat545HiXeBk+KpqxjKwBghSwO57TEhdB+ yDnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=1286Dj1saa8gTSeljDaH3CxfVQN6r+hTtSbWMR+x4ZA=; b=sITl+btqqturg4nVetLAQIMIF3UTo0umC0knrWvRvuJFaVIqpI4RHIGCWwHehd7I3S +QkzRoQWnf5ozktCQ1w8laT3hi+7+kEC0JtkP+z8FhkRc+hmirG0SyJf+tMUAuxGUZjP gib32p6QrmVrQffIsegPtLjTHCb0dNmJs6KkB5Mp/hFzLPih7wRb47WmIeXSwlDrWS8h wj+oRHejcTOISG/Cm8lcA/hL1Uwx1yMhxBdv1Oh3Tyi2YaOvnRfGzKXEnGvQ2lMzoiQu 9R9quoROhNgdPK7z4v++ciQpd/NvLMkwrE6v1L4LcwRMIpiF0JgmpqzAzPWYkEuDepMy tdrQ==
X-Gm-Message-State: AIkVDXKjkvr//YlNvOpYuQRePtjayok8e9vHWiDI70SfY82a2Oeyloe2xa6vx2MUpEkwzQ==
X-Received: by 10.28.57.193 with SMTP id g184mr3955269wma.122.1484765151301; Wed, 18 Jan 2017 10:45:51 -0800 (PST)
Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id e14sm47172382wmd.14.2017.01.18.10.45.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Jan 2017 10:45:50 -0800 (PST)
Subject: Re: Review of draft-ietf-mpls-residence-time-12
To: Robert Sparks <rjsparks@nostrum.com>, Greg Mirsky <gregimirsky@gmail.com>
References: <148414970343.8167.4538946698521330202.idtracker@ietfa.amsl.com> <CA+RyBmU9W5QP4EjbPezoCpdLHv1RJCrzJvxQmeTnAvjO_6vbJA@mail.gmail.com> <CA+RyBmVrvyiwDp2kV3VLiQtqOaL=MaVjZugGbvgWnp6y3dwP3Q@mail.gmail.com> <95d41b52-5c85-869f-2139-6713816e9637@nostrum.com>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <13a04df0-49b4-89ca-ca88-dc8c417cbef5@gmail.com>
Date: Wed, 18 Jan 2017 18:45:44 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <95d41b52-5c85-869f-2139-6713816e9637@nostrum.com>
Content-Type: multipart/alternative; boundary="------------7B89250D800A8519E02998A3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/e5bcbdnOQFXO6oEiFOT_CwjF8m4>
Cc: "mpls@ietf.org" <mpls@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, draft-ietf-mpls-residence-time.all@ietf.org, "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jan 2017 18:45:55 -0000
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@gmail.com >> <mailto:gregimirsky@gmail.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@nostrum.com <mailto:rjsparks@nostrum.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]. >> >> >> >> >> >
- Review of draft-ietf-mpls-residence-time-12 Robert Sparks
- Re: Review of draft-ietf-mpls-residence-time-12 Greg Mirsky
- Re: Review of draft-ietf-mpls-residence-time-12 Greg Mirsky
- Re: Review of draft-ietf-mpls-residence-time-12 Juergen Schoenwaelder
- Re: Review of draft-ietf-mpls-residence-time-12 Greg Mirsky
- Re: Review of draft-ietf-mpls-residence-time-12 Greg Mirsky
- Re: Review of draft-ietf-mpls-residence-time-12 Greg Mirsky
- Re: Review of draft-ietf-mpls-residence-time-12 Greg Mirsky
- Re: Review of draft-ietf-mpls-residence-time-12 Robert Sparks
- Re: Review of draft-ietf-mpls-residence-time-12 Stewart Bryant
- Re: Review of draft-ietf-mpls-residence-time-12 Greg Mirsky
- Re: [mpls] Review of draft-ietf-mpls-residence-ti… Acee Lindem (acee)
- Re: [mpls] Review of draft-ietf-mpls-residence-ti… Greg Mirsky
- RE: [mpls] Review of draft-ietf-mpls-residence-ti… Les Ginsberg (ginsberg)
- Re: [mpls] Review of draft-ietf-mpls-residence-ti… Greg Mirsky
- RE: [mpls] Review of draft-ietf-mpls-residence-ti… Adrian Farrel
- RE: [mpls] Review of draft-ietf-mpls-residence-ti… Alexander Vainshtein
- RE: [mpls] Review of draft-ietf-mpls-residence-ti… Mach Chen
- Re: [mpls] Review of draft-ietf-mpls-residence-ti… Stewart Bryant
- Re: [mpls] Review of draft-ietf-mpls-residence-ti… Stewart Bryant
- Re: [mpls] Review of draft-ietf-mpls-residence-ti… Stewart Bryant