Senthil & Shen,
-> HH:> There is never a free lunch. But what are a view routing
-> tables compared to the probably much bigger number
-> of p2p LSPs?
You told/questioned about theoretical correctness of
DiffRouting approach. Let me tell you in what direction
we are moving (practically).
If you put together everything what is happening in
IETF WGs you will see that "indirectly" we are doing
DiffRouting. Believe me...read on...
Read this simple draft [in IESG last call]
http://www.ietf.org/internet-drafts/draft-ietf-tewg-te-metric-igp-00.txt
This draft suggest to use 2 IGP metrics (right now
1 in IGP Hop-by-Hop topology info and another in
IGP-TE info) efficiently to do QoS routing.
1 metric for Data and another metric for voice.
What is this finally boil down to - If I provide
this feature to SPs, think, how are they going to
use this in DiffServ domain?
Simply, SPs can map 2 different services [example,
2 different CoS-types] to these different metrics.
Effectively we *are* doing DiffRouting...previously
there is no name for it...(and we are getting panicked
that we are facing a new/unresovable/performace
implicated problem here).
To extend the idea more (from 2 metrics to n metrics)
please read draft-fedyk-isis-ospf-te-metrics-01.txt.
I discussed this with Francois, he said, the above
draft also is going to get into DiffServ-aware-TE problem
space.
Look at this way, DiffServ-Aware-TE is more than
DiffRouting. DiffRouting is just a subset of what we
are solving right now.
-> But the problem is routers have to maintain all information
-> about DSCP they support and propagate them.
Shen, yes we are flooding all the information about DSCP
*indirectly*.
-> 1. The diffserv architecture, as of now, defines only
-> the data plane work. control plane activities( routing,
-> signaling etc) are still open questions.
With recent changes in TE-WG and MPLS, control plane
is now aware of DiffServ-Aware-TE. Read...
http://www.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-proto-01.txt
-> Thus said, coming with a new scheme is not a big task,
-> problem space and applicability statement is very
-> important.
I agree.
-> I am not asking you to formulate diffrout as an increment
-> to SPF but just enlighten us *problem* and *need* of
-> diffrout.
As a layman (problem statement & need):
"I (end-user) will be very happy if my voice call over IP
performs atleast as good as over POTS (proportional to
what I pay as monthly charges)"
As a technical person (problem statement):
- Quality of Service to End User
- End-to-end performance
- Efficient use of Resources
- Congestion Avoidance & Control
...
How are you going to solve above problems with out using
DiffServ-Aware-TE (aka DiffRouting)? I am very glad
to know your *solution*:
- with out letting control plane know
- with out propagation DSCP info (directly/indirectly)
- with just using SPF (with out CSPF)
- with out using MPLS
. . .
Thank you.
-- Venkata.
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT