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

From: "lizho.jin" <[email-masked]>
Date: Wed, 3 May 2017 23:16:02 +0800

Stewart, I am OK with the changes, thanks.

Regards

Lizhong

On 04/26/2017 02:30，Stewart Bryant<[email-masked]> 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:09，Loa Andersson<[email-masked]>
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: [email-masked]

Senior MPLS Expert                          [email-masked]

Huawei Technologies (consultant)     phone: +46 739 81 21 64