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

[<[e-mail]>]

Hi Preeti,

> -----Original Message-----
> From: Preeti Shandilya [mailto:[e-mail]] 
> Sent: 11. joulukuuta 2007 6:19
> 
> Hi ! 
> 
> I am not sure why there is a requirement for subsequent 
> session oriented message to traverse the same intermediary 
> hops which the initial message has traversed. 

What if some of the intermediates are stateful and e.g.
collect charging data by tracking the user session?

Cheers,
	Jouni

> Ultimate requirement is that the session oriented message 
> should landup at the same destination host to which the first 
> message,  with respect to that session , has reached. As per 
> RFC the subsequent message shall have the destination host 
> embedded in the message. So irrespective of the path which 
> intermediary message follow, if it reaches to the same 
> destination node, everything shall work fine. 
> 
> Only requirement which is mandatory here is that response 
> message should follow the same route which request message 
> has traversed,  to have the correct entry of the hop-by-hop 
> Id. Also there need to be a mechanism so that mapping created 
> at the intermediary hops should be periodically deleted to 
> take care of the scenario of not receiving response from the 
> server ever. i.e If server responds to the resent request 
> from client (which follows the different path)  and original 
> request was never answered. 
> 
> Pardon, if I am missing something 
> 
> Regards,
> -Preeti 
> 
> 
> 
> "Asveren, Tolga" <[e-mail]> 
> 
> 12/11/2007 12:56 AM 
> To
> "Gil Shafran" <[e-mail]>, <[e-mail]> 
> cc
> Subject
> RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt
> 
> 	
> 
> 
> 
> 
> 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
> 
> 
> 
> 
> ***********************  Aricent-Restricted   *********************** 
> "DISCLAIMER: This message is proprietary to Aricent  and is 
> intended solely for the use of 
> the individual to whom it is addressed. It may contain 
> privileged or confidential information and should not be 
> circulated or used for any purpose other than for what it is 
> intended. If you have received this message in error, 
> please notify the originator immediately. If you are not the 
> intended recipient, you are notified that you are strictly
> prohibited from using, copying, altering, or disclosing the 
> contents of this message. Aricent accepts no responsibility for 
> loss or damage arising from the use of the information 
> transmitted by this email including damage from virus."
> 
> 

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