Re: [Lsr] Tsvart last call review of draft-ietf-lsr-isis-rfc7810bis-03

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Thu, 06 December 2018 21:30 UTC

Return-Path: <nishida@sfc.wide.ad.jp>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5861311D6; Thu, 6 Dec 2018 13:30:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 SXhUKxn1hx90; Thu, 6 Dec 2018 13:30:52 -0800 (PST)
Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 832311311D4; Thu, 6 Dec 2018 13:30:51 -0800 (PST)
Received: from mail-it1-f171.google.com (mail-it1-f171.google.com [209.85.166.171]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 902692787C5; Fri, 7 Dec 2018 06:30:49 +0900 (JST)
Received: by mail-it1-f171.google.com with SMTP id z7so3824623iti.0; Thu, 06 Dec 2018 13:30:49 -0800 (PST)
X-Gm-Message-State: AA+aEWYUz7rG8FFbqHabGMgq7MJvWf86gCGuJD9pKovycEkTrcPAy4/0 GqU+0zPa9KctBupVWNbIKI4thaop0Y3z9NTzPng=
X-Google-Smtp-Source: AFSGD/V6EsxTqEsNEpZOu1BfUhJB5o1hsYbsDlceFd+B2GFNaMZYnJjm3hyYp+KFo1ivMD2qX8mtb5o2jD+UVBa86us=
X-Received: by 2002:a24:4016:: with SMTP id n22mr14936ita.25.1544131848281; Thu, 06 Dec 2018 13:30:48 -0800 (PST)
MIME-Version: 1.0
References: <154403709395.31955.8914260506541556177@ietfa.amsl.com> <347556ed4ea34fa7844085e5a6639f13@XCH-ALN-001.cisco.com>
In-Reply-To: <347556ed4ea34fa7844085e5a6639f13@XCH-ALN-001.cisco.com>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Thu, 06 Dec 2018 13:30:36 -0800
X-Gmail-Original-Message-ID: <CAO249yepsH6d_cm7Grujvbb=bGiUXf9kUSY3ifdjFo6Hnpo7Ow@mail.gmail.com>
Message-ID: <CAO249yepsH6d_cm7Grujvbb=bGiUXf9kUSY3ifdjFo6Hnpo7Ow@mail.gmail.com>
To: ginsberg@cisco.com
Cc: "nishida@wide.ad.jp" <nishida@wide.ad.jp>, tsv-art@ietf.org, lsr@ietf.org, ietf@ietf.org, draft-ietf-lsr-isis-rfc7810bis.all@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004da7d8057c6136ea"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/l96-iHIldLew5L4prwDnbvKyoXs>
Subject: Re: [Lsr] Tsvart last call review of draft-ietf-lsr-isis-rfc7810bis-03
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Dec 2018 21:30:58 -0000

Hi Les,

On Wed, Dec 5, 2018 at 4:51 PM Les Ginsberg (ginsberg) <ginsberg@cisco.com>
wrote:

> Yoshi -
>
> Thanx for taking the time to review.
>
> I can appreciate that this may the first time you have looked at RFC7810 -
> let alone the bis draft. As a result you have commented on content which is
> common to the bis draft and the RFC it is modifying (RFC 7810).
>
> While your questions in isolation may be interesting, I believe they are
> out of scope for the review of the bis draft. What the bis draft is doing
> is addressing two modest errata - details of which can be found in
> https://tools.ietf.org/html/draft-ietf-lsr-isis-rfc7810bis-03#appendix-A
> Comments on content not related to those changes is out of scope.
>

Just to be clear, my comments on this draft were clarification questions
which won't request changes in the spec of the draft because I thought
there are a certain ambiguities in the draft.
But, if what you really mean is there is no ambiguities or confusions among
expected readers on the points I made, it makes a sense to me and I can
think I had unnecessary concerns.
However, I'm not fully sure about it yet.

For example, the draft mentions about delay variation and it seems to me
this term is a bit ambiguous. If expected readers can understand it means
(for example) mean deviation, I am fine with it.
But, in this case,I might want to see supportive comments on this view from
the community.
Or, if you can clarify that even if there are some discrepancies between
implementations it won't affect overall performance of the applications,  I
am also fine with it.

Anyway, I just tried to do my best to read and review the draft. I hope
not, but if the points I made don't make sense please let me know.
I would like to leave further decisions to ADs.

If you have an interest in this topic and want to comment on the substance
> of RFC 7810 and its companion document for OSPF RFC 7471, I encourage you
> to do so. Note that all of your comments (save the one on Security) are
> also applicable to RFC 7471 - so any agreed upon modification would need to
> be made to both documents. But I do not want to even start discussing such
> changes in the context of reviewing the bis draft changes. I hope you can
> understand why.
>
> As regards your Security comment, I am not sure I understand what you are
> suggesting. As IGP info is flooded hop-by-hop, man-in-the-middle attacks
> have to be able to insert themselves on an IGP enabled link. Use of
> cryptographic authentication prevents untrusted sources from being accepted
> - which is the point being made.
>

As Spencer already made my point clear (Thanks Spencer!), I was wondering
if we need a normative language here as the draft mentions these info can
be sensitive.
I was also wondering why the draft didn't mention encryption while it
conveys sensitive info.

Thanks,
--
Yoshi



> > -----Original Message-----
> > From: Yoshifumi Nishida <nishida@wide.ad.jp>
> > Sent: Wednesday, December 05, 2018 11:12 AM
> > To: tsv-art@ietf.org
> > Cc: lsr@ietf.org; ietf@ietf.org;
> draft-ietf-lsr-isis-rfc7810bis.all@ietf.org
> > Subject: Tsvart last call review of draft-ietf-lsr-isis-rfc7810bis-03
> >
> > Reviewer: Yoshifumi Nishida
> > Review result: Almost Ready
> >
> > This document has been reviewed as part of the transport area review
> > team's
> > ongoing effort to review key IETF documents. These comments were written
> > primarily for the transport area directors, but are copied to the
> document's
> > authors and WG to allow them to address any issues raised and also to the
> > IETF
> > discussion list for information.
> >
> > When done at the time of IETF Last Call, the authors should consider this
> > review as part of the last-call comments they receive. Please always CC
> > tsv-art@ietf.org if you reply to or forward this review.
> >
> > Summary: This document is almost ready for publication, but several
> points
> > need
> > to be clarified.
> >
> > 1: In Section 1:
> >      "While this document does not specify how the performance
> information
> >      should be obtained, the
> >       measurement of delay SHOULD NOT vary significantly based upon the
> > offered
> >       traffic load."
> >
> >    It is not clear to me that why the measurement of delay should not
> vary
> >    here. Also, queuing delay might be useful info to infer path status.
> Could
> >    you elaborate the delays that the draft tries to capture?
> >
> > 2: In Section 1:
> >      "Thus, queuing delays SHOULD NOT be included in the delay
> > measurement. "
> >
> >    Is it clear for expected readers how to exclude queuing delays in
> their
> >    measurements? Don't we need to provide any guidances or references
> > here?
> >    Also, what they should do if they cannot exclude it?
> >
> > 3: In Section 2:
> >
> >      "All values (except residual bandwidth) MUST be calculated as
> rolling
> >      averages where the
> >       averaging period MUST be a configurable period of time."
> >
> >    This requirement is a bit different from the following texts in
> Section 5:
> >    Also, does this mean only simple moving average must be used or any
> > forms of
> >    moving average is acceptable?
> >
> >     "The values advertised in all sub-TLVs (except min/max delay and
> >      residual bandwidth) MUST represent an average over a period or be
> >      obtained by a filter that is reasonably representative of an
> average.
> >      For example, a rolling average is one such filter."
> >
> > 4: In Section 4.3:
> >
> >     "This sub-TLV advertises the average link delay variation between two
> >      directly connected IS-IS neighbors.  The delay variation advertised
> >      by this sub-TLV MUST be the delay from the local neighbor to the
> >      remote one (i.e., the forward-path latency)."
> >
> >    Sorry.. I am not sure how to measure delay variation here. I think
> more
> >    explanation is needed. It seems that it is not variance as the unit
> is sec.
> >
> > 5: In Section 11:
> >
> >     "The use of Link State PDU cryptographic authentication allows
> mitigation
> >     the risk of man-in-
> >      the-middle attack."
> >
> >    When there is a risk for man-in-the-middle attack, don't we need more
> > strong
> >    requirements for the use of security mechanisms?
> >
> > Thanks,
> > --
> > Yoshi
>
>