Thanks for helping me break my resolution to leave this thread alone :-( >>> procedure (in draft-hegde-spring-traffic-accounting-for-sr-paths) that >>> breaks SR >>> Architecture, highly unscalable and complicated to implement. >> >> [JD] Do you have any evidence to justify any of your assertions, above? > > Please note that in draft-hegde-spring-traffic-accounting-for-sr-paths: > > • The transit node needs to be able to recognize the special label, read > the SR Path Identification label and update the counter against such > “states”.
Possibly worth noting that existing devices are capable of maintaining many counters and updating them at line speed. Several people have noted that ipfix is a process used for accounting in networks. That approach may have to find the bottom of stack and then match the packet that follows. Other approaches (e.g., to ECMP) involve finding the bottom of stack and hashing on the header of the payload. Some hardware cannot perform either mechanism. This usually results from a trade between low cost, high performance, and features. Generally you can't have all three. That hardware can't perform transit accounting with fine granularity (although you have promised us a solution within the next four months). > • The draft proposes to push (up to) 3 Labels for each segment in the SR > Path. That means that label stack is increased up to 3x times! This is > a > serious a scaling issue. John asked for evidence and you provided a misunderstanding or misreading of our draft. The document proposes adding 2 or 3 labels per SR Path (noting as John did, that this is our own term). That is not what you say, so perhaps you could retract or provide a pointer to the text. Thus, "increased up to 3x times" applies only with the single case where the imposed label stack has exactly one label *and* the three label option is applied. So, while what you say is true, it is clearly (and wilfully?) exaggerating the severity of impact, and it is doubtful that 4-label stack is actually a problem. > • The controller needs to keep track of transit node capability and > push the additional per-path labels, accordingly. I.e., the controller > also needs to maintain such information for the transit nodes. In most cases, the controller/ingress only needs to care about the capabilities of the egress nodes. That is, if the special purpose label reaches the top of the stack it has to be able to handle it. The only time when the transit node issue arises is when there is a small RLD. That information may need to be known by the controller to enable correct ECMP behavior, and it is distributed in the IGP. If there is a desire to enable accounting at transit nodes with a small RLD then the Path ID can be inserted higher up the stack and *that* means that the controller has to be sensitive as to where in the network the special purpose label will rise to the top of the stack. It seems to me that: - Controllers are not particularly resource constrained: adding a flag per node (or even per link!) would not break any scaling behavior. - Adding another flag to the IGP alongside the RLD is not significant scaling issue. Cheer, Adrian _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
