Hi John, if network doesn't use payload information to handle ECMP then performance measurement using RFC 8169-style or pure active OAM based on RFC 6374 will certainly work. But if it is DPI-based hashing for ECMP, then there cannot be guarantee that packets with GAL/G-ACh follow the same path as regular packets. Of course, one can use GAL/G-ACh encapsulation as a tunnel, as normal case and then do any sort of measurements.
Regards, Greg On Thu, Nov 16, 2017 at 7:59 PM, John E Drake <jdr...@juniper.net> wrote: > 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:mpls-boun...@ietf.org] *On Behalf Of * > ruediger.g...@telekom.de > *Sent:* Thursday, November 16, 2017 4:44 AM > *To:* adr...@olddog.co.uk > *Cc:* draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org; > spring@ietf.org; rob...@raszuk.net; m...@ietf.org; z...@cisco.com > *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:spring-boun...@ietf.org <spring-boun...@ietf.org>] *Im > Auftrag von *Adrian Farrel > *Gesendet:* Donnerstag, 16. November 2017 06:35 > *An:* 'Mach Chen' <mach.c...@huawei.com>; 'Jeff Tantsura' < > jefftant.i...@gmail.com>; 'Robert Raszuk' <rob...@raszuk.net> > *Cc:* 'draft-hegde-spring-traffic-accounting-for-sr-paths' < > draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>; 'spring' < > spring@ietf.org>; 'Zafar Ali (zali)' <z...@cisco.com>; 'mpls' < > m...@ietf.org> > *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 > > > > _______________________________________________ > mpls mailing list > m...@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
