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

From: Ravi <[email-masked]>
Date: Wed, 19 Aug 2009 22:59:57 +0530

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

---

From: "Subash Comerica (subashtc)" <[email-masked]>
Date: Thu, 20 Aug 2009 10:41:37 +0530

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Ravi
	Sent: Wednesday, August 19, 2009 11:00 PM
	To: [email-masked]
	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

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

	Ravi

---

From: "Victor Fajardo" <[email-masked]>
Date: Thu, 20 Aug 2009 08:46:23 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Subash Comerica (subashtc)
Sent: Thursday, August 20, 2009 1:12 AM
To: Ravi; [email-masked]
Subject: Re: [Dime] Comment on draft-ietf-dime-capablities-update-00.txt

Hi Ravi,

    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

 

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ravi
Sent: Wednesday, August 19, 2009 11:00 PM
To: [email-masked]
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.

Ravi

---

From: Ravi <[email-masked]>
Date: Thu, 20 Aug 2009 23:00:42 +0530

Hi, This is my view of the diameter core protocol and applications

           _________________________
 ________________________________
          |                                            |           |
                                              |
          |          IETF Applications        |           |          3GPP
Applications                  |
          |(accounting, credit control,...) |           |    (Rf, Ro, Gx,
Cx, Dx ....)                 |
          |_________________________|
|_______________________________ |

______________________________________________________________________
          |
                                                         |
          |                                                    Core Protocol
                                                 |

 |______________________________________________________________________|

1) The core protocol is responsible for transport establishment(Peer state
machine), connection supervision(watch dog), capabilities exchange, routing,
peer discovery. Capability exchange is one of the main functions of the core
protocol.

2) The applications are responsible for functions like NASREQ, credit
control, accounting and maintaining their state machines (auth, accounting
or  credit control).

IMO creating an application for the purpose of capability exchange is
probably not a very good idea because it moves a core protocol function into
the application scope.

I read the e-mail thread which you have referred regarding previous
discussions and this is my opinion

The concern seems to be about how the CEA should be handled. Whether the
peer receiving the CEA should update the peer capabilities or not upon
receiving a result code of DIAMETER_SUCCESS in the CEA. Hence in the draft,
the CUA has only few AVPs like Result Code and it does not have the
application ids of the peer. The rationale is that both the peers intending
to advertise their updated capabilities simultaneously is a rare occurrence.

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 <
[email-masked]> 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:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Subash Comerica (subashtc)
> *Sent:* Thursday, August 20, 2009 1:12 AM
> *To:* Ravi; [email-masked]
> *Subject:* Re: [Dime] Comment on draft-ietf-dime-capablities-update-00.txt
>
>
>
> Hi Ravi,
>
> *Changing the Way We Live, Work, Play and Learn*
>
>
>
>
>  ------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Ravi
> *Sent:* Wednesday, August 19, 2009 11:00 PM
> *To:* [email-masked]
> *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.
>
>
>
> To summarize, I feel that capabilities advertisement/update should belong
> to base protocol and not belong to diameter application scope.
>
>
>
> Ravi
>
>

---

From: "Victor Fajardo" <[email-masked]>
Date: Fri, 21 Aug 2009 08:48:57 -0400

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

Ravi

On Thu, Aug 20, 2009 at 6:16 PM, Victor Fajardo
<[email-masked]> wrote:

Hi,

Regards,

victor

Hi Ravi,

Thanks & Regards,

Subash

 

  _____  

Hi, 

Ravi

---

From: Ravi <[email-masked]>
Date: Sun, 23 Aug 2009 23:29:55 +0530

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 <
[email-masked]> wrote:

> think we maybe missing a point here. It’s not that we cannot do option 1, 2
> required contextual behavior based on the presence/absence of an AVP …
> 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
>
>
>

---

From: "Victor Fajardo" <[email-masked]>
Date: Mon, 24 Aug 2009 08:43:53 -0400

Hi,

Comments inline:

From: Ravi [mailto:[email-masked]] 
Sent: Sunday, August 23, 2009 2:00 PM
To: [email-masked]
Cc: Subash Comerica (subashtc); [email-masked]
Subject: Re: [Dime] Comment on draft-ietf-dime-capablities-update-00.txt

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.

 

[Victor]: As you may already know,  the decision you mentioned above is
because we want to preserve backward compatibility and not increment the
version number for bis. We have a lot of resistance with this and we want to
progress bis as quick as possible.

 

[Victor]: This is what other folks have mentioned as well. 

Regards,

Victor

Your opinion is welcome.

Ravi

On Fri, Aug 21, 2009 at 6:18 PM, Victor Fajardo
<[email-masked]> wrote:

Hi Ravi,

Regards,

victor

Now, coming to my view

Ravi

Hi,

Regards,

victor

Hi Ravi,

Thanks & Regards,

Subash

 

  _____  

Hi, 

Ravi