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

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 05 Dec 2007 22:16:43 +0100

Hi Tina,

I just noticed that you replied to my mail.
Please find further comments below:

Tina TSOU wrote:
> Dear Hannes,
> Thank you for your review:)
> Please see my comments in line demarked as [Tina: ...].
>
> B. R.
> Tina
> --------------------------------------------------------
> Mondays aren't so bad; and pigs have wings...
>   ----- Original Message ----- 
>   From: Hannes Tschofenig 
>   To: [email-masked] 
>   Sent: Sunday, November 25, 2007 5:57 PM
>   Subject: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt
>
>
>   I read through 
>   http://tools.ietf.org/wg/dime/draft-tsou-dime-base-routing-ext-03.txt
>
>   At this point in time I only have high-level comments.
>
>   I am not sure about the usefulness of the proposed mechanism. In some 
>   sense you dynamically establish an explicit route based on the initial 
>   routing of the message. Then, this information is used for subsequent 
>   messages. When something changes along the path then a new route is 
>   being "established" and cached by the originator.
>
>   Diameter routes do not regularly change. If they change then there is a 
>   good reason (e.g., failure of a node).
>   This mechanism only seems to be useful for the cases where Diameter 
>   routes change because of some irrelevant reason but routing through the 
>   explicit path would still be possible.
>   [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?

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

>   In Diameter Base Protocol, usually when session starts, the Destination-Host is not appointed. Only the Destination-Realm is appointed. However,
>   The subsequent requests in the session need to appoint Destination-Host to assure it is routed to the same server, as the routing may changes.
>   And the mechanism define by this protocol, is to assure that it is routed to the intermediate stateful Proxy Agent.]
>   
I agree that the issue sounds like a logical thing todo.
I do, however, wonder whether this is going to be an issue in real issue.

>   Is there some evidence that the proposed mechanism would actually be 
>   helpful?
>   [Tina: Please look at the "Figure 1: Generic Stateful Proxy Problem" in draft-tsou-dime-base-routing-ext-03.txt.
>   After a Diameter Relay Agent, there are two stateful Proxy Agents.
>
>                 VISITED NETWORK     |    HOME NETWORK
>                                     |
>         +--------+     +--------+   |   +--------+
>         | Client |<--->| Relay1 |<----->| Proxy1 |
>         +--------+     +--------+   |   +--------+\
>                                  \  |              \+-------------+
>                                   \ |               | Home Server |
>                                    \|              /+-------------+
>                                     \   +--------+/
>                                     |---| Proxy2 |
>                                     |   +--------+
>
>   ]
>
>   
Your proposal only helps if the Relay does random routing. I do, 
however, doubt that this is true.

>   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.
>
>
>   RES/TISPAN-02045-NGN-R2  V0.0.5 
>   ETSI Standard
>   Telecommunications and Internet converged Services and
>   Protocols for Advanced Networking (TISPAN);
>   NGN Functional Architecture;
>   Network Attachment Sub-System (NASS)
>
>   Here, in Visited NGN Network, the UAAF, CLF are also in this case.
>   ]
>   
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.

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.

Ciao
Hannes

>   Ciao
>   Hannes
>
>
>   _______________________________________________
>   DiME mailing list
>   [email-masked]
>   https://www1.ietf.org/mailman/listinfo/dime
>
>   

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

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 5 Dec 2007 16:36:04 -0500

Hi Hannes,

> however, doubt that this is true.
I think we have two issues related with this:

1) That relays should route messages for the same session always to the
same next hop is not mandated. It definitely is preferable to loadshare
traffic somehow, and a basic round-robin loadsharing could lead messages
of a single session to be sent to different entities.

2) It is preferable for the relays to be stateless from efficiency
perspective (and we also do not want to synchronize state between
relays). One way of doing "consistent routing" is running some type of
hash function on Session-Id to determine the next hop, but this also has
its challenges if the set of next hops change.

In Section 1.2 of the draft, there is some discussion about possible
workarounds with existing mechanisms.

Thanks,
Tolga

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Wednesday, December 05, 2007 4:17 PM
> To: Tina TSOU
> Cc: [email-masked]
> Subject: Re: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt
> 
> Hi Tina,
> 
> >   Diameter routes do not regularly change. If they change then there
is
> a
> >   routes change because of some irrelevant reason but routing
through
> the
> >   [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.
> >   It is because that the Diameter Relay Agent is likely to select
the
> next hop node by random.
> >   In Diameter Base Protocol, usually when session starts, the
> Destination-Host is not appointed. Only the Destination-Realm is
> appointed. However,
> >   The subsequent requests in the session need to appoint
Destination-
> Host to assure it is routed to the same server, as the routing may
> changes.
> >   And the mechanism define by this protocol, is to assure that it is
> routed to the intermediate stateful Proxy Agent.]
> >
> >   [Tina: Please look at the "Figure 1: Generic Stateful Proxy
Problem"
> in draft-tsou-dime-base-routing-ext-03.txt.
> >   [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.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 05 Dec 2007 23:02:14 +0100

Hi Tolga,

> of a single session to be sent to different entities.
The question is how relays route messages. If your deployment wants to 
route Diameter messages differently per-session AND you are concerned 
about the consequences then why do you put a stateless agent in there in 
the first place.

> its challenges if the set of next hops change.
I agree that you would want to have stateless routing.
However, on the other hand here you seem to also want to
* route messages as you want (almost randomly)
* and at the same time ensure that the Diameter messages of a specific 
session is routed along the same path.

I appreciate the text in Section 1.2.
For example, Section 1.2.1 indicates that you have to have stateful 
proxies along the entire path.
That's not necessary. You only need to have them at places where it 
really matters.
 
Ciao
Hannes

>>>   I am not sure about the usefulness of the proposed mechanism. In
>>>       
> some
>   
>>>   sense you dynamically establish an explicit route based on the
>>>       
> initial
>   
>>>   routing of the message. Then, this information is used for
>>>       
> subsequent
>   
>>>   messages. When something changes along the path then a new route
>>>       
> is
>   
>>>   This mechanism only seems to be useful for the cases where
>>>       
> Diameter
>   
>> Do we have these types of Diameter deployments already that have so
>>     
> many
>   
>> hops?
>>
>>     
>> protocol extensions but rather write a document that indicates what
>>     
> good
>   
>> I do, however, wonder whether this is going to be an issue in real
>>     
> issue.
>   
>>>   Is there some evidence that the proposed mechanism would actually
>>>       
> be
>   
>>>   helpful?
>>>   Do we have some real-world data indicating that this is indeed a
>>>       
>> problem
>>     
>>>                 3GPP, "3GPP system to Wireles Local Area Network
>>>       
> (WLAN)
>   
>>>                 interworking; System description", 3GPP TS 23.234
>>>       
>> Version
>>     
>>>                 7.4.0 2006.
>> network and that issue turned out to be a problem. I would also be
>>     
> happy
>

---

From: Tony Zhang <[email-masked]>
Date: Thu, 06 Dec 2007 19:18:02 +0800

Hi:
>about the consequences then why do you put a stateless agent in there in 
If just Use Diameter base protocol routing procedure ,the client also should face the problem when the next hop have many statefule agent. below deployment.
                 VISITED NETWORK     |    HOME NETWORK
                                     |
         +--------+                  |    +--------+
         | Client |<------------\-- ----->| Proxy1 |
         +--------+              \    |   +--------+\
                                  \  |              \+-------------+
                                   \ |               | Home Server |
                                    \|              /+-------------+
                                     \   +--------+/
                                     |---| Proxy2 |
                                     |   +--------+

The another problem,any network node should not care about the network how to deployment.it should use same routing procedure for meet any network case.

Tony.
-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Thursday, December 06, 2007 6:02 AM
To: Asveren, Tolga
Cc: [email-masked]
Subject: Re: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt

Hi Tolga,

 
Ciao
Hannes

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 6 Dec 2007 13:45:21 -0500

Hi Hannes,

> Sent: Wednesday, December 05, 2007 5:02 PM
> To: Asveren, Tolga
> Cc: Tina TSOU; [email-masked]
[TOLGA]There are different use cases for intermediaries. For example, an
intermediary which is performing some level of policing may need to be
stateful. OTOH, a node whose purpose is to loadbalance does not really
need to be stateful. It is possible to have these two types of
intermediaries in the same network and this is what creates the problem
case.
> That's not necessary. You only need to have them at places where it
[TOLGA]If one has a mix of staful and steles entities, there is no
guarantee that the right stateful entity will get all of the messages
for a particular session, because stateless entities may select the next
hop quite randomly. Based on existing specification, the solution seems
to be to make all entities stateful (hashing is promising but seems to
fall short providing a full stateful solution).
> >>>                                  \  |
\+-------------+
> >>>                                   \ |               | Home Server
|
> >>>                                    \|
/+-------------+

---

From: <[email-masked]>
Date: Thu, 6 Dec 2007 20:20:43 +0100

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?

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

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

[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

---

From: "Gil Shafran" <[email-masked]>
Date: Mon, 10 Dec 2007 20:05:42 +0200

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

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 10 Dec 2007 14:26:25 -0500

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

> From: Gil Shafran [mailto:[email-masked]]
> Sent: Monday, December 10, 2007 1:06 PM
> To: [email-masked]

---

From: <[email-masked]>
Date: Mon, 10 Dec 2007 22:07:23 +0100

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

> Sent: 10. joulukuuta 2007 20:06
> To: [email-masked]
> 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 
> > > the same time, in the case it has relative many next hop nodes, 
> > > routing probably changes.
> > > >
> > > many hops?
> > 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?
> >
> > > good design for Relay Agents is.
> >
> > > Agent in 3GPP and ETSI TISPAN. I think that if there is stateful 
> > > Proxy Agent, such mechanism is needed.
> > > >   [TS23.234]
> > > 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?
> >
> > > 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
> > >
> >

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 10 Dec 2007 16:15:04 -0500

Hi Jouni,

A bit off topic but one question below.

Thanks,
Tolga

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Monday, December 10, 2007 4:07 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt
> 
> Hi Gil,
> 
[TOLGA]How does this advertisement work? Capability exchange mechanism
does not have that type of capability(i.e. advertising application
support per realm).

---

From: <[email-masked]>
Date: Mon, 10 Dec 2007 22:48:54 +0100

Hi Tolga,

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

Cheers,
	Jouni

> > However, the roaming user knows that B.com has an agreement with 
> > D.com, thus it asks from NAP for an "authentication route"
> should take 
> > the same path (either on realm or actual agent granularity 
> depending 
> > on the deployment).
> > 
> > Cheers,
> > 	Jouni
> > 
> > 
> > 
> > > 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
> > >
> > >

---

From: Preeti Shandilya <[email-masked]>
Date: Tue, 11 Dec 2007 09:48:54 +0530

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" <[email-masked]> 
12/11/2007 12:56 AM

To
"Gil Shafran" <[email-masked]>, <[email-masked]>
cc

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

Hi Gil,

 Thanks,
 Tolga

***********************  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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: <[email-masked]>
Date: Tue, 11 Dec 2007 07:43:43 +0100

Hi Preeti,

> From: Preeti Shandilya [mailto:[email-masked]] 
> 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. 
> 
> routing in
> 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."
> 
>

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 10 Dec 2007 23:58:02 -0800

...

[gwz] 
I must admit that I cannot think of a single (real-life) scenario where this
kind of thing would be desirable (let alone required).  Would you mind
describing one in detail?
[/gwz]
 
...

---

From: Preeti Shandilya <[email-masked]>
Date: Tue, 11 Dec 2007 14:17:23 +0530

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

<[email-masked]> 
12/11/2007 12:13 PM

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

Hi Preeti,

Cheers,
                 Jouni

---

From: Tina TSOU <[email-masked]>
Date: Tue, 11 Dec 2007 17:02:38 +0800

Dear Glen and all,
I know Jouni has two use cases. Jouni, Steve and I talked about them in Vancouver. I am trying to describe as below. If it is not precise, Jouni, please correct me.

Use case #1:
There are several visiting network, and one home network. 
Type 1# service should go via intermediate node #a in visiting network A#.
Type 2# service should go via intermediate node #b in visiting network B#.
......
This use case can be for both mobile and fix network operator.

Use case #2:
The charging data should be sent from that node.

This use case can be for mobile operator.

B. R.
Tina
-------------------------------------------------------------
You know it is Monday when you see cat hair in your cereal.
  ----- Original Message ----- 
  From: Glen Zorn 
  To: [email-masked] ; [email-masked] ; [email-masked] 
  Cc: [email-masked] ; [email-masked] 
  Sent: Tuesday, December 11, 2007 3:58 PM
  Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt

  ...

  [gwz] 
   
  ...

---

From: <[email-masked]>
Date: Tue, 11 Dec 2007 11:47:40 +0100

Hi Preeti,

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

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 11 Dec 2007 09:03:09 -0500

Hi Jouni,

> Sent: Monday, December 10, 2007 4:49 PM
> To: Asveren, Tolga; [email-masked]
[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?

> > > > > weird. I mean, there are identified issues slash grey areas,
so
> > why
> > > > > rel-8 timeframe. Coming back to above reference, the same
family
> > of
> > > > > scary specs also use NAI decoration based source routing as
part
> > of

---

From: <[email-masked]>
Date: Tue, 11 Dec 2007 16:41:07 +0100

Hi Tolga,

[snip]

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

Don't see a reason for this.

> b) Or does it use a different Diameter identity for each domain?

NAP has one identity.

> c) Or do the clients assume that NAP provides access for all 
> possible domains?

The NAP provides access to those realms it advertises.

Cheers,
	Jouni

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 11 Dec 2007 10:21:35 -0800

Dear Glen and all,

I know Jouni has two use cases. Jouni, Steve and I talked about them in
Vancouver. I am trying to describe as below. If it is not precise, Jouni,
please correct me.

Use case #1:

......

[gwz] 

So what happens if node #a is down?  Is Type 1# service
disabled/unavailable?  If not, what's the point of the routing, given that
it is unnecessary; if so, doesn't that sort of defeat the purpose of
fail-over?

[/gwz]

Use case #2:

[gwz] 

Does this mean that the data path must also pass through that node?

[/gwz]

B. R.
Tina

---

From: <[email-masked]>
Date: Tue, 11 Dec 2007 23:49:49 +0100

Glen,

> > 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.
> 
> I must admit that I cannot think of a single (real-life) 
> scenario where this kind of thing would be desirable (let 
> alone required).  Would you mind describing one in detail?
> [/gwz]

References to literature were given earlier in this thread ;)

Anyway, assume two providers connected via "roaming infrastructure
cloud" that cannot guarantee same AAA routes deterministically. The
visited provider has outsourced its AAA based roaming charging to
third party proxies within the "cloud" (each provider may have their
own "third party"). 

/Jouni

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 11 Dec 2007 19:11:47 -0800

Glen,

[gwz] And? [/gwz]

/Jouni

---

From: Preeti Shandilya <[email-masked]>
Date: Wed, 12 Dec 2007 09:59:09 +0530

Hi Jouni !

In my opinion, if it is required that all the messages to follow the same 
proxy node(so that proxy can apply charging) , this shall be specific 
node's routing policy. i.e Source,  while selecting a route, it should 
always end up selecting the proxy node for sending the message. I don't 
think there is any need of standardization of routing policy for this 
specific purpose. While selecting the route, nodes can look into the type 
of service also inside the message which is to be routed further.

regards
preeti

12/12/2007 04:19 AM

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

Glen,

/Jouni

---

From: Tina TSOU <[email-masked]>
Date: Thu, 13 Dec 2007 14:23:31 +0800

Dear all,
I would like to re-emphasize Tolga's earlier comment on this (which in my opinion so rightly describes the problem & solution):
1. It is not the originator's, but the visited n/ws business case that its proxy should be in-path for all the messages of the session. So, originator may/need not decide this route, the proxy must have a mechanism to stay in the path.
2. As long as all next hops in the visited n/w are session stateful, the proxy in the visited n/w has no problem to stay in path. The problem comes when there are some session agnostic/stateless agents (read as relays) in between.
3. The explicit routing does not supercede fail over considerations. It will select the same next hop as long as it is available only.

B. R.
Tina

---

From: Tina TSOU <[email-masked]>
Date: Thu, 13 Dec 2007 14:37:47 +0800

Dear Preeti,
My comments are below demarked with [Tina: ...].

B. R.
Tina
  ----- Original Message ----- 
  From: Preeti Shandilya 
  To: [email-masked] 
  Cc: [email-masked] ; [email-masked] 
  Sent: Wednesday, December 12, 2007 12:29 PM
  Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt

  Hi Jouni ! 

  In my opinion, if it is required that all the messages to follow the same proxy node(so that proxy can apply charging) , this shall be specific node's routing policy. i.e Source,  while selecting a route, it should always end up selecting the proxy node for sending the message. I don't think there is any need of standardization of routing policy for this specific purpose. While selecting the route, nodes can look into the type of service also inside the message which is to be routed further. 
  [Tina: Stateful proxy agent routing is a common problem. Basing on service type doesn't' work, as maybe many nodes will process same service. This is the issue this I-D will resolve, how to select among multiple service nodes.]

  regards 
  preeti 

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

  Glen,

  /Jouni

  ***********************  Aricent-Restricted   *********************** "DISCLAIMER: This message is proprietary to Aricent  and is intended solely for the use of 

------------------------------------------------------------------------------

---

From: Tina TSOU <[email-masked]>
Date: Thu, 13 Dec 2007 14:44:54 +0800

Dear Glen,

B. R.
Tina
  ----- Original Message ----- 
  From: Glen Zorn 
  To: 'Tina TSOU' ; [email-masked] ; [email-masked] ; [email-masked] 
  Cc: [email-masked] ; [email-masked] 
  Sent: Wednesday, December 12, 2007 2:21 AM
  Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt

  Dear Glen and all,

  Use case #1:

  ......

  [gwz] 

  So what happens if node #a is down?  Is Type 1# service disabled/unavailable?  If not, what's the point of the routing, given that it is unnecessary; if so, doesn't that sort of defeat the purpose of fail-over?

  [/gwz]

  [Tina: Ongoing session will disable/unavailable. But the service can use another stateful proxy agent. It is like one server fails. If one server fails, ongoing session will fail, but another server maybe can take over new session process.] 

  Use case #2:

  [gwz] 

  [/gwz]

  [Tina: It is unnecessary, the node maybe just do charging base on session time.] 

  B. R.
  Tina