Subject: Re: [Dime] 答复: resubmission draft for capabilities-update-propoblem statment

From: Victor Fajardo <[email-masked]>
Date: Mon, 18 Aug 2008 10:16:57 -0400

Hi Shan,

> Thanks for your comments!
> Just as a fundamental idea, it's not recommended for a node to perform the
> same processing twice upon the peer's capabilities change, esp. for the
> primary protocol. That's a reason to have a clearer view on this, to avoid
> magnifying the 'bug' unlimited.
>   

Ok.

> Taking into your comments, and what we had in the F2F meeting, let's come up
> a new revision, esp. with the backward compatibility late. Thanks!
>   

Did you have the chance to reviewed my suggestion below ?

> Thanks for describing the problem with the CER/CEA exchange in the open 
> state. I think we maybe able to solve the issue described in this draft 
> without introducing a new non-backward compatible CEA ABNF. From my 
> understanding (which maybe incorrect), the key to the optimization 
> described in your draft is to ignore the peer capabilities contained in 
> the CEA in the OPEN state (both scenario 1 and 2 in your draft). If this 
> is true, then the current bis document already supports this because it 
> states in Sec 5.3:
>
> "The sender of the Capabilities-Exchange-Answer  (CEA) SHOULD include 
> all of its supported applications as a hint to the receiver regarding 
> all of its application capabilities."
>
> In this case, we are not mandating that the CEA receiver processes the 
> received peer capabilities. In some sense, I do think that text in 5.3 
> is hard to read and this maybe why we end up with these types of 
> discussions. So, for me, we may need to cleanup the text in 5.3 to 
> simply the description of what is actually happening. With regards to 
> this particular issue, we can even relax the CEA processing even more by 
> changing it to MAY instead of SHOULD.
>   

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

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 20 Aug 2008 10:03:36 -0400

Hi Shan,

Here's an updated version of the "Capabilities Update" section of bis 
that hopefully addresses the issue you stated in your draft:

"5.6.5.  Capabilities Update

   When a Diameter node is in the OPEN state, it can notify all its
   peers that its capabilities has changed by sending a Capabilities-
   Exchange-Req (CER).  The receiver(s) of CER MUST reply with a CEA as
   a described in Section 5.3.  Peers which successfully process a
   received CER SHOULD update their routing tables to reflect the
   change.  The receiver of a CEA with the Result-Code AVP set to
   DIAMETER_SUCCESS MAY ignore the list of supported applications
   contained in the CEA.  This optimization prevents the receiver from
   having to un-necessarily update is local routing tables.  The
   receiver of the CEA with a Result-Code AVP set to a value other than
   DIAMETER_SUCCESS MUST disconnect the transport layer.  The Diameter
   node MAY attempt to reconnect if its local capabilities has changed
   as stated in Section 2.1.

   Peer capabilities update SHOULD be limited to the advertisement of a
   new list of supported applications and MUST not include re-
   negotiation of security mechanism or other capabilities.  If any
   capabilities update occurs in a Diameter node other than a list of
   supported applications, the node SHOULD gracefully terminate all its
   peer connections and simply attempt to re-connect with a new set of
   capabilities.
"

regards,
victor

---

From: "David Frascone" <[email-masked]>
Date: Wed, 20 Aug 2008 10:25:27 -0400

I think the new text is clear, and resolves the issue.

Only one comment -- should we explain *why* a peer can ignore the
applications listed in a CEA?

-Dave

On Wed, Aug 20, 2008 at 10:03 AM, Victor Fajardo
<[email-masked]>wrote:

> Hi Shan,
>
> Here's an updated version of the "Capabilities Update" section of bis that
> hopefully addresses the issue you stated in your draft:
>
>>> understanding (which maybe incorrect), the key to the optimization described
>>> in your draft is to ignore the peer capabilities contained in the CEA in the
>>> OPEN state (both scenario 1 and 2 in your draft). If this is true, then the
>>> current bis document already supports this because it states in Sec 5.3:
>>>
>>> "The sender of the Capabilities-Exchange-Answer  (CEA) SHOULD include all
>>> of its supported applications as a hint to the receiver regarding all of its
>>> application capabilities."
>>>
>>> received peer capabilities. In some sense, I do think that text in 5.3 is
>>> hard to read and this maybe why we end up with these types of discussions.
>>> So, for me, we may need to cleanup the text in 5.3 to simply the description
>>> of what is actually happening. With regards to this particular issue, we can
>>> even relax the CEA processing even more by changing it to MAY instead of
>>> SHOULD.
>>>
>>>
>>
>>

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 20 Aug 2008 10:34:21 -0400

Hi David,

> applications listed in a CEA?

I guess we can as long as its short  an concise.

regards,
victor

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 21 Aug 2008 16:32:38 +0700

Victor Fajardo <mailto://[email-masked]> writes:

...

>    peer connections and simply attempt to re-connect with a new set of

Aside from the obvious fact that the initial message is not a
"Capabilities-Exchange-Req" (no exchange is being requested, a change is
being announced), this looks much better.  The following fixes a few
typos/grammatical errors:

    When a Diameter node is in the OPEN state, it can notify all its
    peers that the set of Diameter applications it supports has changed by
sending a Capabilities-
    Exchange-Req (CER).  The receiver of a CER MUST reply with a CEA as
    a described in Section 5.3.  Peers which successfully process a
    received CER SHOULD update their routing tables to reflect the
    change.  The receiver of a CEA with the Result-Code AVP set to
    DIAMETER_SUCCESS MAY ignore the list of supported applications
    contained in the CEA.  This optimization prevents the receiver from
    having to unnecessarily update its local routing tables.  The
    receiver of the CEA with a Result-Code AVP set to a value other than
    DIAMETER_SUCCESS MUST disconnect the transport layer.  The Diameter
    node MAY attempt to reconnect if its local capabilities have changed
    as stated in Section 2.1.
 
    Peer capabilities update SHOULD be limited to the advertisement of a
    new list of supported applications and MUST not include re-
    negotiation of the security mechanism or other capabilities.  If any
    change in capabilities occurs in a Diameter node other than a list of
    supported applications, the node SHOULD gracefully terminate all its
    peer connections and simply attempt to re-connect with a new set of
    capabilities.
"

A couple more things: in this situation, might not the MAY in "The receiver
of a CEA with the Result-Code AVP set to DIAMETER_SUCCESS MAY ignore the
list of supported applications contained in the CEA" better be a SHOULD,
since only rarely will changes in supported applications in peers be
simultaneous?  Also, I'm not sure what " The Diameter node MAY attempt to
reconnect if its local capabilities have changed as stated in Section 2.1."
means: there are at least 2 Diameter nodes being discussed here, which one
is it?  

...

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 21 Aug 2008 16:38:38 +0700

> I guess we can as long as its short  an concise.

I think that this confusion is inherent in the overloading of the CER/CEA
exchange -- we'll pay later for any false economy of words today...

> described

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 21 Aug 2008 09:26:42 -0400

Hi Glen,

>     peer connections and simply attempt to re-connect with a new set of

Looks good. Thanks.

> simultaneous?  

I'm ok with that.

> Also, I'm not sure what " The Diameter node MAY attempt to

It is implies either nodes. In which case, how about changing the text to:

"Both Diameter nodes MAY attempt to reconnect if their local 
capabilities have changed ...."

br,
-- victor

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 21 Aug 2008 09:28:24 -0400

Hi Glen,

> exchange -- we'll pay later for any false economy of words today...

Ok. Any text you can suggest ?

br,
-- victor

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 21 Aug 2008 21:08:34 +0700

Victor Fajardo [mailto:[email-masked]] writes:

Missed one, sorry:

Change:
If any change in capabilities occurs in a Diameter node other than a list of
supported applications, the node SHOULD gracefully terminate all its peer
connections and simply attempt to re-connect with a new set of capabilities.

To:
If any change in capabilities occurs in a Diameter node other than to the
list of supported applications, the node SHOULD gracefully terminate all its
peer connections and simply attempt to re-connect with a new set of
capabilities.

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 21 Aug 2008 10:32:57 -0400

Great. Thanks.