Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

[John E Drake <[e-mail]>]

Hi,

Comments inline

Yours Irrespectively,

John

From: spring [mailto:[e-mail]] On Behalf Of Zafar Ali (zali)
Sent: Saturday, November 18, 2017 1:12 AM
To: John E Drake <[e-mail]>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths <[e-mail]>; spring <[e-mail]>; mpls <[e-mail]>
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>