Subject: [Rserpool] [ASAP] Questions on messages & PE/endpoint identification

From: Karl Knutson <[email-masked]>
Date: Tue, 17 Jul 2001 18:11:50 -0500 (CDT)

Here are a couple of questions about (related) ASAP messages and
PE/endpoint identification:

1.  UPDATE_POLICY_VALUE

In the UPDATE_POLICY_VALUE message (Section 3.8), the "New policy
value" takes up 4 bytes, but in the PE Parameter Definition (Section
3.1), the "Policy Value" takes up 2 bytes.  Is there padding in the
UPDATE_POLICY_VALUE message?

Further, since there is a PE Parameter in the UPDATE_POLICY_VALUE
message, would it be possible to just update the "Policy Value" in the
PE Parameter?

(I can think of a reason not to do this, that the PE Parameter is used
to look up the relevant PE in the namespace so changing it (in the PE
Parameter) would ironically prevent changing it (in the namespace).)

2.  ENDPOINT_UNREACHABLE

In the ENDPOINT_UNREACHABLE message (Section 3.10), a SCTP transport
address (IP address and SCTP port) is provided to identify the
relevant endpoint (PE).  The question is that since we use a whole PE
Parameter in UPDATE_POLICY_VALUE, should we use a PE Parameter here?

Or, if a SCTP transport address fully identifies an endpoint (PE, in
this case), should we only use that in the UPDATE_POLICY_VALUE
message?

Karl
--
Karl O. Knutson                  
[email-masked]
[email-masked]
+1.847.372.6629 (cell)

_______________________________________________
rserpool mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/rserpool

---

From: Randall Stewart <[email-masked]>
Date: Tue, 24 Jul 2001 08:05:00 -0500

> UPDATE_POLICY_VALUE message?

No, this is a bug in the spec... not sure how it came to be
but in looking around a bit the policy value was always a 32 bit
u-long... the policy type was just a character... somehow or
another we had a bug creep in here... we will have to fix it in the
message clean up :)

> message, would it be possible to just update the "Policy Value" in the

Yes, I think this is dooable once we fix the above bug :)

> Parameter) would ironically prevent changing it (in the namespace).)

Really the other fields in the PE Parameter should be
used to find the PE. Even when doing a hash of the PE one would
presumably only use the IP address and port... I think your
suggestion is safe (once the spec bug is fixed).

> Parameter in UPDATE_POLICY_VALUE, should we use a PE Parameter here?

Hmm. I guess this would be an alternative... problem I see is that
the policy value is always how I have currently calculated it.. remembre
once I referesh a policy from an ENRP server I may (depending on
type of pooling policy) be changing these values... i.e. in a
least used degrading every time I select a PE I add 1 to the policy
value. This really means .. I think.. that we shoudl take the
policy value (and maybe even the policy) out of the PE parameter...
hmm... lets attack this as part of the message restructure...

> this case), should we only use that in the UPDATE_POLICY_VALUE

I think that we need to fix the PE parameter i.e. maybe get this
policy value and policy type out of it...

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)