Re: [mpls] MPLS-RT review of draft-bryant-mpls-rfc6374-sfl

"lizho.jin" <lizho.jin@gmail.com> Wed, 03 May 2017 15:18 UTC

Return-Path: <lizho.jin@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 B8663129479; Wed, 3 May 2017 08:18:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.276
X-Spam-Level:
X-Spam-Status: No, score=-1.276 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, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, 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 FFhbL30s70av; Wed, 3 May 2017 08:18:08 -0700 (PDT)
Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 8B98E129489; Wed, 3 May 2017 08:16:05 -0700 (PDT)
Received: by mail-pf0-x241.google.com with SMTP id o68so4753747pfj.2; Wed, 03 May 2017 08:16:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-transfer-encoding:content-disposition; bh=k3ZJIPcOgqzeHyqL5rUulzHkTeZQpn1rXIhyXD9LfeI=; b=Bhc6lUZD16L+6yBHf2wnJeKnuO/+9rKHtVZ15TVIvTA3FQsNWXla267EkDD2TKFABj PMutzqU13YszHB+8kjspFmcWnI1zV/6+wGjvH77YE1ulDWpYdlP+UYU2gejLoTInp7u4 Tl5ZjX1EDoXuKmjS+56BFyNvR50VyPfA51jrEEkfEdd0+1KSiuA/31Ry3qy0821xEdCv W+9f43/fta0aNvKfZ7KKrP2/uH1QJPcHJGIKWEPu+ZRvQq/awau8KojNAHHaTwH8IEwY vgjy8fc9Y2QKDeiY24FIqhlyezJG6kprZEB+xmNhVxAdhQYUWZzMsUQCBFRoYLepp5Ru 7ETg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-transfer-encoding :content-disposition; bh=k3ZJIPcOgqzeHyqL5rUulzHkTeZQpn1rXIhyXD9LfeI=; b=DQZWIz3VfAbdD9hswWsArtqnac3Hup99LDmTglHLeWaP7eSiuUHkhLYXT3vM86fl8i icwB9uoLQRmiKtKhgApug5KWYhO6clxp6F5wJviTyxxM1dJFUHZUfuJepQvxT0QPFqSM hTT+hvj1f9vnUC2m3fX4aaufDFUUIrLmqxhqasAz33zQdUI09lOJ51phWYDUpM4aZAvl LvcRuFzkUjq0kIjJzWTcjn8BGFAHWGVqedfLPv6JYVS+S1E8NH8WjKoHcXIa5HBOwmr6 1unGPgscxacePs5v7GI8eAGS8Yg35C/r4Y19O458efZAH0t415pT9FV43OGcpKSQBIKv EtSA==
X-Gm-Message-State: AN3rC/5xiv1nWSf2JYlkDGUEwmFE4+JbiY8ZNcUAVOEhsGoLoxgK7IBo e97NmEler7pwNievYYk=
X-Received: by 10.98.25.78 with SMTP id 75mr5498693pfz.84.1493824565104; Wed, 03 May 2017 08:16:05 -0700 (PDT)
Received: from LLIOK4RX6E0B076 ([103.251.128.66]) by smtp.gmail.com with ESMTPSA id r90sm5890050pfl.120.2017.05.03.08.16.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 May 2017 08:16:03 -0700 (PDT)
Date: Wed, 3 May 2017 23:16:02 +0800
From: "lizho.jin" <lizho.jin@gmail.com>
To: Stewart Bryant <stewart.bryant@gmail.com>
Cc: Loa Andersson <loa@pi.nu>, draft-bryant-mpls-rfc6374-sfl <draft-bryant-mpls-rfc6374-sfl@ietf.org>, huubatwork <huubatwork@gmail.com>, "Andrew G. Malis" <agmalis@gmail.com>, Vishwas Manral <vishwas@nanosec.io>, mpls-chairs <mpls-chairs@ietf.org>, mpls <mpls@ietf.org>
Message-ID: <299CBBE1-0CFD-424D-BFB5-B602EAFC4469@gmail.com>
In-Reply-To: <4fe2d0af-480c-f9ae-d3a2-38fcd1c70772@gmail.com>
References: <3492a077-bc52-dd35-aed7-17fc6c749a8b@pi.nu> <20653DE4-B6BE-4915-AB22-0574891CD225@gmail.com> <4fe2d0af-480c-f9ae-d3a2-38fcd1c70772@gmail.com>
X-Mailer: PC MailMaster/3.3.1.1013 (Windows 7)
MIME-Version: 1.0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/-Ctr9yBUCSLNfrWy-9nktTfoQm0>
Subject: Re: [mpls] MPLS-RT review of draft-bryant-mpls-rfc6374-sfl
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 03 May 2017 15:18:10 -0000

Stewart, I am OK with the changes, thanks.


Regards
Lizhong

On 04/26/2017 02:30Stewart Bryant<stewart.bryant@gmail.com> wrote:



On 23/03/2017 15:14, lizho.jin wrote:
Hi,
I review this draft, and also the two related SFL draft. Overall, this document is useful and technically sound. And I have some non-blocking comments listed below. Regarding the adoption, I suggest to consider adopting draft-bryant-mpls-sfl-framework-03 first, then this draft which is highly relied on the concept of SFL.

I have read draft-bryant-mpls-sfl-framework, did a minor edit and uploaded it. draft-bryant-mpls-sfl-framework-04 is ready for a WG adoption call.


Section 3
   The data service packets of the flow being instrumented are grouped
   into batches, and all the packets within a batch are marked with the
   SFL [I-D.ietf-mpls-flow-ident]
[Lizhong] more suitable to refer [draft-bryant-mpls-sfl-framework], not [I-D.ietf-mpls-flow-ident]

[I-D.ietf-mpls-flow-ident] describes the requirements in a solution agnostic way. I think the reference is correct.

We then describe the problems and that takes us to the framework draft and hence to the solution.

So I think it's all OK.


Section 4
   Such a packet may not need to be carried over an SFL since the delay
   over a particular LSP should be a function of the TC bits.
[Lizhong] not understand here, adding SFL does not change the LSE and TC, why not possible to carry over SFL?

This is considering the case where we are using SFL to do packet loss, and want to do a single measurement of delay. We should be able to do this just by sending an RFC6374 packet over the LSP. However there is a corner case where RFC3270 (label based) prioritization is being used. I think there is another issue with ECMP. I will reword the section to make it clear.

The section now says:

RFC6374 describes how to measure the packet delay by measuring the
transit time of an RFC6374 packet over an LSP.  Such a packet may not
need to be carried over an SFL since the delay over a particular LSP
should be a function of the TC bits.

However where SFLs are being used to monitor packet loss or where
label inferred scheduling is used {{RFC3270}} then
the SFL would be REQUIRED to ensure that the RFC6374 packet
which was being used as a proxy for a data service packet experienced
a representative delay. The format of an
RFC6374 packet carried over the LSP using an SFL is shown in {{RFC6374SFL}}.

The packet loss case is petty firm, we need to think about the RFC3270 case, but
can do that post adoption.

 
Section 7
7.  Multiple Packet Delay Characteristics
[Lizhong] is it assumed here that all packets belong to one flow will go through the same path? Some network equipment may not be the case. E.g., case in RFC7424.

Normally we try quite hard to make sure the packets of a flow go over a single path, so that is a good assumption. If we are load balancing across a number of paths then The method still works, but the delays will be multi-modal. Some of the methods will show this better than others.


Section 7.1
   There will be a number of Interval/Number pairs depending on the
   number of buckets being specified by the Querier.  If an RFC6374
   message is being used to configure the buckets, the Responder MUST
   respond with 0 packets in each bucket until it has been configured
   for a full measurement period (i.e. it was configured at the time of
   the last response message).  Out of band configuration is permitted
   by this mode of operation.
[Lizhong] need detail process of Query and Reponse. E.g., does the query need "Number pkts in Bucket" field, and if not, please specify.

I have updated the text as follows:

There will be a number of Interval/Number pairs depending on the
number of buckets being specified by the Querier. If an RFC6374
message is being used to configure the buckets, (i.e. the responder
is creating or modifying the buckets according to the intervals  in
the Query message), then the Responder
MUST respond with 0 packets in each bucket until it has been
configured for a full measurement period. This indicates that it was configured
at the time of the last response message, and thus the response
is valid for the whole interval. As per the {{RFC6374}} convention
the Number of pkts in Bucket fields are included in the Query message and set
to zero.

Out of band configuration is permitted by this mode of operation.

Hopefully this sufficiently  clarifies the operation of the protocol.

7.3.1.  RFC6374 Multi-Packet Delay Measurement Message Format
[Lizhong] this is only for Classic Standard Deviation, right? why it is not section 7.2.1?


Fixed

7.4
   This RFC6374 message is carried over an LSP in the way described in
   [RFC6374] and over an LSP with an SFL as described in Section 9
[Lizhong] what's the format of query message, will it include "Time of First Packet", "Time of First Packet", and other fields?

I have added:

As is the convention with RFC6374, the Query message contains placeholders
for the Response message. The placeholders are sent as zero.



13.1.  Allocation of PW Associated Channel Type
   As per the IANA considerations in [RFC5586], IANA is requested to
   allocate the following Channel Type in the "PW Associated Channel
   Type" registry:

   Value  Description                    TLV Follows  Reference
   -----  -----------------------------  -----------  ---------
   TBD    Description MPLS Multi-Packet  No           This
          Delay Measurement
[Lizhong] there is other two message type need to be defined here. E.g., Bucket Jitter Measurement Message Format, Average Delay Measurement Message Format

Thanks for catching that I have added it

New version will uploaded when I have responded to all the review comments.

Thanks for the review

Stewart


Regards
Lizhong

On 03/9/2017 11:09Loa Andersson<loa@pi.nu> wrote:
Huub, Andy, Vishwas and Lizhong,

You have been selected as MPLS-RT reviewers for 
draft-bryant-mpls-rfc6374-sfl-03.

Note to authors: You have been CC'd on this email so that you can know
that this review is going on. However, please do not review your own
document.

Reviews should comment on whether the document is coherent, is it
useful (ie, is it likely to be actually useful in operational networks), 
nd is the document technically sound?

We are interested in knowing whether the document is ready to be
considered for WG adoption (ie, it doesn't have to be perfect at this
point, but should be a good start). Please remember that it often is
easier to progress the document when it has become a working group
document. All comments in the MPLS-RT review needs to be addressed,
but please think carefully about whether a comment is gating the
adoption or could just as easily be addressed after the adoption.

Reviews should be sent to the document authors, WG co-chairs and WG
secretary, and CC'd to the MPLS WG email list. If necessary, comments
may be sent privately to only the WG chairs.

If you have technical comments you should try to be explicit about what
needs to be resolved before adopting it as a working group document, and
what can wait until the document is a working group document and the
working group has the revision control.

Are you able to review this draft by March 23, 2017? Please respond
whether you are available to do the review in a timely fashion.


Thanks, Loa
(as MPLS WG co-chair)
-- 


Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64