Hi Benoit, I will work on the editorials shortly and I'm removing those from the discussion. See below:
On Mon, Apr 14, 2014 at 5:28 AM, Benoit Claise <[email protected]> wrote: > Hi Anoop, > > Thanks for the new draft version. > I removed some of the points > > > > > On Tue, Feb 18, 2014 at 7:55 AM, Benoit Claise <[email protected]>wrote: > >> - >> >> A number of routers support sampling techniques such as sFlow [sFlow- >> v5, sFlow-LAG], PSAMP [RFC 5475] and NetFlow Sampling [RFC 3954]. >> For the purpose of large flow identification, sampling must be >> enabled on all of the egress ports in the router where such >> measurements are desired. >> >> I don't understand the second sentence. >> One way to read this is: sampling must be * enabled *on all of the >> egress ports where such measurements are desired. >> Ok, this is an obvious statement. If the measurements are desired, >> enable them >> > > Yes, > > >> Or maybe you want to say: *sampling *must be enabled on all of the >> egress ports where such measurements are desired. >> This is a false statement: if you have the choice between sampling >> and non sampling, use non sampling measurements. >> Or maybe you want to say: sampling must be enabled on *all *of the >> egress ports where such measurements are desired. >> This is a false statement: if I have ECMP on 2 links, and only one of >> them can't do non sampling, then we should not force >> sampling on both links. >> You see, I'm confused. >> >> You miss a couple of key messages: >> - if unsampled measurements are available, use those. >> - egress means where LAG/ECMP are enabled (this is important for the >> paragraph starting with "If egress sampling is not available, ingress >> sampling can suffice since the central management entity use") >> > > We were not intending to discuss a mix sampling and non-sampling > interfaces in the same router, but this is a reasonable point and it will > be clarified (i.e. we will state that it's possible to mix sampled and non > sampled interfaces as long as the function of large flow > detection/identification can be performed). > > You're still missing the point that unsampled measurements is better than > sampled ones. > We do point this out in Section 4.3.4. http://tools.ietf.org/html/draft-ietf-opsawg-large-flow-load-balancing-10#section-4.3.4 >>> As link speeds get higher, sampling rates are typically reduced to keep the number of samples manageable which places a lower bound on the detection time. With automatic hardware recognition, large flows can be detected in shorter windows on higher link speeds since every packet is accounted for in hardware [NDTM <http://tools.ietf.org/html/draft-ietf-opsawg-large-flow-load-balancing-10#ref-NDTM>]. >>> > Is this what you mean by: > > It is possible that a router may have line cards that support a > sampling technique while other line cards support automatic hardware > detection of large flows. > > It's not very clear. > > No, this does not address your point. This is talking about the case where line cards have different capabilities, rather than a line card that supports both. Since we already have the advantages and disadvantages listed in 4.3.4, do you still see a need for explicitly mentioning that automatic hardware detection is to be preferred over sampling if both are available? We did debate the point about accuracy quite a bit among the authors. The question is -- does that level of accuracy really matter for the large flow case? Since we are dealing with flows that need to consume a certain percent of the link bandwidth, sampling, if configured correctly, will catch anything that is important. Anoop
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
