RE: Differentiated Routing, not only plain rambo-SPF

"Ayyasamy, Senthilkumar (UMKC-Student)" <saq66@umkc.edu> Tue, 06 August 2002 00:41 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 UAA09297 for <routing-discussion-archive@odin.ietf.org>; Mon, 5 Aug 2002 20:41:52 -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 UAA09667; Mon, 5 Aug 2002 20:36:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA09637 for <routing-discussion@optimus.ietf.org>; Mon, 5 Aug 2002 20:36:16 -0400 (EDT)
Received: from kc-msxproto4.kc.umkc.edu (kc-msxproto4.kc.umkc.edu [134.193.143.48]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09125 for <routing-discussion@ietf.org>; Mon, 5 Aug 2002 20:35:04 -0400 (EDT)
Received: from KC-MAIL2.kc.umkc.edu ([134.193.143.162] RDNS failed) by kc-msxproto4.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.4905); Mon, 5 Aug 2002 19:36:16 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: Differentiated Routing, not only plain rambo-SPF
Date: Mon, 05 Aug 2002 19:36:15 -0500
Message-ID: <A29143A40AEAE3459FF829D1DD4331613C252A@KC-MAIL2.kc.umkc.edu>
Thread-Topic: Differentiated Routing, not only plain rambo-SPF
Thread-Index: AcI8tw/6mhAKwU3bQ0C8tvoQga4Q+wAI3MbQ
From: "Ayyasamy, Senthilkumar (UMKC-Student)" <saq66@umkc.edu>
To: "Naidu, Venkata" <Venkata.Naidu@marconi.com>, 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
X-OriginalArrivalTime: 06 Aug 2002 00:36:16.0169 (UTC) FILETIME=[46214990:01C23CE1]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA09638
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 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.
Diffserv aware MPLS TE draft doesn't call for bar on SPF. But
you people are keeping that as a subject and discussing.

Some of the definitions and road examples of diffrout doesn't fit 
the bill of diffserv aware MPLS TE. 

As of now, whatever techniques standardized by TE-WG, is applicable
only for intra-domain (including diffserv-aware TE.) But read some 
of your mails, you talk about end to end issues.

Do you get your problem now? If you are not clear with your problem
statement, you will tent to make deviating observations.

If Diffserv-aware-MPLS-TE = diffrout, I am in full agreement with some 
of your views. But remember again, you made some comments about end to end 
delay issues which even Faucheur et all won't accept. 

Hummel, was your original proposal same like Diffserv-aware-TE. I thought
it was different.


> 
>   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).

Yup ..its different. you have used some of the ToS routing 
conclusions for claiming diffrout scheme and hence, i made that
comment regarding scalability. 


>  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.

Sorry for making such a statement. But you should also agree 
that, you did not still clearly state *why we need diffrout?*

>  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).
First of all control plane work in Diffserv is incomplete. 
what you want to do with *diffrout*-QoS-Routing, sneak-around 
the congestion-area routing, and traffic balanced routing.

Let me suggest you a simple technique: Use *explicit routing* of
MPLS which is the simplese one for doing sneaking around work.

Doing dynamic QoS routing is very difficult and operators 
generally dont prefer. But this is surely not a good argument :-).
i will support diffrout if you just explain me *why we need 
diffrout*. I am reading all the 14 mails regarding diffrout but 
still couldn't get a correct problem statement.

In the corner, I am too advocating a new idea which is  contradictory
to diffrout. By taking SPF into account, an effective load balancing 
can be done in diffserv architecture. I will get back to you once i get 
done with an analytical model.


  

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