Re: [Dime] Comment on draft-ietf-dime-capablities-update-00.txt

[Ravi <nrs2712 at gmail.com>]

Hi Victor,

     Thanks for your response. I agree with your point that we need to have a clean solution and not overload a command. However I am not sure if I really agree with the point that we are overloading the CER command. We are talking about capabilities update here and I feel CER is the right command for this. In fact capabilities exchange in the open state was designated to be done using CER/CEA in RFC 3588. This is deprecated now because of various reasons.

Having said that, I am not against defining a new command for this purpose. I feel we already have a command to achieve this and its scope is being restricted. We may however go ahead with this approach(defining a new command) if everyone thinks this is the best approach.

I am not really convinced that we need to define a new application for the purpose of capabilities update. I feel that capabilities update MUST be done in the scope of "Diameter Common Messages" i.e. with appid = 0.

I agree with you that we need to comply to the guideline while defining extensions to the protocol mechanism but I am not sure if we can ignore the protocol functional architecture altogether.(core protocol functions Vs application functions)

If it is really difficult to come up with a clean solution in the current diameter version, we could take up this capabilities update mechanism in the Version 2 of Diameter base protocol. (There are some other ways of achieving this like defining a request type AVP which says Initial / Update. This can be discussed later)

Your opinion is welcome.

Ravi

On Fri, Aug 21, 2009 at 6:18 PM, Victor Fajardo <vfajardo at research.telcordia.com> wrote:

Hi Ravi,

 

I understand the description you posted below and it is reasonable. But I think we maybe missing a point here. It’s not that we cannot do option 1, 2 or 3 below (technically we can do anything we want to and convolute CER/CEA to our hearts content). The point is we want a clean solution that does not violate our own guidelines in overloading a command. For me, your option 3 below is a classic example of command overloading. Your putting a lot of required contextual behavior based on the presence/absence of an AVP … something our guideline says we should avoid doing.

 

Regards,

victor

 

Now, coming to my view

 

1) If both the peers advertising their updated capabilities simultaneously is a rare occurrence then actually it does not matter if the peer sends the application-ids in the CEA because there is no change in supported applications. A simple check to verify any change from the previous supported applications of the peer will suffice.

2) Assuming that rarest of the rare instance happens where there is a near simultaneous upgrade of both the peer and a CER/CEA exchange is triggered. Then both the peers need to match each other's capabilities. This does not change for the case we use CUR/CUA.

3) I presume that the backward compatibility issue arises from the fact that RFC 3588 mentions about CER/CEA exchange in open state but does not clearly specify what should be done by the peers in this case. CER/CEA exchange is deprecated in the 3588 bis and this new mechanism of CUR/CUA is being proposed.

I feel the same can be achieved using a new AVP in the CER. Am I overlooking something?

 

Ravi

 

On Thu, Aug 20, 2009 at 6:16 PM, Victor Fajardo <vfajardo at research.telcordia.com> wrote:

Hi,

 

Just to give you a background on why this draft exist: 1) We’ve gone through this discussion several IETF’s ago and we realized that we are overloading CER/CEA in terms of context and use. 2) We did not want to introduce a new set of non-backward compatible semantics into CER/CEA just for the sake of updating. Check out the problem statement for this draft and also the thread: http://www.ietf.org/mail-archive/web/dime/current/msg02775.html

 

Regards,

victor

 

 

From: dime-bounces at ietf.org [mailto:dime-bounces at ietf.org] On Behalf Of Subash Comerica (subashtc)
Sent: Thursday, August 20, 2009 1:12 AM
To: Ravi; dime at ietf.org
Subject: Re: [Dime] Comment on draft-ietf-dime-capablities-update-00.txt

 

Hi Ravi,

    I guess the intent here is to support dynamically changing the capabilities.

    I believe RFC 3588 also talks about the state machine where if the peer state is I-open(or R-open) and receives a CER, it processes the CER and sends a CEA and still remains in I-open(or R-open) state.

    So I agree with you that it is doable as an optional AVP in CER itself.

 

Thanks & Regards,

Subash

Changing the Way We Live, Work, Play and Learn

 

 

---

From: dime-bounces at ietf.org [mailto:dime-bounces at ietf.org] On Behalf Of Ravi
Sent: Wednesday, August 19, 2009 11:00 PM
To: dime at ietf.org
Subject: [Dime] Comment on draft-ietf-dime-capablities-update-00.txt

Hi,

  I read the draft-ietf-dime-capablities-update-00.txt document and I have a comment regarding defining a new application for the purpose of capability updates.

 

1) Advertising the capabilities of a diameter node is the function of the diameter base protocol. IMO we need to do this in the scope of the diameter base protocol and not as a separate application

2) By way of defining a new application-id, a diameter node obtains the ability to know that a peer has the capability to receive a capabilities update message in the Open state. This function can be achieved by defining a new AVP in the CER. A new AVP can be defined called "Capabilities-Update-AVP". This can be defined as an optional AVP in the CER message. There is no need to set the "M" flag for this AVP. It takes two enumerated values "Supported", "UnSupported"

 

Peer A sends a CER with "Capabilities-Update-AVP" set as "Supported". When peer B receives this AVP, there can be two possibilities

 

1) It understands this AVP and it can choose to respond with "Supported"/"UnSupported" depending on its intent to receive/publish a CER to/from the peer

2) It doesnt understand this AVP and hence it is ignored and a CEA is sent back without this AVP

 

Both the peers get to know of each other's intent/capability to receive/publish a CER.

Capability update is carried by using CER/CEA messages.

 

To summarize, I feel that capabilities advertisement/update should belong to base protocol and not belong to diameter application scope.

 

Ravi