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

[<[e-mail]>]

Hi Tolga,

> Hi Jouni,
> 
> A bit off topic but one question below.
> 
> Thanks,
> Tolga
> 
> > 
> > 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).

That's typically done before gaining the access to the network.
The access network may for example use RFC4284 to advertise realms
or then some access technology specific way (like .11u, .16g etc).

I am not actually sure what you are after with your question 
related to capability exchange.

Cheers,
	Jouni


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