Re: [ippm] AD Evaluation of draft-ietf-ippm-alt-mark-07

["Carlos Pignataro (cpignata)" <[e-mail]>]

Hi Spencer, Giuseppe,

I concur. I really like the outcome and overall structure indeed! Thank you both!

Thanks!

—
Carlos Pignataro, [e-mail]<mailto:[e-mail]>

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

On Sep 5, 2017, at 12:02 PM, Spencer Dawkins at IETF <[e-mail]<mailto:[e-mail]>> wrote:

Hi, Giuseppe,

On Tue, Sep 5, 2017 at 10:16 AM, Fioccola Giuseppe <[e-mail]<mailto:[e-mail]>> wrote:
Hi Spencer,
I have just published a new version (-08) of the draft that includes only the structural changes.
Here is the Diff file: https://tools.ietf.org/rfcdiff?url2=draft-ietf-ippm-alt-mark-08.txt
Please note that sometimes the repositioning of paragraphs and sentences implicates some editorial changes in order to make the text flowing coherently.

Once you have checked this new version, I will go ahead with other revisions.

I've looked at it, and I'm really happy with the structural changes. Thanks for doing block moves with few editorial changes first, to make that easy for me.

From my perspective, it's ready for you to work through my other comments. I bet there aren't many left.

Dear Carlos-the-shepherd, could you let Giuseppe know whether you agree? :-)

Thanks,

Spencer

Best Regards,

Giuseppe

Da: Spencer Dawkins at IETF [mailto:[e-mail]<mailto:[e-mail]>]
Inviato: lunedì 4 settembre 2017 16:50
A: Fioccola Giuseppe
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Oggetto: Re: AD Evaluation of draft-ietf-ippm-alt-mark-07

Hi, Fioccola,

Top-posting, because I'm only responding with "thank you, that all sounds great".

Thank you, that all sounds great!

Spencer

On Mon, Sep 4, 2017 at 9:35 AM, Fioccola Giuseppe <[e-mail]<mailto:[e-mail]>> wrote:
Hi Spencer,
First of all, I would like to thank you for your valuable comments. Your revision makes a lot of sense to me.
Regarding your notes for the authors and editors, you can find my answers inline tagged as [GF]

As you suggest, I will keep the structural changes and any other changes in separated versions. I will work on it in the coming days.

Best Regards,

Giuseppe

Da: Spencer Dawkins at IETF [mailto:[e-mail]<mailto:[e-mail]>]
Inviato: domenica 3 settembre 2017 05:44
A: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Oggetto: AD Evaluation of draft-ietf-ippm-alt-mark-07

Hi, Carlos,

I've divided my evaluation feedback into two sections.

  *   I really like this draft,
  *   and there's a lot of good ideas in it, and a lot of good text in it,
  *   and I have about 6 pages of comments from AD Evaluation.
Please don't be disturbed by the "6 pages of comments" part. I seem to send lots of comments about really good IPPM work ... and then it gets published.

Bill and Brian are accustomed to this, after four years with me.

Please let me know what the plan for revision turns out to be. I'm expecting to see this draft come back soon, because I'm expecting lots of text to move, but not very much text to change, so I'll leave it in "AD Evaluation" state, and change the substate to "Revised I-D Needed". So, NOT returning this to the working group in the datatracker.

Thanks, and it's always a pleasure.

Spencer

--- For the shepherd and chairs (everyone else is welcome to read this part, but you don't have any actions to take unless the shepherd and chairs ask you to, so you could also safely skip down to "--- For the authors and editors", about a page down).

I get no joy from asking this, but I note that this draft has eight names of authors and editors, so I’m looking for confirmation from the chairs that all of the names significantly contributed to the document.

(I’d ask the editor who has contributed significantly, but there are six editors listed. I’ve never seen that before, and can imagine that if the pen has rotated around, six people could have held it at some point since it was an individual -00 draft, but is the working group expecting six people to hold the pen when ADs start sending ballots with DISCUSSes and Comments?)

The reason I’m asking now, is that when this draft goes into IESG Evaluation, this text from the  RFC Editor’s Style Guide (https://tools.ietf.org/html/rfc7322#section-4.1.1) comes into play:

   The total number of authors or editors on the first page is generally
   limited to five individuals and their affiliations.  If there is a
   request for more than five authors, the stream-approving body needs
   to consider if one or two editors should have primary responsibility
   for this document, with the other individuals listed in the
   Contributors or Acknowledgements section.

and the working group chairs and participants are much better able to assess who should be listed than the IESG during a telechat.

And, with six editors listed, the IESG wouldn't know who to pick as editor without asking the people I'm asking now. So, let's handle this in the working group, ok? :-)

If the shepherd could include that confirmation in https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/shepherdwriteup/, probably under Working Group Summary, that would be outstanding, because that’s where balloting ADs would look before asking questions about this.

I looked at https://tools.ietf.org/rfcdiff?url1=draft-tempia-ippm-p3m-03.txt&url2=draft-ietf-ippm-alt-mark-07.txt, and it looks like a lot of that text was carried over without many changes. That's fine, but the structure of the document didn't change, and some things should have changed. I have a lot of comments below about the structure of the document, but most of the comments about structure would apply verbatim to https://datatracker.ietf.org/doc/draft-tempia-ippm-p3m/, which had all-Telecom Italia authors and editors, so that structure probably made sense in that context - just not for a document intended for implementers of this document as an RFC.

How this happens is up to the chairs and shepherd, but what I'd like, is for the next revision to look as if one person read through the document and my comments about structure, which I'll tag as "*** Includes suggestion for change to document structure", and do the right thing.

Because I'm suggesting strcutural changes which will make diffs unusable if implemented, it would be helpful for me, to see one revision with only structural changes, and then a second revision with any other changes. I'll be able to request Last Call sooner if I don't have to read every line of the next revision again - and I'm asking questions about very few changes to actual text, so I'd like to be able to spot them quickly after text MOVES.

--- For the authors and editors

In the Abstract,

   A report on the operational
   experiment done at Telecom Italia is explained in order to give an
   example and show the method applicability.

might read more clearly as “a report is provided in order to explain”.

[GF]: Agree

Recognizing that the authors know very well what’s on their own network, I’m wondering whether

   Nowadays, most of the traffic in Service Providers' networks carries
   contents that are highly sensitive to packet loss [RFC7680], delay
   [RFC7679], and jitter [RFC3393].

is true for all Service Providers. I wouldn’t have been at all surprised to see

   Nowadays, most Service Providers' networks carry traffic with contents
   contents that are highly sensitive to packet loss [RFC7680], delay
   [RFC7679], and jitter [RFC3393].

but the claim in the document is broader - “most traffic is highly sensitive”.

[GF]: Agree

In this text,

  The method proposed in this document follows the second approach, but
   it doesn't use additional packets to virtually split the flow in
   blocks.  Instead, it "colors" the packets

is there a reference you could provide for this use of the term “colors”? I mostly ask because the document already provides such good coverage on references, so this omission stood out. I see

  The previous IETF drafts about this technique were:
   [I-D.cociglio-mboned-multicast-pm] and [I-D.tempia-opsawg-p3m].

in the Acknowledgements section, so wonder if they would be helpfully mentioned here (or soon after), but I don't know if that would be helpful, and you folks would know what is helpful.

[GF]: the term “colors” could be  misunderstood, so I can explain better the operation or change “colors with “marks”. The reference to the previous draft can also be emphasized.

In this text,

   In order to coherently compare timestamps collected on different
   routers, the network nodes must be in sync.

is it obvious to everyone but me, what about the network nodes must be in sync? I can think of a number of things, but I’m guessing. If this was a clocking thing, I’d expect to see something like “the clocks on the network nodes must be in sync”.

In this text

   Due to ECMP, packet re-ordering is very common in IP network.  The
   accuracy of marking based PM, especially packet loss measurement, may
   be affected by packet re-ordering.  Take a look at the following
   example:

   Block   :    1    |    2    |    3    |    4    |    5    |...
   --------|---------|---------|---------|---------|---------|---
   Node R1 : AAAAAAA | BBBBBBB | AAAAAAA | BBBBBBB | AAAAAAA |...
   Node R2 : AAAAABB | AABBBBA | AAABAAA | BBBBBBA | ABAAABA |...

                        Figure 5: Packet Reordering

it would be clearer if “Take a look at the following example” provided enough detail to tell the reader what the reader is looking for - like, what does Node R1 add to this picture? I think from the text after Figure 5, your point is that when you see reordered packets, you can’t assign them unambiguously to an interval block, but I don’t know why the packets in the Node R2 row aren’t enough to make your point, which makes me wonder what you think is the difference between the Node R1 and Node R2 rows, that you needed both rows.

If I was guessing, something like ‘in Figure 5, the packet stream for Node R1 isn’t being reordered, and can be safely assigned to interval blocks, but the packet stream for Node R2 is being reordered, so there is no safe way to tell whether the packet with the marker of "B" in block 3 belongs to block 2 or block 4’ would make your point more clearly, but please explain what the two rows mean a little more clearly, however you do it.

[GF]: Yes, Figure 5 needs to be introduced better, like you suggest. I will do it and I will add also a reference to Section 3.2. where the timing aspects include also reordering problem.

*** Includes suggestion for change to document structure - I’m looking at

   Before going deeper into the implementation details, it's worth
   mentioning two different strategies that can be used when
   implementing the method:

   o  flow-based: the flow-based strategy is used when only a limited
      number of traffic flows need to be monitored.  This could be the
      case, for example, of IPTV channels or other specific applications
      traffic with high QoS requirements (i.e.  Mobile Backhauling
      traffic).  According to this strategy, only a subset of the flows
      is colored.  Counters for packet loss measurements can be
      instantiated for each single flow, or for the set as a whole,
      depending on the desired granularity.  A relevant problem with
      this approach is the necessity to know in advance the path
      followed by flows that are subject to measurement.  Path rerouting
      and traffic load-balancing increase the issue complexity,
      especially for unicast traffic.  The problem is easier to solve
      for multicast traffic where load balancing is seldom used,
      especially for IPTV traffic where static joins are frequently used
      to force traffic forwarding and replication.  Another application
      is on Mobile Backhauling, implemented with a VPN MPLS in Telecom
      Italia's network; where the monitoring is between the Provider
      Edge nodes of the VPN MPLS.

   o  link-based: measurements are performed on all the traffic on a
      link by link basis.  The link could be a physical link or a
      logical link (for instance an Ethernet VLAN or a MPLS PW).
      Counters could be instantiated for the traffic as a whole or for
      each traffic class (in case it is desired to monitor each class
      separately), but in the second case a couple of counters is needed
      for each class.

   The current implementation in Telecom Italia uses the first strategy.
   As mentioned, the flow-based measurement requires the identification
   of the flow to be monitored and the discovery of the path followed by
   the selected flow.  It is possible to monitor a single flow or
   multiple flows grouped together, but in this case measurement is
   consistent only if all the flows in the group follow the same path.
   Moreover, a Service Provider should be aware that, if a measurement
   is performed by grouping many flows, it is not possible to determine
   exactly which flow was affected by packets loss.  In order to have
   measures per single flow it is necessary to configure counters for
   each specific flow.  Once the flow(s) to be monitored have been
   identified, it is necessary to configure the monitoring on the proper
   nodes.  Configuring the monitoring means configuring the policy to
   intercept the traffic and configuring the counters to count the
   packets.  To have just an end-to-end monitoring, it is sufficient to
   enable the monitoring on the first and the last hop routers of the
   path: the mechanism is completely transparent to intermediate nodes
   and independent from the path followed by traffic flows.  On the
   contrary, to monitor the flow on a hop-by-hop basis along its whole
   path it is necessary to enable the monitoring on every node from the
   source to the destination.  In case the exact path followed by the
   flow is not known a priori (i.e. the flow has multiple paths to reach
   the destination) it is necessary to enable the monitoring system on
   every path: counters on interfaces traversed by the flow will report
   packet count, counters on other interfaces will be null.

and I'm wondering if this is true of Alternate Marking in general, or only for Telecom Italia. If it’s true in general, this seems really useful for everyone to know, but it’s in the Telecom Italia implementation report part of the draft, so it’s easy for people who only want to understand how Alternate Marking works to stop reading before they read down to it.

Perhaps moving the entire block of text, except for "The current implementation" sentence, earlier in the document, and leaving only

   The current implementation in Telecom Italia uses the flow-based strategy
   defined in Section (wherever you put it).

in the Telecom Italia section would be helpful.

[GF]: Totally Agree

*** Includes suggestion for change to document structure - I think pretty much all of 5.1.1, 5.1.2, and 5.1.3 would also apply generally, but you folks would know better. 5.1.4 does seem Telecom Italia-specific.

[GF]: Agree, but in this case I will split the text: the part that can be considered general will be moved earlier in the overall description while the part that is specific of the Telecom Italia implementation (e.g. bit of DSCP field to perform marking) will remain.

*** Includes suggestion for change to document structure - Actually, Sections 6 and 7 are still saying things like

   This document doesn't aim to propose a new Performance Metric but a
   new method of measurement for a few Performance Metrics that have
   already been standardized.

that doesn't seem specific to Telecom Italia. Which makes me wonder how much actual reporting ON the Telecom Italia implementation itself is in this document, and how much of it is (perhaps something like) "generally-applicable lessons learned from the Telecom Italia Implementation". Maybe just changing the high-level descriptions would be better than trying to separate this part of the report into "what's true for all Alternate Marking" and "what's specific to Telecom Italia".

Please take all this as a compliment. The text flows really well in sections 5-7. My concern is only that people who need to read it will have stopped before they read it.

[GF]: Thanks a lot and I understand your point. The change to document structure will reduce Telecom Italia specific implementation section, however that report includes some very useful peculiarities for a Service Provider implementation (e.g metric transparency, choise of marking bits, NMS oriented architecture,…)

In Section 8,

   the measurements described in this document
   are passive, so there are no packets injected into the network
   causing potential harm to the network itself and to data traffic.

might be clearer if it said "no new packets injected".

(I know you know this stuff, but you're also writing for reviewers, ADs, and actual implementers of your RFC who may not know that)

[GF]: Agree

*** Includes suggestion for change to document structure - You talk about "harm caused by the measurement" and "harm to the measurement" (and that's good), but I think the paragraph that starts

  The measurement itself may be affected by routers

falls into the second group, and then the paragraph that starts

   One of the main security threats in OAM protocols is network
   reconnaissance;

goes back to the first group. If you switched the order, this section would be divided more clearly into the two groups (and network security folk who are only worried about "harm caused by the measurement" can safely stop reading when they get to the parts about "harm to the measurement"). Maybe dividing the Security Considerations section into two named sub-sections would be helpful to readers.

[GF]: Ok I will do the division

I'm not happy about this, but in 2017, we're worried about people who have really good capabilities for pervasive monitoring (see BCP 188 at https://tools.ietf.org/html/rfc7258 to remind yourself why). So I'm thinking that in this text,

   One of the main security threats in OAM protocols is network
   reconnaissance; an attacker can gather information about the network
   performance by passively eavesdropping to OAM messages.  The
   advantage of the methods described in this document is that the
   marking bits are the only information that is exchanged between the
   network devices.  Therefore, passive eavesdropping to data plane
   traffic does not allow attackers to gain information about the
   network performance.

your point is that that attackers can't gain information about network performance from a single monitoring point, and must use synchronized monitoring points at multiple points on the path, because they have to do the same kind of measurement and aggregation that Service Providers using Alternate Marking must do.

If that's true, it's probably worth saying, before a secdir reviewer asks about it. And I should mention that I just looked at https://www.ietf.org/mailman/roster/secdir, and you COULD get the author of BCP 188 as your secdir reviewer ;-)

*** Includes suggestion for change to document structure - It would probably be helpful if your "Conclusions" section was significantly earlier in the document - it would strengthen your "Overview of the Method" section a lot, if it was there - and it's more "Summary" than "Conclusion". At a minimum, it shouldn't be behind the Security Considerations, because it's really helpful text, and the current location hides it.

[GF]: Of course

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.