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

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

Hi Jouni,

A bit off topic but one question below.

Thanks,
Tolga

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Monday, December 10, 2007 4:07 PM
> To: [e-mail]; [e-mail]
> Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt
> 
> Hi Gil,
> 
> The functionality referenced earlier was actually requested
> by operators to enable some of their potential roaming and
> deployment scenarios. "Forcing" next hop is, for example,
> for deployments where a shared NAP advertises a number direct
> roaming connections for realms (say A.com, B.com and C.com) but
[TOLGA]How does this advertisement work? Capability exchange mechanism
does not have that type of capability(i.e. advertising application
support per realm).
> none of them match to roaming user's home realm (say D.com).
> However, the roaming user knows that B.com has an agreement
> with D.com, thus it asks from NAP for an "authentication route"
> to D.com through B.com. After this all subsequent messages
> should take the same path (either on realm or actual agent
> granularity depending on the deployment).
> 
> Cheers,
> 	Jouni
> 
> 
> 
> > -----Original Message-----
> > From: Gil Shafran [mailto:[e-mail]]
> > Sent: 10. joulukuuta 2007 20:06
> > 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

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