John, that’s not what I’m looking for. What I’m looking for is traffic statistics collected at transit nodes. These statistics should reveal the true end-to-end traffic demand within the MPLS domain. The collection of statistics shouldn’t add complexity. A low number of counters helps to simplify collection and post-processing.
If I’m not entirely wrong, this discussion at least partially discusses different ways how to define what kind of flow to account and where and how to capture related statistics. In that case I prefer a collection of a broader set of requirements and possible solutions. If our ongoing discussion doesn’t identify a set of useful options (I’m not sure whether all contributors to the discussion require the same here), a draft collecting different requirements and solutions may be helpful. Regards, Ruediger Von: John E Drake [mailto:[email protected]] Gesendet: Donnerstag, 16. November 2017 13:00 An: Geib, Rüdiger <[email protected]>; [email protected] Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Betreff: RE: [mpls] [spring] redux: Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths Ruediger, There is also the possibility of using a GAL w/ a new fixed size GACH containing the SR Segment List Id. This is similar to Robert’s suggestion of using a VXLAN header. Yours Irrespectively, John From: mpls [mailto:[email protected]] On Behalf Of [email protected]<mailto:[email protected]> Sent: Thursday, November 16, 2017 4:44 AM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [mpls] [spring] redux: Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths Adrian, to me, there’s no ideal solution. But an analysis may help to find a useful solution. There’s a need to collect traffic statistics also for packets which don’t follow the shortest end to end path. There’s no simple howto, I think. For the time being, I’d prefer not to add special labels to the stack. What other options are there? * Accounting at the router pushing a relevant label stack only. * Accounting of an n-label stack. * Acoounting of a subset of labels only (e.g. Node-SID Labels and Anycast-SID, but not ADJ-SID). The idea is a compromise to limit the number of counters be maintained. Consider accounting of the top 2 labels carrying global routing information. * A special label. Shradda proposes to put such a label into the stack. The labels present there prior to the addition are maintained. One might think about a single top label which identifies and replaces the label stack carrying routing information relevant for the path. That would simplify accounting, but it requires suitable IGP functionality. None of the options sounds simple. Are there more (and simpler) ones I didn’t come upon? Regards, Ruediger Von: spring [mailto:[email protected]] Im Auftrag von Adrian Farrel Gesendet: Donnerstag, 16. November 2017 06:35 An: 'Mach Chen' <[email protected]<mailto:[email protected]>>; 'Jeff Tantsura' <[email protected]<mailto:[email protected]>>; 'Robert Raszuk' <[email protected]<mailto:[email protected]>> Cc: 'draft-hegde-spring-traffic-accounting-for-sr-paths' <[email protected]<mailto:[email protected]>>; 'spring' <[email protected]<mailto:[email protected]>>; 'Zafar Ali (zali)' <[email protected]<mailto:[email protected]>>; 'mpls' <[email protected]<mailto:[email protected]>> Betreff: Re: [spring] [mpls] redux: Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths Let's unpick a couple of things... 1. This work is not talking about per-flow accounting, it is talking about peer SR-path accounting 2. ipfix on its own does not cut it because you still have to put a marker in the packets 3. Yes, SR assumes there is no (i.e. zero) state per SR-path in the network But this third point causes a tension: we want to use SR because it is good, but we want to do transit node diagnostics because (frankly) they are necessary. To get the full picture of why they are necessary read the draft, or consider ECMP. This discussion will not be unfamiliar to those who tried to debug LDP networks. Adrian
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
