Subject: [Dime] comments on draft-tsou-dime-realm-based-redirect-00

From: "Glen Zorn" <[email-masked]>
Date: Sat, 13 Jun 2009 13:47:21 +0700

Section 2 says:

   Note that regardless of which approach is used, the original operator
   cannot escape the necessity to specify at least one individual
   Redirect-Host in indications to upstream Diameter nodes that cannot
   handle realm-based redirection.

That being the case, this capability seems pretty much useless.  Presumably,
one of the main purposes of realm-based redirection is to allow SPs to avoid
keeping track of Diameter nodes in other realms, but if one node needs to be
tracked, why not all?  Therefore, I think that this draft needs to be
changed to either a) define a new application (so that realm-based
redirection support can be advertised) or b) changed to Standards-Track &
stated to update RFC 3588.

~gwz

Play assigns meaning to human activity--work erases it.
  -- P.L. Wilson

---

From: Sebastien Decugis <[email-masked]>
Date: Mon, 15 Jun 2009 12:12:17 +0900

Hi,

I have a naive question. Is it not possible to define a new error code
(distinct from DIAMETER_REDIRECT_INDICATION) for this purpose, to get
rid of managing a single host in the redirect agent? I guess this would
also imply update of RFC 3588, but at least backward compatibility
issues can be removed from the draft.

Best regards,
Sebastien.

Glen Zorn a écrit :
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>
>   

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 15 Jun 2009 09:54:08 +0300

The first thing to decide about the document is whether there is a real problem we want to solve. 

Then, we jump into how to solve it. 
Still, thanks a lot for the review. 

Ciao
Hannes

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Sebastien Decugis
>Sent: 15 June, 2009 06:12
>To: 'Tina TSOU'
>Cc: [email-masked]
>Subject: Re: [Dime] comments on draft-tsou-dime-realm-based-redirect-00
>
>Hi,
>
>I have a naive question. Is it not possible to define a new 
>error code (distinct from DIAMETER_REDIRECT_INDICATION) for 
>this purpose, to get rid of managing a single host in the 
>redirect agent? I guess this would also imply update of RFC 
>3588, but at least backward compatibility issues can be 
>removed from the draft.
>
>Best regards,
>Sebastien.
>
>
>Glen Zorn a écrit :
>> Section 2 says:
>>
>> That being the case, this capability seems pretty much useless.  
>> Presumably, one of the main purposes of realm-based 
>redirection is to 
>> allow SPs to avoid keeping track of Diameter nodes in other realms, 
>> but if one node needs to be tracked, why not all?  
>Therefore, I think 
>> that this draft needs to be changed to either a) define a new 
>> application (so that realm-based redirection support can be 
>> advertised) or b) changed to Standards-Track & stated to 
>update RFC 3588.
>>
>>
>>
>>
>> ~gwz
>>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 15 Jun 2009 09:00:44 +0200

Do we have indications from operators of users that this is a problem and that standard DIAMETER extensions would be an appropriate way to solve this problem? 

Dan

> Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Monday, June 15, 2009 9:54 AM
> To: ext Sebastien Decugis; Tina TSOU
> Cc: [email-masked]
> >From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of 
> >ext Sebastien Decugis
> error code

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 15 Jun 2009 15:24:16 +0700

Tschofenig, Hannes (NSN - FI/Espoo) [mailto:[email-masked]]

> problem we want to solve.

I thought that one of the useful outputs of the routing design team was that
this (along with NAI-based routing) were useful things that should be
pursued.  Am I mistaken?

> Still, thanks a lot for the review.

This is what you said in your "Hum" message: "Please let us know whether you
would want draft-tsou-dime-realm-based-redirect-00.txt to become a working
group item in DIME or whether you have objections."  I don't see anything in
there about "whether there is a real problem to be solved"; you ask about
whether the document should become a WG item.  It it's possible to offer a
real opinion on that question _without_ reviewing the document, perhaps you
can tell me how?  Prophecy, perhaps?  Furthermore, discussion of solutions
would seem to imply that the problem is considered to be one that would be
useful to solve, at least to those doing the discussing.

...

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 15 Jun 2009 11:39:21 +0300

Hi Glen,

>I thought that one of the useful outputs of the routing design 
>team was that this (along with NAI-based routing) were useful 
>things that should be pursued.  Am I mistaken?

You need to make your own assessment how successful the design team work
was. 

Picking up work that folks believe is important is appreciated. 

>This is what you said in your "Hum" message: "Please let us 
>know whether you would want 
>draft-tsou-dime-realm-based-redirect-00.txt to become a 
>working group item in DIME or whether you have objections."  I 
>don't see anything in there about "whether there is a real 
>problem to be solved"; you ask about whether the document 
>should become a WG item.  It it's possible to offer a real 
>opinion on that question _without_ reviewing the document, 
>perhaps you can tell me how?  Prophecy, perhaps?  Furthermore, 
>discussion of solutions would seem to imply that the problem 
>is considered to be one that would be useful to solve, at 
>least to those doing the discussing.

My mail was sent in light with the alternative proposals on how to solve
the problem. 

As you know, draft-tsou-dime-realm-based-redirect-00.txt is only the
starting point and everything can change (from a content point of view)
but hopefully the problem to be solved remains roughly the same :-)

Ciao
Hannes

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 15 Jun 2009 11:03:19 +0200

> From: Glen Zorn [mailto:[email-masked]] 
> Sent: Monday, June 15, 2009 11:48 AM
> To: Romascanu, Dan (Dan); 'Tschofenig, Hannes (NSN - 
> FI/Espoo)'; 'ext Sebastien Decugis'; 'Tina TSOU'
> Cc: [email-masked]
> Subject: RE: [Dime] comments on 
> draft-tsou-dime-realm-based-redirect-00
> 
> Romascanu, Dan (Dan) [mailto://Dan Romascanu 
> ([email-masked])] writes:
> 
> > Do we have indications from operators of users that this is 
> a problem 
> > and that standard DIAMETER extensions would be an 
> appropriate way to 
> > solve this problem?
> 
> You're kidding, right?  If we waited for operators to notice 
> a problem before tackling it IPv6 development would have 
> started last week ;-).
> 

Maybe, but we are in OPS and we do protocols and data models for
operators here. So even if we do not enjoy the participation of many
operators in this WG nowadays asking whether at least the vendors who
are proposing a piece of work are basing their proposal on requirements
they hear from operators and end-users seems to me a reasonable sanity
checking method for dealing with such 'hums'.

Dan

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 15 Jun 2009 15:47:56 +0700

Romascanu, Dan (Dan) [mailto://Dan Romascanu ([email-masked])] writes:

> Do we have indications from operators of users that this is a problem
> and that standard DIAMETER extensions would be an appropriate way to
> solve this problem?

You're kidding, right?  If we waited for operators to notice a problem
before tackling it IPv6 development would have started last week ;-).

...

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 15 Jun 2009 13:01:25 +0300

Glen, 

>You're kidding, right?  If we waited for operators to notice a 
>problem before tackling it IPv6 development would have started 
>last week ;-).

Checking with those folks who deploy some of the extensions we are working
on isn't a bad idea (tm). This is useful input for our work. I also
encourage folks to implement extensions, which is another source of input.
All these things are important. 

When time in the group is limited and the group itself has a limited
capacity for processing stuff it is important to select items that are more
likely to ever see the light at the end of the tunnel. Maybe
draft-tsou-dime-realm-based-redirect is such an item that will be demanded a
lot. Everyone needs to make their own judgement. Ideally, folks might also
like to indicate why they like a certain thing. In the previous IETF meeting
Avi stood up when you presented your MIB things and said that they would
implement them once they become RFC. That's useful information (if correct).

Ciao
Hannes

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 15 Jun 2009 17:03:59 +0700

...

> Picking up work that folks believe is important is appreciated.

I think that the idea may be useful; the draft needs a lot of work, though.
For example, what should the client do if it has no peer in the specified
realm?

...

> My mail was sent in light with the alternative proposals on how to

I see.  I just wasn't aware of any alternative proposals...

> starting point 

Of course!

> and everything can change (from a content point of view)

Ah, but ensuring that's your job (with Victor :-).

...

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 15 Jun 2009 17:13:54 +0700

Hannes Tschofenig [mailto:[email-masked]] writes:

> on isn't a bad idea (tm). This is useful input for our work. 

My point was that this kind of thing should not be a limiting factor.
People often have no idea how much they needed something until they get
it...

...

> lot. 

In my (admittedly limited) experience, if something is useful, it will be
used.

> Everyone needs to make their own judgement. Ideally, folks might
> also

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 15 Jun 2009 17:37:18 +0700

Romascanu, Dan (Dan) [mailto:[email-masked]] writes:

...

> checking method for dealing with such 'hums'.

Possibly so, but here's a question that may cast some light upon the
validity of this approach: How many years elapsed between the publication of
RFC 3588 & (some) operators' discovery that they needed the protocol we're
busily extending?

---

From: "Carlberg, Kenneth G." <[email-masked]>
Date: Mon, 15 Jun 2009 07:58:10 -0400

> Glen Zorn writes:
>
>  > Checking with those folks who deploy some of the extensions we are 
>  > working on isn't a bad idea (tm). This is useful input for 
>  our work.
>  
>  People often have no idea how much they needed something 
>  until they get it...

I'm inclined to agree with elements of both sides of the argument.
Sanity checks in terms of what is distinctly broken are appreciated
(even desired) by the operator community.  But, I much rather prefer to
lean towards the presence of additional tools (particularly those
favored by vendors) and rely on the old adage of "letting the market
decide".

(speaking as one who doesn't have a horse in this particular race :-)

-ken

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 15 Jun 2009 14:12:50 +0200

> Sent: Monday, June 15, 2009 1:37 PM
> > > problem before tackling it IPv6 development would have 
> started last 
> > > week ;-).
> > >
> > 
> > are proposing a piece of work are basing their proposal on 
> > requirements they hear from operators and end-users seems to me a 
> > reasonable sanity checking method for dealing with such 'hums'.
> 
> Possibly so, but here's a question that may cast some light 
> upon the validity of this approach: How many years elapsed 
> between the publication of RFC 3588 & (some) operators' 
> discovery that they needed the protocol we're busily extending?
> 
> > 
> > Dan
> 
> 

I am not making the argument that popular demand should be the only way
we decide what to do. What I am saying is that there are cases when a WG
can use operators and users input as a way to filter and prioritize -
especially when the WG has more new things to do proposed than it is
capable to execute. 

Dan

---

From: jouni korhonen <[email-masked]>
Date: Mon, 15 Jun 2009 21:24:30 +0300

Well.. I don't personally know of any concrete requirements, yet.  
However, a plethora of (mobile) operators have just started to work on  
their Diameter based roaming recommendations (LTE roaming), so I would  
say that not too many (mobile) operator has yet realized what they  
will exactly need at Diameter level.

Still, the concept proposed by this draft could be an useful tool. Not  
necessarily in the "problem context" the draft presents and the  
solution could be different. One thing I was thinking here is whether  
the redirection could be achieved transparently. For example a back-to- 
back type solution could probably work and would not require support  
from originating hosts or agents beyond those doing the redirection..

Cheers,
	Jouni

On Jun 15, 2009, at 10:00 AM, Romascanu, Dan (Dan) wrote:

> Do we have indications from operators of users that this is a  
> problem and that standard DIAMETER extensions would be an  
> appropriate way to solve this problem?
>
> Dan
>
>