Re: [mpls] Mirja Kühlewind's No Objection on draft-ietf-mpls-residence-time-14: (with COMMENT)
Greg Mirsky <gregimirsky@gmail.com> Fri, 03 March 2017 02:47 UTC
Return-Path: <gregimirsky@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C7B12949E; Thu, 2 Mar 2017 18:47:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 73KKNKQio2zU; Thu, 2 Mar 2017 18:47:20 -0800 (PST)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::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 1231F12946C; Thu, 2 Mar 2017 18:47:20 -0800 (PST)
Received: by mail-oi0-x232.google.com with SMTP id f192so49528900oic.3; Thu, 02 Mar 2017 18:47:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AMOBdZuHDOfuYfBTqTBpQ7B0Dzyp5fAAOgsWwouf5lI=; b=cwTgG1PTDJtGt7cw7UPNH/b0eoo7HpA/tUxhAQRK1VJ3Ex8dxHbnGBe6sK1KLl43oF qMdj31CrvKlhMgSwdNkeg/3CTzwXt+naxjmGHIoBaEpQZUPf7O/D5BeJFRco/E9uBjuL QJXV19tj7zAUReb76MC8guVqNEEQpOSIckwWUdW8C5DwqY88Ao7aU3hiIgOmnijt1ACe At4yynd1RBenTudmluWBV0HPG2PTLo3QZz6xvqo5HelSe6kkcJVMrNCLM7/C6ZpdZIK2 wvO8ltSKVGuFPlLKw9YEkM0cqbTZiYigakKFfc8DK/Mk8DiI/cqYsSK7AhI+Ao+tJMsl Hx/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AMOBdZuHDOfuYfBTqTBpQ7B0Dzyp5fAAOgsWwouf5lI=; b=AQbJj4/lYudR8y4//4w6dHSsYnmIWpUgAMNeZg7/LN55mszUCgMGO28KCTE2zfbCAr xgrh6kwZgcslGuEhSfxupxPXMo4iwIoceqKXTz4aPhDgZyWjwSRDzTu0Q3apcCSiHwOo nf/NLn5o/+/YRzeWTKkvJNWM1/TkMvfK4F/D+d2VE6FF9Q+Vmhn1zvGXoQaGr7GtpIug 9LYWlG0bOKBdxcMOFiV0vTurr+w7IGxT8oWVElSzeJHdA548pgTbyOf4lIxaB2tQUmxA RSQq4X974HBQFl5Ua3nl3WSwFSY24eyXH9fwtq9rigE8jyOLmflxt7K0M46SCUmgjwFV ow4Q==
X-Gm-Message-State: AMke39m8Ynzs1OnAnSAQk6GClBAsWVQJkYwBde3a8pcsSafeOdpngaP3Dqm+tMnPP3RBVcOQNhxwAPlvoLaOLA==
X-Received: by 10.202.232.210 with SMTP id f201mr216343oih.60.1488509239372; Thu, 02 Mar 2017 18:47:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.21.21 with HTTP; Thu, 2 Mar 2017 18:47:18 -0800 (PST)
In-Reply-To: <148838693301.7079.14351576385669069452.idtracker@ietfa.amsl.com>
References: <148838693301.7079.14351576385669069452.idtracker@ietfa.amsl.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 02 Mar 2017 18:47:18 -0800
Message-ID: <CA+RyBmUdQVjEcsYuKEqoK5eW_0F3p_u4k9rnmjD6wBy4qMuPCA@mail.gmail.com>
To: Mirja Kühlewind <ietf@kuehlewind.net>
Content-Type: multipart/alternative; boundary="001a11407b327530de0549ca90e6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/2kWnWF_ep61ZnNPIqobi4kyCTVI>
Cc: mpls-chairs@ietf.org, draft-ietf-mpls-residence-time@ietf.org, "mpls@ietf.org" <mpls@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [mpls] Mirja Kühlewind's No Objection on draft-ietf-mpls-residence-time-14: (with COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Mar 2017 02:47:21 -0000
Hi Mirja, thank your for the review and the comments, most helpful. Please find my answers in-line tagged GIM>>. Regards, Greg On Wed, Mar 1, 2017 at 8:48 AM, Mirja Kühlewind <ietf@kuehlewind.net> wrote: > Mirja Kühlewind has entered the following ballot position for > draft-ietf-mpls-residence-time-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > High level comment: > Maybe extend the security section a bit and describe what can happen in > the worse case if the value has been modified to a too high or too low > value; and maybe even given some guidance on performing additional checks > to figure out if a given value is reasonable for a given path or not. > > Questions: > - Can you explain why PTPType, Port ID, and Sequence ID are needed in the > PTP Sub-TLV format if those values are already in the PTP packet itself > that follows? > GIM>> We propose to copy these values as they uniquely identify PTP control message as these are required for two-step mode and suggesting inspection of the PTP payload would cause layer violation. - Why is it necessary to define PTP sub-TLV (and have a registry for one > value only)? Are you expecting to see more values here? What would those > values be? > GIM>> We may have another protocols or applications to use RTM and these the most likely will have their specific set of parameters to uniquely identify control session for two-step mode. One obvious case would be NTP when on-path support is defined. But since we don't know which parameters will uniquely identify cotrol session we don't request code point allocation. > - Similar to Spencer's question: Why don't you also define a Sub-TLV > format for NTP? > GIM>>Hope that above answer addresses this question. > - sec 4.3: "RTM (capability) - is a three-bit long bit-map field with > values > defined as follows: > * 0b001..." > Maybe I don't understand what a bit-map field is here but these are > more then 3 bits...? > GIM>> '0b' identifies binary format as '0x' identifies hexadecimal format of notation. > - also sec 4.3.: "Value contains variable number of bit-map fields so > that overall > number of bits in the fields equals Length * 8." > However there is no field 'Value' in the figure... GIM>> Thank you for pointing. I'll update Figure 4 and Figure 5 to add Value tag on the field immediately following RTM field. > Also the following > explanation about future bit-maps is really confusing to me; why don't > you just say that the rest as indicated by the length field must be > padded with zeros...? > - Should section 4.8 maybe be a subsection of 4.7? This part confused me > a bit because the example seems to be generic but the rest is RSVP-TE > specific, right? Maybe move the example as a separate section before or > after the whole section 4...? > > Nits: > - Maybe change to title to: Residence Time Measurement (RTM) in MPLS > network > - There are (still) some not spelled out abbreviations (LDP, PW); GIM>> Since both are used only once - expanded > in turn > others are extended twice (e.g. PTP)... > GIM>> Cleaned. > - In figure 1, I would rename 'Value' to 'Sub-TLV' and maybe also > indicate it as optional in the figure: Sub-TLV (optional) > GIM>> Agree
- [mpls] Mirja Kühlewind's No Objection on draft-ie… Mirja Kühlewind
- Re: [mpls] Mirja Kühlewind's No Objection on draf… Greg Mirsky
- Re: [mpls] Mirja Kühlewind's No Objection on draf… Mirja Kuehlewind (IETF)
- Re: [mpls] Mirja Kühlewind's No Objection on draf… Greg Mirsky
- Re: [mpls] Mirja Kühlewind's No Objection on draf… Mirja Kuehlewind (IETF)
- Re: [mpls] Mirja Kühlewind's No Objection on draf… Greg Mirsky
- Re: [mpls] Mirja Kühlewind's No Objection on draf… Mirja Kühlewind
- Re: [mpls] Mirja Kühlewind's No Objection on draf… Greg Mirsky