Re: [Int-dir] R: Intdir last call review of draft-ietf-ippm-alt-mark-10

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

Just on the mechanics -

On Wed, Sep 20, 2017 at 9:50 AM, Fioccola Giuseppe <
[e-mail]> wrote:

> Hi Brian,
> Ok, Thank you!
>
> Giuseppe
>
> -----Messaggio originale-----
> Da: Brian Haberman [mailto:[e-mail]]
> Inviato: mercoledì 20 settembre 2017 16:29
> A: Fioccola Giuseppe; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Oggetto: Re: R: Intdir last call review of draft-ietf-ippm-alt-mark-10
>
> Hi Giuseppe,
>      I am fine with your proposed changes, but I would recommend that you
> wait until the AD or doc shepherd indicate that the changes be made.
>

Giuseppe has responded to his reviewer with proposed text changes, and
(even better) has feedback from his reviewer.

That's what matters most. Submitting an update at that point is often
harmless, but risks getting feedback from other reviewers, and from the
IESG, that touches the same text, so then the editor is left to mix
everything together and have a coherent update come out. Even worse, it can
happen that you get different ADs balloting on different versions of the
draft and providing comments that other ADs have to analyze when balloting.
So, waiting for the telechat, and submitting one update that addresses the
comments received, is fine with me.

Other ADs might have other preferences for a specific draft, but since this
one's mine, let's go with my opinion for now :D ...

Spencer


>
> Regards,
> Brian
>
>
> On 9/19/17 8:22 AM, Fioccola Giuseppe wrote:
> > Hi Brian,
> > Thanks for your valuable review of the document.
> > Please see my answers inline tagged as [GF].
> >
> > Best Regards,
> >
> > Giuseppe
> >
> > -----Messaggio originale-----
> > Da: Brian Haberman [mailto:[e-mail]]
> > Inviato: lunedì 18 settembre 2017 16:40
> > A: [e-mail]
> > Cc: [e-mail]; [e-mail];
> > [e-mail]
> > Oggetto: Intdir last call review of draft-ietf-ippm-alt-mark-10
> >
> > Reviewer: Brian Haberman
> > Review result: Ready with Nits
> >
> > * The shepherd writeup mentions IPR 2557 in relation to this draft.
> However, the IPR declaration is only associated with the original
> individual draft. The IPR declaration needs to be updated to refer to the
> WG draft.
> >
> > [GF]: If needed we can renew the IPR declaration to refer to the WG
> draft.
> >
> > * The introduction says that this technique is needed to help monitor
> time & loss sensitive traffic. That would seem to indicate a need to
> associate these counters with individual flows. Has anyone done any
> calculations on how these counters will scale? Section 5 seems to indicate
> that there were only a few number of counters implemented via ACLs.
> >
> > [GF]: It is important to say that you can select the flow to monitor in
> several ways. In general a flow can be defined by a set of selection rules
> (e.g. headers fields) used to match a subset of the packets. In this way it
> is possible to control the number of involved nodes, the paths followed by
> the packets and the size of the flows. That is a general consideration.
> > In practice, as an example, the Telecom Italia experiment has been
> applied to the BackHauling traffic implemented with a VPN MPLS and we
> consider a flow as all the packets sharing the same source IP address or
> the same destination IP address, depending on the direction. It has been
> implemented by using router capabilities, so we developed scripts for the
> automation, policies for marking and ACLs for counting. Our implementation
> scale up to 500 flows monitored together on Cisco 7609 router, 1000 IPv4
> and 1000 IPv6 flows on Cisco ASR9000. We have also an experimental
> implementation on dedicated HW that scales more. If you agree I can add
> more information in Section 5.
> >
> > * The draft sets out to develop this technique without augmenting packet
> formats. That makes the statement in section 3.1.1 about how to color
> packets is out of scope a bit disingenuous. I would have preferred a brief
> description of the few available options on coloring packets in this
> section.
> >
> > [GF]: This sentence may be useful to open the door to future
> implementation. Section 5 explains the examples of implementation we have
> for now. But, of course, we can add a reference to section 5 in section
> 3.1.1.
> >
> > * The mention of maintaining timestamps for delay measurements is
> under-specified. Would the 32-bit NTP timestamp format be sufficient? The
> 64-bit NTP timestamp format? Guidance on how to carry out experimentation
> with this approach seems useful. Does the concept of adding timestamps per
> color block conflict with the first bullet of section 7 (only uses features
> already available on routers)?
> >
> > [GF]: the first bullet of section 7 means that a basic "homemade"
> implementation of the method can be possible by using features already
> available on routers: policy for marking, ACL for counting and Netflow to
> obtain timestamps of first/last packets of a batch. But in general we hope
> to have an optimized implementation that, as you point out, makes this
> sentence not true. So I propose to modify the sentence in the first bullet
> of section 7.
> > Regarding timestamps we can say that all the timestamp formats are
> allowed, because it's managed out-of-band. The format (NTP or PTP) depends
> on the precision you want.
> >
> > * If the above statement on per-flow counters is not true, can I not
> accomplish the same capability by harvesting ifMib stats per interface and
> compare xmit/recv/drop stats across the network?
> >
> > [GF]: Yes you can do that but it is not so precise because you cannot
> know that nodes you are comparing are referring to exactly the same time
> interval and exactly the same packets. The great advantage of alternate
> marking method is that it solves these synchronization issues creating
> packet batches.
> >
> > * The description of the Telecom Italia experiment references a 5-minute
> window per color. For time sensitive traffic like IPTV, how useful was the
> 5-minute reporting window? Were corrective actions taken prior to calls
> being handled by support?
> >
> > [GF]: The choice of 5 minutes period has been made to make it coherent
> with the reporting window of our NMS. We use a threshold for the packet
> loss rate in 5 minutes that originates alarms for the Operation department.
> Another reason is that long windows simplify our "homemade" implementation.
> For example the Huawei implementation (section 5.2) uses very short windows
> (seconds).
> >
> > * The Telecom Italia experiment writeup does not mention how the
> counters were harvested from the routers. Were readily available tools used
> to do this?
> >
> > [GF]: Our scripts on board of the router collect the counters of the
> flows under monitoring and then send them out to the NMS that will make
> packet loss calculation. The tools have been developed in our NMS
> development team. Also Huawei developed this features in its network
> management tool.
> >
> >
> > 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.
> >
>
>