Hi, Comments inline
Yours Irrespectively, John From: spring [mailto:[email protected]] On Behalf Of Zafar Ali (zali) Sent: Saturday, November 18, 2017 1:12 AM To: John E Drake <[email protected]> Cc: draft-hegde-spring-traffic-accounting-for-sr-paths <[email protected]>; spring <[email protected]>; mpls <[email protected]> Subject: Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths Hi John, Sorry for delay in the response; I was away from the emails. Please see in-line. Thanks Regards … Zafar <snip> <snip> 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”. [JD] I think I mentioned in a previous email that this is the type of capability used by RSVP-TE LSPs since the advent of MPLS • 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. [JD] Um, no. Two or three labels per SR segment list (aka MPLS label stack) • 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. [JD] Absolutely not, whatever gave you that idea? If a transit node understands the labels it can maintain and report the counters, otherwise it doesn’t, but the controller doesn’t need to know this a priori. <snip>
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
