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

[Preeti Shandilya <[e-mail]>]

Hi Jouni !

As per RFC, relay node should not even look into the message(except the 
routing AVPs). So intermediary nodes should not try  to collect charging 
data by tracking the user session. If this is the case, this would be 
against the spec

As per definition of relay agent from RFC 3588

      "Relays forward requests and responses based on routing-related
      AVPs and realm routing table entries.  Since relays do not make
      policy decisions, they do not examine or alter non-routing AVPs.
      As a result, relays never originate messages, do not need to
      understand the semantics of messages or non-routing AVPs, and are
      capable of handling any Diameter application or message type."

regards
Preeti



<[e-mail]> 
12/11/2007 12:13 PM


To
Preeti Shandilya/HSS@HSS, <[e-mail]>
cc
<[e-mail]>, <[e-mail]>
Subject
RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt






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



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