Re: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt

"Gil Shafran" <gshafran@traffixsystems.com> Mon, 10 December 2007 18:05 UTC

Return-path: <dime-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1n0n-0005Nc-Qq; Mon, 10 Dec 2007 13:05:49 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1n0m-0005NW-Nh for dime@ietf.org; Mon, 10 Dec 2007 13:05:48 -0500
Received: from nz-out-0506.google.com ([64.233.162.226]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1n0m-0002ac-21 for dime@ietf.org; Mon, 10 Dec 2007 13:05:48 -0500
Received: by nz-out-0506.google.com with SMTP id n1so606375nzf for <dime@ietf.org>; Mon, 10 Dec 2007 10:05:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=4fo+hnthTq9QLI5/QSXebYuBK6RV0KJEv5toyjpQZgk=; b=eCtXhJTKzbNDWL1TK2vUJQpdWjzm5qgvvory/diwRktvLr46FIk9wIyMpl6s6yUVezCEnSn4by/NuG/bULQKiMuGK1qBKXc1L6mE8ep5Gi/YDJJbj0LYwMIYY9DwzxE2gy35v4laT8tHPTE+GROZDAYgB1g66YQSgunTP1S2nnY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=HYYQGsTOAYDKmBsELYjvTWh1jiEDCvxpX2SgfATseqAvhBedSqU3/W29qVY+BpIqpoJg4aKIWMuRaNtmQx50UFRLv7O4IrSONwBNlKTbqepuBgnzgS+OojPx3OOYM34awRYiXWXRulI4kC7mecRvfD6pttZlrAA8PS+lRVZ9lp4=
Received: by 10.142.165.9 with SMTP id n9mr629621wfe.1197309942480; Mon, 10 Dec 2007 10:05:42 -0800 (PST)
Received: by 10.142.194.16 with HTTP; Mon, 10 Dec 2007 10:05:42 -0800 (PST)
Message-ID: <e73a13320712101005l3b2d3e31r69fdfae70b1e40fa@mail.gmail.com>
Date: Mon, 10 Dec 2007 20:05:42 +0200
From: Gil Shafran <gshafran@traffixsystems.com>
To: dime@ietf.org
Subject: Re: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt
In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9C38@SEHAN021MB.tcad.telia.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4757153B.2060802@gmx.net> <59D7431DE2527D4CB0F1EFEDA5683ED3024F9C38@SEHAN021MB.tcad.telia.se>
X-Google-Sender-Auth: e7c4d11f5abdd776
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi all,

IMHO, visited network clients should not force an explicit routing in
network domains of other operators. I believe operators would prefer
to fully control their load balancing and routing issues. They can
also assure routing through their own stateful Diameter proxies. Using
the existing Diameter routing definitions (RFC 3588), an operator has
only rough knowledge and control (destination realm) over other
networks, which is a good modular model.

Regards,
Gil


On Dec 6, 2007 9:20 PM,  <jouni.korhonen@teliasonera.com> wrote:
> Hannes,
>
> Few comments inline.
>
> [snip]
>
> > >   [Tina: There is Relay Agent in Diameter routing path, at
> > the same time, in the case it has relative many next hop
> > nodes, routing probably changes.
> > >
> > Do we have these types of Diameter deployments already that
> > have so many hops?
>
> Do we have large deployments in general that have inter-operator
> interfaces? At this stage requiring deployment experience is
> kinda weird. I mean, there are identified issues slash grey
> areas, so why not study and document those before we hit them
> in real deployments?
>
> > >   It is because that the Diameter Relay Agent is likely to
> > select the next hop node by random.
> > >
> > Hmmm. Probably this is then the problem. We then shouldn't
> > develop protocol extensions but rather write a document that
> > indicates what good design for Relay Agents is.
>
> IMHO that still does not make the issue go away.
>
> [snap]
>
> > >   Do we have some real-world data indicating that this is
> > indeed a problem
> > >   rather than an academic exercise?
> > >   [Tina: Here are some application with stateful Proxy
> > Agent in 3GPP and ETSI TISPAN. I think that if there is
> > stateful Proxy Agent, such mechanism is needed.
> > >   [TS23.234]
> > >                 3GPP, "3GPP system to Wireles Local Area
> > Network (WLAN)
> > >                 interworking; System description", 3GPP TS
> > 23.234 Version
> > >                 7.4.0 2006.
> > >   Here, 3GPP AAA Proxy is a stateful Proxy Agent.
>
> [chop]
>
> > I was told that there was a discussion in the 3GPP once about
> > this aspect. The WLAN 3G interworking was done a long time
> > ago and we have never heard back from them.
>
> Heard back what? In 3GPP routing etc is again under discussion
> in rel-8 timeframe. Coming back to above reference, the same
> family of scary specs also use NAI decoration based source
> routing as part of NASREQ & EAP application for selecting the
> next hop. I cannot find this (might be a result of sloppy reading)
> feature being described anywhere in Diameter specification thus I
> suspect it will actually work. Or can we just assume that everything
> defined in RFC4282 gets reflected back to existing applications?
>
> > I would like to hear from an operator that they have a large
> > Diameter network and that issue turned out to be a problem. I
> > would also be happy to hear from vendors what they do. I will
> > certainly investigate this issue with vendors and operators.
>
> Rather ask.. "an operator that have a large Diameter network
> with inter-operator interfaces in multi-vendor environment" ;)
>
>
> Cheers,
>        Jouni
>
>
> >
> >
> > Ciao
> > Hannes
> >
> > >   Ciao
> > >   Hannes
> >
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
>

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime