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

["Asveren, Tolga" <[e-mail]>]

Hi Gil,

I think explicit routing issue is more related with visited network
(actually any network) trying to make sure that messages for a session
traverse some of the intermediaries, which were used during routing of
the initial request for that particular session. I don't see this
mechanism as the originator of the session enforcing a path
(potentially/partly in another network) before the session is
established. BTW, intermediaries which do not want to stay on the path
don't need to participate.

A network with all elements stateful won't have an issue but here the
key point is that *all* elements should have the intelligence to select
the same next-hope for all requests of a particular session.

 Thanks,
 Tolga

> -----Original Message-----
> From: Gil Shafran [mailto:[e-mail]]
> Sent: Monday, December 10, 2007 1:06 PM
> To: [e-mail]
> Subject: Re: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt
> 
> 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,  <[e-mail]> 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
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/dime
> >
> 
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dime