Subject: RE: [Dime] Backward Capability Propagation

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Wed, 11 Jul 2007 00:07:53 -0700

Soji VP <mailto:[email-masked]> allegedly scribbled on Tuesday, July
10, 2007 10:20 PM:

> Hi Glen,
> 
> CER/A should be confined only between peers and it should exchange
> capabilities of the node. But still, when one of the peers the relay
> is advertising on behalf goes down, the relay has to exchange a CER/A
> with rest of the peers with its updated capability. 

We are talking about relays, here, right?  They advertise that they will
relay anything they get, they specifically do not advertise on behalf of
any other node.  What you're suggesting seems to add a lot of complexity
for little (to be generous) benefit.
  
> 
> I agree the point that it would be inaccurate as soon as the
> connectivity gets propagated, but the same situation would be
> persisting now also; consider a case, where peer removed it's
> supported application and a node send a message to that peer before
> updated capability being negotiated to the node. In this case, little
> inaccuracy exists atleast for one hop connectivity.     
> 
> I'd appreciate any comments on this.
> 
> Thanks,
> Soj
> 
> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:[email-masked]]
> Sent: Tuesday, July 10, 2007 10:43 PM
> To: Soji VP
> Cc: Asveren, Tolga; [email-masked]
> Subject: RE: [Dime] Backward Capability Propagation
> 
> 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...
> 
> ...

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

---

From: "harish raghuveer" <[email-masked]>
Date: Wed, 11 Jul 2007 12:57:28 +0530

Soji: I tend to agree with Glen. This can be a scaling bottleneck at relays.

cheers,
Harish

-- 
Harish R Prabhu
Bangalore, India.