Re: [Network-tokens] [arch-d] Questions for APN: Q#3 and Q#4

[[e-mail]]

Hi Shuping,


> APN doesn’t really introduce any change in any routing protocol. The goal is to be able to better classify packets and assign them to policies. How these policies are defined and operated are outside the scope of APN and rely on existing routing policy technology.


Then perhaps RTG is not appropriate.  Perhaps INT would be more to the point.

 
> Extension headers have been there for a while so I don’t believe that utilizing existing IPv6 extension headers could be considered as a “major change in the data plane”.


I await specifics. I infer that you want at least an order of magnitude increase in the scale of forwarding plane statistics. To my mind, that alone qualifies.


> Basically, in APN, the application data packets contains some bits in the header that will be used by the operator ingress devices in order to steer the packet into a pre-defined and installed policy (e.g. a traffic engineered path or a source routed path). The current state of routing protocols allow the provisioning, computation and installation of these policies without any additional change.


If the point is not additional control, then your needs seem to be focused on scale.  What granularity of detail are you anticipating and what is the resulting scale? I infer that DSCP is an inadequate mechanism, so what classification mechanism are you suggestiing? Or is are we trying to do full per-flow tracking? If so, what managerial mechanisms are you suggesting for offloading this? Current day telemetry is nowhere near this.


> Is there a discussion anywhere of the costs of this approach and a cost/benefit analysis? Have you considered the scalability of a solution?  What about the added complexity to the architecture? My apologies if I’ve missed something obvious.


I’ll renew these questions as you haven’t addressed them.

Tony

p.s. I agree with Christian.