AW: Differentiated Routing, not only plain rambo-SPF

I am really surprised that the need for having several routing table is =
a big (scalability) issue:
(BTW:Logically it takes separate routing tables, one per DSCP. But you =
may as well maintain one routing table
 and search the next hop entry also based on the DSCP)

IMO stateless DiffRout-Forwarding is more scalable than MPLS or RSVP.

However,if the size of the routing table is an issue, then why wasn't =
it an issue so far:
Each ingress node needs to know the egress node before setting up the =
respective next hop entry in the routing table.
So why doesn't the IP header contain a field for the destination router =
address. It would allow to keep the routing tables
small: one single next hop entry w.r.t. each destination router would =
be sufficient.
Of course, it would be rediculous to expect any change in IPv4. But why =
wasn't this an issue for IPv6 ?
When IPv6 was born, I guess there have already been routing tables of =
respectful size.
Can anyone tell me?

Heinrich


-----Urspr=FCngliche Nachricht-----
Von: Naidu, Venkata [mailto:[email protected]]
Gesendet: Montag, 5. August 2002 21:33
An: 'Ayyasamy, Senthilkumar (UMKC-Student)'; Hummel Heinrich
Cc: [email protected]; [email protected]; [email protected];
[email protected]
Betreff: RE: Differentiated Routing, not only plain rambo-SPF


Senthil,

-> > There is no difference between MPLS-TE and=20
-> DiffServ-aware-MPLS-> TE? In other=20
-> > words, are you saying that Differv-aware-MPLS-TE=20
-> > is notgoing solve ANY problem that MPLS-TE alone couldn't=20
-> > solve ?
-> I was just talking about diffserv aware MPLS TE which is=20
-> more related to=20
-> the context of discussion. The authors of diffserv MPLS TE=20
-> draft discusses scalability problems.

  Yes! I am also talking about DiffServ-aware-MPLS-TE.
  In the draft-ietf-tewg-diff-te-reqts-05.txt authors
  clearly mentioned about problem statement and how we
  can benefit from DiffServ-aware-MPLS-TE (even if there
  are some scalability issues). Effectively, authors
  are trying to solve SOME problem - then how can=20
  you can say that DiffServ-aware-MPLS-TE (aka DiffRouting)
  is not going to solve ANY problem.

  Scalability issues in TOS Routing are different
  from scalability issues in DiffRouting (if you consider
  TOS routing is applicable in traditional hop-by-hop
  routing case and DiffRouting is applicable in todays
  source routing cases).

  Finally, let me conclude what I agree and disagree
  with you.

  What I agree:
  - None of these approaches [traditional TOS-Routing or
    DiffRouting (DiffServ-aware-MPLS-TE)] really solve
    end-to-end QoS/Performance. I already expressed this
    concern to Fred Baker (which he concluded that as
    an open ended question) - which is fine!
http://www1.ietf.org/mail-archive/working-groups/routing-discussion/curr=
ent/
msg00060.html

  - None of the above approaches are complete. They have
    some common and some different issues - for example
    scalability etc etc

  What I don't agree (my view):
  - Just because a solution has scalability issues doesn't
    mean that that solution is not going to solve ANY=20
    problem.

  - Diffserv-aware-MPLS-TE is trying to solve different problems
    which we couldn't solve with traditional routing approaches
    *easily* in the past.

  - We are trying to solve (we will solve) those scalability
    issues in source routing (using hierarchical TE etc etc)
    in future.

  Do you agree? If not let me know - let us discuss :)

  If you still feel that DiffRouting is not going to solve=20
  ANY problem then I will ask authors of=20
  draft-ietf-tewg-diff-te-reqts-05.txt (for clarification).
 =20
  Finally, you didn't tell me in what other approaches
  we can solve the same issues that the DiffServ-TE is
  trying to solve (with out letting control plane know,
  with out CSPF, with out connection-oriented MPLS etc etc).
 =20
--
Venkata
_______________________________________________
Irtf-rr mailing list
[email protected]
http://puck.nether.net/mailman/listinfo/irtf-rr