Re: [Dime] 答复: Design Team on Diameter Routing

Hi Fortune, 

>Hi all,
>
>I visited the diameter-routing group and noticed that there 
>was a conference call on Sep 19.

Yes, I scheduld a call.  Unfortunately, I was the only person on the call. I have no clue why other folks did not join the call. 

As you can imagine I was not happy. 

I have scheduled another conf. call for next week. 

 Although I am very interested 
>in this topic, unfortunately I am not one of the design team 
>members and haven't been invited to the group.
>Therefore, could Hannes or someone else be so kind to send out 
>something like the minutes for us to know the progress, please?

In previous design teams I have distributed meeting minutes. In this specific case I obviously cannot distribute any minutes since the meeting essentially did not took place. 

>
>BTW, here is my understanding of the diameter routing problems 
>or scenarios.
>Please correct me if I am wrong.
>1) Explicit routing. If there are alternative Diameter proxies 
>which perform for example charging based on messages (e.g. 
>AAR/AAA for charging start, and STR for charging termination), 
>once a proxy is chosen for the first request or response 
>message (e.g. AAR or AAA), the following messages (e.g. STR) 
>should always go through the proxy; otherwise, the charging never ends.
>Explicit routing a mechanism to make sure the following 
>messages go through the proxy which has been chosen for the session.

There are two issues related to this: 

A) Are these valid scenario that proxies need to be in the path for every messages of certain sessions? 

B) At what level does routing work? Is it on the level of a domain or based on individual hosts? 

In past discussions folks had different views regarding both (A) and (B) with several strong opinions raised against explicit routing based on individual hosts rather than domains. 

>2) Redirect realm indication. Suppose operater_A with Realm_A 
>currently provides a certain service to its Diameter clients. 
>However, for a certain reason, operater_A decides not to 
>provide the service any longer and asks operator_B with 
>Realm_B to provide the same service to its clients. Before all 
>its clients change their configuration to send the service 
>requests directly to Realm_B, the Diameter redirect agent in 
>Realm_A may also need to redirect the incoming requests to 
>Realm_B at least for a period of time.
>Redirect realm indication is a mechanism to make the relay 
>function more flexible and make the redirect to another realm happen.

This is a nice scenario. Is it a challenge operators face when deploying Diameter or is it rather a theoretically nice thing to have? 
My impression so far was that the redirect mechanism isn't really widely used at all. In your example above, I could imagine that operator A may want to still see all messages to make sure that it knows what operator B is actually offering to clients. 

Thanks for sharing your thoughts with us. 

Ciao
Hannes

>Best Regards,
>Fortune
>
>
>-----邮件原件-----
>发件人: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] 代表
>Tschofenig, Hannes (NSN - FI/Espoo)
>发送时间: 2008年9月4日 14:41
>收件人: dime@ietf.org
>抄送: diameter-routing@googlegroups.com
>主题: [Dime] Design Team on Diameter Routing
>
>The DIME chairs in discussion with Dan decided to create a 
>design team with the intention to investigate extensions to 
>the RFC 3588bis Diameter routing. More specifically, we had 
>discussions about this subject triggered by the publication of 
>http://tools.ietf.org/id/draft-tsou-dime-base-routing-ext-04.tx
>t that never got resolved and the impression of folks at the 
>IETF#72 meeting was that we have to investigate the usage 
>scenarios and to develop a problem statement before we focus 
>on the solution components. 
>
>The first product of the group will be a problem statement and 
>usage scenarios description that will be presented to the DIME group. 
>Other necessary activity will be decided based on the outcome 
>of the above-mentioned deliverable. 
>
>The design team members are:
>- Tena Tsou
>- Victor Fajardo
>- Jouni Korhonen
>- Tolga Asveren
>- Mark Jones
>- Avi Lior
>- Glen Zorn
>- Steve Norreys
>- Lionel Morand
>
>The design team is lead by the working group chairs: Dave 
>Frascone and Hannes Tschofenig
>
>Mailing List archive: 
>http://groups.google.com/group/diameter-routing
>
>Ciao
>Hannes & Dave
>
>PS: The rules for design teams are described in 
>http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt
>
>_______________________________________________
>DiME mailing list
>DiME@ietf.org
>https://www.ietf.org/mailman/listinfo/dime
>
>
>
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime