Subject: Re: [Rserpool] ENRP Peer Name Update

From: Qiaobing Xie <[email-masked]>
Date: Wed, 04 Aug 2004 00:43:27 -0700

Thomas,

Thomas Dreibholz wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Dear all,
> 
> ENRP PEER_NAME_UPDATE contains the full Pool Element Parameter even in case of 
> deregistrations. ASAP DEREGISTRATION only uses a PE Identifier Parameter to 
> identify the PE. This is sufficient to identify and remove the PE. So, what 
> about defining to also use a PE Identifier parameter for deregistrations in 
> the PEER_NAME_UPDATE? That is, in case of registrations PEER_NAME_UPDATE 
> would contain a Pool Element Parameter and in case of deregistrations a PE 
> Identifier Parameter.

The advantage of using a single format for PEER_NAME_UPDATE is to make the implementation 
easier and to keep the number of messages small (remember we also have PE update in addition 
to add and remove). In the case of removal (I wouldn't call it de-reg, see below), we may 
allow the sender to only fill in the PE-id and leave other fields blank and allow the 
receiver to ignore the other fields. But I do not see the value of using different formats.

> 
> May be, it would be a good idea to split up PEER_NAME_UPDATE into a 
> PEER_NAME_REGISTRATION and PEER_NAME_DEREGISTRATION.  Then, it would be 
> consistent to ASAP's message types.

I think there is never an intention to match ASAP types here. Calling Peer-name-reg and 
peer-name-dereg is IMO misleading since the sending ENRP server is not doing a reg or de-reg 
with the receiving server. they are really updating each other.

regards,
-Qiaobing

> 
> 
> Best regards
> - -- 
> =======================================================================
>  Dipl.-Inform. Thomas Dreibholz
> 
>  University of Duisburg-Essen                    Room ES210
>  Inst. for Experimental Mathematics              Ellernstraße 29
>  Computer Networking Technology Group            D-45326 Essen/Germany
> - -----------------------------------------------------------------------
>  E-Mail:     [email-masked]
>  Homepage:   http://www.exp-math.uni-essen.de/~dreibh
> =======================================================================
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> 
> iD8DBQFBBh6932BbsHYPLWURAg7UAKC4k1L1fC4kyMB/1cxkLeksxePL+QCePM78
> uDbdR+0wptVWbmoGNv5v60c=
> =g//Z
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> rserpool mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rserpool
> 

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

---

From: Thomas Dreibholz <[email-masked]>
Date: Thu, 26 Aug 2004 11:42:56 +0200

Am Mittwoch, 4. August 2004 09:43 schrieb Qiaobing Xie:
> > ENRP PEER_NAME_UPDATE contains the full Pool Element Parameter even in
> > case of deregistrations. ASAP DEREGISTRATION only uses a PE Identifier
> > Parameter to identify the PE. This is sufficient to identify and remove
> > the PE. So, what about defining to also use a PE Identifier parameter for
> > deregistrations in the PEER_NAME_UPDATE? That is, in case of
> > registrations PEER_NAME_UPDATE would contain a Pool Element Parameter and
> > in case of deregistrations a PE Identifier Parameter.
>
> The advantage of using a single format for PEER_NAME_UPDATE is to make the
> implementation easier and to keep the number of messages small (remember we
> also have PE update in addition to add and remove). In the case of removal
> (I wouldn't call it de-reg, see below), we may allow the sender to only
> fill in the PE-id and leave other fields blank and allow the receiver to
> ignore the other fields. But I do not see the value of using different
> formats.

When a NS applies a deregistration from the namespace, it first calls a 
function to delete the NS from the namespace. Then, the information about the 
PE is gone (memory is deallocated). This implies, that the PE information has 
to be duplicated (including malloc()/new calls -> error handling becomes 
necessary) before the deregistration to be able to fill out the 
PeerNameUpdate message. It is not recommended to send PeerNameUpdates before 
deregistering the element itself from the namespace, since a deregistration 
may fail (permissions, etc.). Using only a PE ID, it is simply necessary to 
remember a 32-bit integer value (fixed-size, no malloc()/new necessary).

When parsing a Pool Element Parameter having fields set blank and things like 
pool policy and user transport missing, all procedures requiring a complete 
Pool Element Parameter have to check if the parsed parameter is valid. If we 
do *not* allow to leave fields blank and skip user transport/policy 
parameter, a pool element parameter scanner procedure can directly verify if 
it is complete. No special cases are necessary. And finally, a Pool Element 
Parameter having all fields except the ID set blank, is nothing more than a 
degenerated Pool Element Identifier Parameter.

Conclusion: Using Pool Element Parameter for ADD_PE and Pool Element 
Identifier Parameter for DEL_PE decreases the complexity of the 
implementation and is IMHO useful.

Best regards
- -- 

 University of Essen,                            Room ES210

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 27 Aug 2004 23:39:45 +0800

Thomas,

Please see below...

Thomas Dreibholz wrote:

<snip>
> remember a 32-bit integer value (fixed-size, no malloc()/new necessary).

This argument is rather implementation specific. There are another ways of implementing it 
without facing such difficulties. in fact, I didn't have this difficulty in my impl (Randy 
can testify :-).

> degenerated Pool Element Identifier Parameter.

Again, this is not a strong argument IMO. E.g., my parser allows me to get a particular TLV 
while ignoring others, so I did not have this problem. So, when I find the action is a 
deletion, I would call the parser and ask it to return me the PE Id TLV, and after that I 
may choose not to check any other TLV at all.

> implementation and is IMHO useful.

To be frank, I am not convinced that there is an implementation advantage for your proposed 
change but I do not have a strong position here and can go with either way. What do others 
think?

regards,
-Qiaobing

> iD8DBQFBLbCg32BbsHYPLWURAsGhAJ9fiMHPIJkhby16G6eETpTAD6oL/ACg2E1b
> //mzvhxT1ha19O9AfYzpXXQ=
> =u2dq

---

From: Thomas Dreibholz <[email-masked]>
Date: Fri, 27 Aug 2004 18:32:13 +0200

Am Freitag, 27. August 2004 17:39 schrieb Qiaobing Xie:
> > function to delete the NS from the namespace. Then, the information about
> > the PE is gone (memory is deallocated). This implies, that the PE
> > information has to be duplicated (including malloc()/new calls -> error
> > handling becomes necessary) before the deregistration to be able to fill
> > out the
> > PeerNameUpdate message. It is not recommended to send PeerNameUpdates
> > before deregistering the element itself from the namespace, since a
> > deregistration may fail (permissions, etc.). Using only a PE ID, it is
> > simply necessary to remember a 32-bit integer value (fixed-size, no
> > malloc()/new necessary).
>
> This argument is rather implementation specific. There are another ways of
> implementing it without facing such difficulties. in fact, I didn't have
> this difficulty in my impl (Randy can testify :-).

Yes, it is possible. But IMHO, it requires more effort than simply using a PE 
Identifier parameter. In this case, you would simply scan for the PE 
Identifier Parameter instead of scanning for the Pool Element Parameter and 
looking there for the PE ID itself.

> > When parsing a Pool Element Parameter having fields set blank and things
> > like pool policy and user transport missing, all procedures requiring a
> > complete Pool Element Parameter have to check if the parsed parameter is
> > valid. If we do *not* allow to leave fields blank and skip user
> > transport/policy parameter, a pool element parameter scanner procedure
> > can directly verify if it is complete. No special cases are necessary.
> > And finally, a Pool Element Parameter having all fields except the ID set
> > blank, is nothing more than a degenerated Pool Element Identifier
> > Parameter.
>
> Again, this is not a strong argument IMO. E.g., my parser allows me to get
> a particular TLV while ignoring others, so I did not have this problem. So,
> when I find the action is a deletion, I would call the parser and ask it to
> return me the PE Id TLV, and after that I may choose not to check any other
> TLV at all.

But a parser should check if the complete message is valid and not malformed. 
For example a Pool Element Paramter is defined in the common parameters draft 
to be containing e.g. a user transport parameter and a policy parameter. When 
e.g. there is no user transport parameter or it contains no addresses etc., 
the message is IMHO malformed and should not be processed.

When only a PE identifier has to be specified, a Pool Element Identifier 
Parameter should be used. This parameter encapsulates the information 
necessary and requires nothing more, therefore it also more consistent. Why 
using a full Pool Element Parameter when a PE Identifier Parameter is 
sufficient?

Best regards
- --