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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Giuseppe,

On Tue, Sep 5, 2017 at 10:16 AM, Fioccola Giuseppe <
[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]]
> *Inviato:* lunedì 4 settembre 2017 16:50
> *A:* Fioccola Giuseppe
> *Cc:* [e-mail]; [e-mail];
> [e-mail]; [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 <giuseppe.fioccola@
> telecomitalia.it> 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]]
> *Inviato:* domenica 3 settembre 2017 05:44
> *A:* [e-mail]
> *Cc:* [e-mail]; [e-mail];
> [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.*
>
>
>