Hi Heiner,
Thank you very much for commenting.
> 3.1. Improved routing scalability
> It lacks naming the two aspects in the first place: memory consumption and
> CPU-performance (update churn). Only thereafter it makes sense to request
> independency from the internet user population. Why is the control plane
> mentioned specifically? I don’t understand. It is neither necessary nor
> correct.
The control plane subsumes the memory, bandwidth and CPU required for routing,
both within individual systems and network-wide. We distinguish from the data
plane, which is the transit traffic. There are similar scalability issues in
the data plane, but the argument there is much more challenging to make and is
not widely accepted.
> 3.2. Scalable support for traffic engineering
> Bad English: The solutions should also be scalable also wrt detouring routes.
> ( and not wrt to traffic engineering).
By detour routes, I'm assuming that you're talking about FRR and similar
technologies. This would seem to be an independent issue and I don't think we
have any agreement that this is an inter-domain issue.
> 3.3. Scalable support for multi-homing
> It wouldn’t be bad to mention that multi-homing is just a particular aspect
> of multipath.
Sorry, I'm not seeing your point. Does multi-path support affect our design
goals?
> 3.4. Scalable support for mobility
> We should also mention support of PRIVACY (where is the roaming user at this
> moment). Privacy can always be supported (i.e. by any solution) by employing
> a home agent who will or who will not relay. We may need to deal with both
> options. The current text fosters the belief that some solution
> may provide both concurrently.
Agreed. Added a comment:
"Mechanisms that help to provide more
efficient and scalable mobility support are desired, especially
when they can be coupled with security, _especially privacy_, and
support topological changes at a high-rate."
> 3.5. Simplified renumbering
> The best of all is not mentioned: solutions which do not require any
> renumbering.
Fair enough. Added.
> 3.6. Decoupling location and identification
> I have strong doubts that this community has fully understood what
> loc/id-split may mean.
This doesn't seem like a document where we should be educating them.
> 3.7. First-class elements
> Half of this paragraph is used to explain this weir headline.
> What is really intended here, should be expressed simpler and without this
> climbim.
Please propose text. I realize that my background is unique, but I know of no
better way to accurately and concisely describe this in polite and professional
language. Saying that "the architecture can't be a kludge" or "no cheesy
hacks" doesn't seem to be appropriate. ;-)
> 3.8. Routing quality
> A lot of words in order to get to the term “stretch”.
> I have my own suspicion why this term had been invented (and why it has been
> adopted). I can imagine that routing quality may also mean different aspects
> (QoS,…)
If you would care to propose text, I would be happy to replace the current
definition. This is taken from the academic literature, where they wanted a
metric to evaluate routing quality. Personally, I don't consider it to be a
very practical measure, as it ignores policy and the granularity is poor. A
stretch of 2 is simply disastrous.
> 3.9. Routing security
> No comment to this place holder phrase.
Your sarcasm is not constructive. If you dislike the content, please propose
alternate text.
> 3.10. Deployability
> The first sentence can be deleted (blabla only).
> Any solution which required a flag day is out from the beginning.
> Yes, incremental deployability is definitely required.
> However, I think that ALL solutions can provide this (all the so far
> displayed as well as all not-yet born solutions:-)
Clearly, this is not the case. It is very clear that one can propose a
solution that there are non-deployable flag-day solutions. While they are not
going to fall into anyone's definition of common sense, it is incumbent on us
to be clear about the requirements anyway. In fact, in the past, this was a
significant point of discussion.
> Furthermore I miss 3.11:
> The solution should also enable Moore's Law as addressed in RFC4984
I'm sorry, I don't understand your point. As has been argued in 4984, Moore's
Law is not the only constraint that we must work with. DRAM latency, for
example, is NOT subject to Moore's Law. Care to propose text?
Regards,
Tony
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
