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

[Preeti Shandilya <[e-mail]>]

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