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 10:47
> 
> Hi Jouni ! 
> 
> As per RFC, relay node should not even look into the 


Should have said that I meant proxy there.

/Jouni


> 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