AW: Differentiated Routing, not only plain rambo-SPF

Hummel Heinrich <Heinrich.Hummel@icn.siemens.de> Tue, 06 August 2002 07:40 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28436 for <routing-discussion-archive@odin.ietf.org>; Tue, 6 Aug 2002 03:40:57 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA09637; Tue, 6 Aug 2002 03:31:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA09598 for <routing-discussion@optimus.ietf.org>; Tue, 6 Aug 2002 03:31:34 -0400 (EDT)
Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28159 for <routing-discussion@ietf.org>; Tue, 6 Aug 2002 03:30:19 -0400 (EDT)
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id JAA29369; Tue, 6 Aug 2002 09:31:28 +0200 (MET DST)
Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id JAA21703; Tue, 6 Aug 2002 09:31:30 +0200 (MET DST)
Received: by MCHH274E with Internet Mail Service (5.5.2656.59) id <P83CGKP6>; Tue, 6 Aug 2002 09:31:14 +0200
Message-ID: <EF8E39AA846CD411BB9C00508B951F510514B984@MCHH267E>
From: Hummel Heinrich <Heinrich.Hummel@icn.siemens.de>
To: "'Naidu, Venkata'" <Venkata.Naidu@marconi.com>, "'Ayyasamy, Senthilkumar (UMKC-Student)'" <saq66@umkc.edu>, Hummel Heinrich <Heinrich.Hummel@icn.siemens.de>
Cc: jnc@ginger.lcs.mit.edu, fred@cisco.com, irtf-rr@puck.nether.net, routing-discussion@ietf.org
Subject: AW: Differentiated Routing, not only plain rambo-SPF
Date: Tue, 06 Aug 2002 09:31:11 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA09599
Sender: routing-discussion-admin@ietf.org
Errors-To: routing-discussion-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Routing Area General mailing list <routing-discussion.ietf.org>
X-BeenThere: routing-discussion@ietf.org
Content-Transfer-Encoding: 8bit

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üngliche Nachricht-----
Von: Naidu, Venkata [mailto:Venkata.Naidu@Marconi.com]
Gesendet: Montag, 5. August 2002 21:33
An: 'Ayyasamy, Senthilkumar (UMKC-Student)'; Hummel Heinrich
Cc: jnc@ginger.lcs.mit.edu; fred@cisco.com; irtf-rr@puck.nether.net;
routing-discussion@ietf.org
Betreff: RE: Differentiated Routing, not only plain rambo-SPF


Senthil,

-> > There is no difference between MPLS-TE and 
-> DiffServ-aware-MPLS-> TE? In other 
-> > words, are you saying that Differv-aware-MPLS-TE 
-> > is notgoing solve ANY problem that MPLS-TE alone couldn't 
-> > solve ?
-> I was just talking about diffserv aware MPLS TE which is 
-> more related to 
-> the context of discussion. The authors of diffserv MPLS TE 
-> 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 
  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/current/
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 
    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 
  ANY problem then I will ask authors of 
  draft-ietf-tewg-diff-te-reqts-05.txt (for clarification).
  
  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).
  
--
Venkata

_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org
https://www1.ietf.org/mailman/listinfo/routing-discussion