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 19:10 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 56E98129997; Fri, 3 Mar 2017 11:10:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, 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 WTJiLrIGDmD7; Fri, 3 Mar 2017 11:10:14 -0800 (PST)
Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 38B5D1295C0; Fri, 3 Mar 2017 11:10:14 -0800 (PST)
Received: by mail-oi0-x229.google.com with SMTP id 62so60620327oih.2; Fri, 03 Mar 2017 11:10:14 -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=IcUFdnRDZuVcqp9xGJEagNPWgCF8IF1TiQPAOL5ovy0=; b=BFLzbvssJGjXD4WTt7pfSLyeTz1awol+BF0+KjUdpzTsk4H3mqHzM3QKaaPGjfoUfy T49CLK62aHMFZvi9C3+GpgXh/lEXMjNG9E6Fny6zRhe8nz0z+tKRTX/NLiVlXYiSDvMm /vLx17bBoKpXffRLjAqhIX0WlZ6KZzi2J8CAJCf+VsANdXu7PkuyJvO8BVYLVXBUNDOs Kaz9nAteDvUWgytfQ/qgibHMo6a/k0PXlsF/PObwLWNRYz0wxNDyJA/ogyDy2gHQhrz+ L1l9ih9h9I0OqGgfhsPK8bu/tIHDmjayFh5CepG7ZHBZWXzAXHEQRW0lTxoM+ZgU+XJc YSFg==
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=IcUFdnRDZuVcqp9xGJEagNPWgCF8IF1TiQPAOL5ovy0=; b=djbekaNxtUDEldxSHNZvP7dklEIk22NP1r6X00UEMLxOCAIiox2x/kPabdbbN1eSsT cZdPknm0GQxvUlwyQEext6MCzc663VOpt7uLHDfJdeeAgHx41p+uxcpNExA5OrpgqitI 9V5uuD6pKkMGX7LGSpaTFsEkkNUWn2pemd6y35Ajb9JW8YM25+BHIfPQ/TJTCcSwEhyd 9OxytqYwtODoecVxnl7A4DxIqyq5dlXY5g7xgsdJ9Z97xTLufp3oDkuLo5duPO4kTnSC JLgQxKYxpeFVFz2tEPFnDlx/uelM+YCFCS1EeENeAQFjvTljvZuwcfj//spZE7ceyteT taRg==
X-Gm-Message-State: AMke39mu/7XulreCDARq5GsR5YLFeKGFjrtSAkT36lmLD6igTclWjX6+JFjRmEVTHlsXItCz6rEFs7X/ywX30g==
X-Received: by 10.202.239.2 with SMTP id n2mr2386898oih.157.1488568213432; Fri, 03 Mar 2017 11:10:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.21.21 with HTTP; Fri, 3 Mar 2017 11:10:13 -0800 (PST)
In-Reply-To: <EF923ED1-114F-43BA-95C1-F81864946788@kuehlewind.net>
References: <148838693301.7079.14351576385669069452.idtracker@ietfa.amsl.com> <CA+RyBmUdQVjEcsYuKEqoK5eW_0F3p_u4k9rnmjD6wBy4qMuPCA@mail.gmail.com> <EF923ED1-114F-43BA-95C1-F81864946788@kuehlewind.net>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Fri, 3 Mar 2017 11:10:13 -0800
Message-ID: <CA+RyBmXTu=u9AHV75b7=j=X_wwkcgB-GCcfeUmEv7RK4QgPp8g@mail.gmail.com>
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
Content-Type: multipart/alternative; boundary=94eb2c0931da95efa10549d84b37
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/ZC_Oi05eZ5xnNoaHBEGxrPAMnx4>
Cc: The IESG <iesg@ietf.org>, draft-ietf-mpls-residence-time@ietf.org, mpls-chairs@ietf.org, "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-mpls-residence-time-14=3A_=28with_COMMENT=29?=
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 19:10:16 -0000

Hi Mirja,
thank you for your comments and very helpful discussion. My notes in-lined
and now tagged with GIM2>>

Regards,
Greg

On Fri, Mar 3, 2017 at 1:46 AM, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net
> wrote:

> Hi Greg,
>
> see inline.
>
> Mirja
>
>
> > Am 03.03.2017 um 03:47 schrieb Greg Mirsky <gregimirsky@gmail.com>;:
> >
> > 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.
>
> I see. Maybe add a sentence that these field are use to identify the
> packet. However, when you copy them, you also have to inspect the payload
> and that’s the same layer violation. Also not sure if duplicating
> information in the packet is the best approach. Why don’t use just add an
> own identifier to the packet instead?
>
GIM2>> Will the following, when added at the very end of Section 3.1, work:

   Tuple of PTPType, Port ID, and Sequence ID uniquely identifies PTP
   control packet encapsulated in RTM message and are used in two-step
   RTM mode Section 2.1.1.

GIM2>> The RTM message created by egress or the first on the LSP two-step
RTM node. Thus other RTM nodes don't need to look into PTP control message
but use the PTP sub-TLV. Creating new identifier is certainly an
alternative but I believe that will require more state coordination between
LERs on the same RTM LSP. Re-using existing characteristic information, in
my view, is simpler solution.

>
> >
> > - 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.
>
> My understanding was that a new protocol would be a different RTM TLV in
> the registry in section 7.2. That’s fine. I don’t understand why your PTP
> sub-TLV needs ANOTHER TLV scheme: figure 2 and registry in sec 7.3.
>
GIM2>> RTM TLV differentiates  between different encapsulation types, e.g.
Ethernet, IPv4 or IPv6 but sub-TLV doesn't have to. Do you see this as a
problem?

>
> > - 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.
>
> Actually not really. Why don’t you know which parameters to use?
>
> > - 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.
> Ah sorry, fully overview that.
>
> > - 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.
>
> There are more questions here:
>
> > 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...?
>
GIM2>> The description follows RFC 7794 Section 2.1

> > - 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...?
>
GIM2>> Thank you, I agree it is more logical flow. With the change
suggested by Ben it will look like this:

   4.  Control Plane Theory of Operation . . . . . . . . . . . . . .  10
     4.1.  RTM Capability  . . . . . . . . . . . . . . . . . . . . .  10
     4.2.  RTM Capability Sub-TLV  . . . . . . . . . . . . . . . . .  11
     4.3.  RTM Capability Advertisement in Routing Protocols . . . .  11
       4.3.1.  RTM Capability Advertisement in OSPFv2  . . . . . . .  11
       4.3.2.  RTM Capability Advertisement in OSPFv3  . . . . . . .  13
       4.3.3.  RTM Capability Advertisement in IS-IS . . . . . . . .  13
       4.3.4.  RTM Capability Advertisement in BGP-LS  . . . . . . .  13
     4.4.  RSVP-TE Control Plane Operation to Support RTM  . . . . .  14
       4.4.1.  RTM_SET TLV . . . . . . . . . . . . . . . . . . . . .  15

>
> > 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
> >
>
>