Hi, Stewart and Alissa,It think the changes addess my comments pretty well.
The only remaining suggestion I have would be to avoid the use of delay in
s7.1. If I understand correctly, all measurements are of (inter-packet) gaps.
I think you could use gap instead of delay which woul avoid any
confusion.Thanks for the rssponses.Cherers,ElwynSent from my Galaxy
-------- Original message --------From: Alissa Cooper <ali...@cooperw.in> Date:
24/02/2021 16:23 (GMT+00:00) To: Stewart Bryant <stewart.bry...@gmail.com>,
Elwyn Davies <elw...@dial.pipex.com> Cc: m...@ietf.org, General Area Review
Team <gen-art@ietf.org>, draft-ietf-mpls-rfc6374-sfl....@ietf.org, Last Call
<last-c...@ietf.org> Subject: Re: [Gen-art] [mpls] Genart last call review of
draft-ietf-mpls-rfc6374-sfl-08 Elwyn, thanks for your review. Stewart, thanks
for your response. I entered a No Objection ballot as it seems the major issues
have been corrected or clarified. However, Elwyn, it would be good if you can
reply to Stewart with any remaining comments.Thanks,AlissaOn Feb 10, 2021, at
11:26 AM, Stewart Bryant <stewart.bry...@gmail.com> wrote:On 2 Feb 2021, at
15:27, Elwyn Davies via Datatracker <nore...@ietf.org> wrote:Reviewer: Elwyn
DaviesReview result: Not ReadyI am the assigned Gen-ART reviewer for this
draft. The General AreaReview Team (Gen-ART) reviews all IETF documents being
processedby the IESG for the IETF Chair. Please treat these comments justlike
any other last call comments.For more information, please see the FAQ
at<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.Document:
draft-ietf-mpls-rfc6374-sfl-??Reviewer: Elwyn DaviesReview Date: 2021-02-02IETF
LC End Date: 2021-01-26IESG Telechat date: Not scheduled for a telechatSummary:
Not Ready. Apologies that this review is rather late, but I found this
document extremely hard to work with. There appear to be a number of areas
where the work is rather too much in progress rather than ready for publication
as an RFC. That was some old text from an early version that was missed.I also
found it very difficult, not just as someone who is not at all familiar with
thisarea of work, but at a basic technical level to work out what the protocol
was going to be able to achieve and whether a LSR would garner the information
it appeared to need to deliver what was clamed. This is a document where you
need to understand MPLS, coloured marking and packet delay characteristics,
but I think anyone seeking to deploy this would already be familiar with
that.Part of this appeared to be due to multiple names being used for the same
thing and being used with other than their natural meaning particulaly in
sections 7.1 and 7,2. Major Issues:s7, What is being standardized?: A number
of methods are described. The expectation is that the MPLS WG possibly with
the assistance of the IPPM WG will select one or maybe more than one of
these methods for standardization.I find this statement very confusing. This
document is intended forstandards track, so if it goes ahead as is, the three
methods arestandardised and implementors would be expected to provide support
forall of them unless there are to be words to indicate that not all needto be
supported. Is this the intention? Or is it that this documentshould only
support the methods chosen by the MPLS working group? Inthe latter case, this
document is definitely not ready forstandardization; I assume the unused
method(s) would be removed in thiscase. Otherwise the second sentence is
speculative and should be removed.I have changed this text in response to other
comments received:It now says A number of methods are described. Each of these
methods has differentcharacteristics and different processing demands on the
packet forwader.The choice of method will depend on the type of diagnostic that
the operator seeks. s7, Title, purpose and general method:Note that I have very
limited knowledge of this area of performancemeasurement so there may be
misunderstandings here. However, given thatcaveat, I did not find the document
very helpful in enlightening me anda considerable amount of background reading
was needed to try anddetermine what was going on.It is always difficult to get
the balance right between a concise document for subject matter experts and a
detailed description.Firstly, I assume that this section covers the 'additional
techniques'mentioned in the Abstract That term does not seem to be in the
abstract. and described as 'more sophisticatedmeasurements' in s1. [Perhaps
common phraseology would be desirablebetween the two cases.] I suggest a
sentence to make this clear wouldbe desirable.I am afraid I cannot see the
conflict that you are concerned about.Secondly, AFAICS these techniques are
basically about measuring andcommunicating delay jitter in various ways. SB>
No, Method 1 is measuring jitter. Method 2 is measuring delay as is Method 3It
might be helpful tolink what is being offered here with RFC 5481 and the
discussion ofdelay variation measurement in RFC 6374. SB> I think we need to
assume that the reader is familiar with RFC6374Section 7.1 is, as Iunderstand
it, covering IPDV measurement using (in general) normalservice packets rather
than just specialised RFC 6374 packets andworking primarily on one LSR. I
assume that the technique in s7.2 isprimarily a means for reporting
measurements derived from s7.1 and/ors7.4, but given that actual delays are
mentioned rather thaninter-packet gaps, theSB> All measurements take place on
user service data using SFL to SB> indicate different groups of packets. We are
using RFC6374 toSB> trigger measurements and collective results.s7.1: After the
first sentence, the first paragraph talks about delay. Since the receiving LSR
has no knowledge of the transmission time ofeach individual packet, it is not
possible for the LSR to calculateactual delays without additional information -
I take it that thepackets are not intended to be RFC 6374 Delay Measurement
Packets asthese would require corresponding responses which would contravene
thequery interval setting and there does not appear to be a way for theLSR
doing the measurements to be told the inter-packet transmissioninterval.
Should this be written in terms of inter-packet gaps ratherthan delays
throughout? SB> 7.1 is measuring the inter packet gaps so as you say is
measuringThe variation in the delay rather than the absolute delay. However
thisIs made clear in the text.Further, The first paragraph describes twomethods
of operation without saying which one should be standardised orAFAICS providing
a selection flag to allow either to be used.SB> We could do that but there is a
need for the operator to configure SB> other characteristics of the
measurement, for example the size of the SB> time increments that the buckets
represent, so this would just be anotherSB> such characteristic. The math in
the analytics engine to convert oneSB> method into the other is trivial (the
difference in the techniques isSB> about collection hardware optimisation) so I
don’t think we need toSB> pick one,It seems to me that an outline of how this
facility might be used ispretty much essential. Would I be right in thinking
that to measure thedelay jitter between a source LSR (S) and destination LSR
(D), theoperator decides to send a set of packets at equally spaced
intervalsfrom S to D and decides on the interval and the number of packets.
Sthen issues a Query setting the query interval to a time greater thanthat
needed to send the set of packets and using the Bucket JitterMeasurement
Message to set the bucket delay intervals around thesending interval according
to the Operator's expectations of thenetwork. D then sets up to measure the
inter-packet delays up until thenext Bucket Jitter Measurement message arrives
after the elapse of thequery interval when D returns the profile of
inter-packet delays.Does the arrival of this second Bucket Jitter Measurement
Messagetrigger a further set of measurements? And if so, how is the
sequenceended?SB> No, you send packets in one color then you change color and
thenSB> send an Query message and the response refers to the set of packetsSB>
before the colour changed.SB> The hardware continuously makes the measurement
and the SB> measurement system collects the results when it wants a test
result.s9.1: This section is headed by an Editor's Note saying that the
sectionneeds review which may alter the format of the TLV. It is
thusimpossible to say if this section is ready.SB> That is a note I had
forgotten to removeMinor Issues:s7.2: As with s7.1, there seems to be some
confusion bettween delay andinter-packet gap.Nits/editorial comments:Abstract:
The primary purpose of this document, as set out in s1, is toextend RFC 6374 to
cover general MPLS networks rather than primarilyMPLS-TP networks and in
particular to add support formulti-point-to-point LSPs. I think that it would
be helpful for thecasual reader to make this somewhat clearer in the abstract.
I suggest:OLD: This document describes a method of making RFC6374 performance
measurements on flows carried over an MPLS Label Switched path. This
allows loss and delay measurements to be made on multi-point to point LSPs
and allows the measurement of flows within an MPLS construct using
RFC6374.NEW: RFC 6374 describes methods of making loss and delay measurements
on Label Switched Paths (LSPs) primarily as used in MPLS TransportProfile
(MPLS-TP) networks. This document describes a method of making RFC6374
performance measurements on flows carried over general MPLS LSPs. In
particular, it extends the technique to allow loss and delay measurements to
be made on multi-point to point LSPs and introduces some additional
techniques to allow more sophisticated measurements to be made in both
MPLS-TP and general MPLS networks.ENDSSB> Thank you that is a good proposals1,
bullet 4: Would it be helpful to refer to RFC 7190 with respect
toaggregation?SB> Yes, I will add the ref.s1, bullet 5: s/counter
again/counter, again/SB> Fixeds3, last sentence: s/co-responding/corresponding/
[co-responding meansresponding together rather than matching. Look up
co-respondent incases of adultery in the divorce courts!]SB> Thanks.
Co-responding seems like a good term to get into a protocol description.s3,
last sentence: s/packet/packets/SB> Fixeds4, para 1: Expand TC: s/TC/Trafic
Class (TC)/SB> Fixeds5, para 1: s/proxy data service packets Section 4./proxy
data servicepackets (see Section 4)./SB> fixeds5, para 2: s/This it is/Thus it
is/SB> Fixeds5, para 2: s/are relatively independent/are made relatively
independent/SB> Text fixeds5, para 3: s/arises for the potential/arises from
the potential/SB> Fixeds5, para after Figure 1: s/were/where/SB> Fixeds5, next
to last para: s/which ever/whichever/SB> Fixed s6, para 1: s/measurement
type/measurement types/;s/combination/combinations/SB> Fixeds7: I assume these
are the additional facilities mentioned in theIntroduction. It would be
helpful to make this clear.SB> Text addeds7.1, para after Figure 2: The
acrronyms QTF, RTF, RPTF and DS shouldbe expanded. There is no section 3.7 in
RFC 6374. These items aredefined in Section 3.2.SB> Sorry Typo - thanks -
fixed.s7.1: The formats of the various numerical fields are not specified.
Iassume they are unsigned integers.SB> Yes, note addeds7.1, Number of Buckets:
I assume that an LSR is likely to have a limitfor this value. If the query
requests an unsupported amount shouldthere be a specific error code?
0x1A: Error - Resource Unavailable. Indicates that the
operation failed because node resources were not available.SB> Would
be the normal error messages7.3: s/In other that exception/In other than
exceptional/SB> Fixeds7.4: The formats for the time fields in the and the Sum
of Timestampsfield are not specified.SB> The subject of the various timestamp
formats is discussed in RFC6374.s8, first sentence: I am unable to parse 'a
delay measurement intervaldefined by an SL of constant colour' before being
introduced to RFC8321. Even then I don't know what SL stands for - it is not
used inRFC 8321 or RFC 6374.SB> That should be SFLs9: Expand GAL on first
use.SB> Dones9.1: Expand FEC on first use.SB> Dones9.1, para 2: Where is the
concept of well-defined array of SFLs defined?SB> I have added the following
text: Multiple SFLs can be assigned to a FEC each with
different actions. This index is an optional convenience for use in
mapping between the TLV and the associated data structures in the
LSRs.s9.1, Specification of FEC field: 'This is encoded as per Section 3.4.1of
TBD'... Er, there doesn't seem to be a reference for TBD.SB> Fixeds10: 'A
future version of the *this document*...' Is this a sign ofunfinishedness or
an indication that further documents will address thisissue? (apart from the
'the this'.)SB> Text removed - it was old texts13: I am not sure I can identify
the relevant issue in s5.SB> It should have pointed to the privacy section -
fixed.s14.2: s/request/requested/SB> Dones14.2, RFC Editor note: I presume the
RFC Editor should be asked todelete two lines - the ones before and after the
request.SB> I have changed it to para. It is a markdown device to include
something referenced in a figure.
_______________________________________________mpls mailing
listmpls@ietf.orghttps://www.ietf.org/mailman/listinfo/mpls_______________________________________________Gen-art
mailing listGen-art@ietf.orghttps://www.ietf.org/mailman/listinfo/gen-art_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
