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

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

Hi Jouni,

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Monday, December 10, 2007 4:49 PM
> To: Asveren, Tolga; [e-mail]
> Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt
> 
> 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.
[TOLGA]I was wondering how this would work from Diameter capability
negotiation perspective:
a) Does the NAP need to advertise support for certain application for
different domains? 
b) Or does it use a different Diameter identity for each domain?
c) Or do the clients assume that NAP provides access for all possible
domains?

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