Subject: RE: [Dime] Backward Capability Propagation

From: "Soji VP" <[email-masked]>
Date: Tue, 10 Jul 2007 20:47:13 +0530

Hi Tolga,

When we do a CER/A exchange, as per current RFC 3588 protocol, node
advertises application ids supported by that node only. It will not
consider supported application id's of its subsequent peers. CER/A
definition specifies capability negotiation confined between to nodes
and should consider the supported application of the particular node
only. i.e 
CER/A exchanged between node A and node B should bother only supported
application id's in node A and node B.

But as per my understanding from RFC (Sec 5.3 para 3), a relay will
advertise application id's supported by that relay node only (in
addition to 0xffffffff). 

Obviously we can do this by advertising App-Id only for
the applications for which the node is able to provide relaying. But I
think, it'd be better if we specify so in nex rev.

Please correct me if I'm wrong.

Thanks
-Soj.

   Note that receiving a CER or CEA from a peer
   advertising itself as a Relay (see Section 2.4) MUST be interpreted
   as having common applications with the peer.

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]] 
Sent: Tuesday, July 10, 2007 6:01 PM
To: Soji VP; [email-masked]
Subject: RE: [Dime] Backward Capability Propagation

Soj,

You should be able to do this already, i.e. advertising App-Id only for
the applications for which the node is able to provide relaying.

 Thanks,
 Tolga

________________________________________
From: Soji VP [mailto:[email-masked]] 
Sent: Tuesday, July 10, 2007 5:09 AM
To: [email-masked]
Subject: [Dime] Backward Capability Propagation

Hi Friends,

Just give a thought of having backward capability propagation feature
while exchanging capability negotiation with the peers (b/w a node and a
relay node).
As per current definitions a Diameter relay must advertise its relay
application id "0xffffffff" (also any application id relay node is
supporting) with its peers. 
But when a node is sending CER to a relay to get it's capability, relay
can always advertise union of application id's of all of its peers
(except the node which sends CER) in CEA. BCP shall be applied between
relays also (if relay chain exists).
This backward propagation will help a diameter node to ensure if it's
useful to send request or response via this particular relay and send
error message without sending message to relay if it's any of the peer
or its subsequent relay's doesn't support the application id.
This will make a node to take decision of sending messages much earlier
(by caching the capability of path to a known level). 

I'm new to dime and not sure if this is already been thought of. Ignore
in that case else let's float some comments.

Thanks & Rgds,
--soj

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

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Tue, 10 Jul 2007 10:13:22 -0700

Soji VP <mailto:[email-masked]> allegedly scribbled on Tuesday, July
10, 2007 8:17 AM:

...

> Obviously we can do this by advertising App-Id only for the
> applications for which the node is able to provide relaying. 

What happens if the one of the peers the relay is advertising on behalf
of goes down, or one or more links goes down?    What you are suggesting
is to base forwarding decisions upon a second-hand snapshot of network
connectivity that may be inaccurate as soon as it is propagated.
Diameter peers advertise only their own capabilities for a reason...

...

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 11 Jul 2007 07:24:05 -0400

Hi Soj,

That a node is called relay/proxy etc... is really more for naming
purposes. The behavior you want matches with what is called as a proxy
in the specification.

OTOH, I think what is important is procedures/on-the-wire protocol
rather than naming of nodes. The protocol allows a node to advertise
0xFFFFFFFF or specific application-Ids. What you need seems to advertise
a set of application-Ids, which is allowed by the protocol.

   Thanks,
   Tolga

> Sent: Tuesday, July 10, 2007 11:17 AM
> To: Asveren, Tolga; [email-masked]