Re: ENRP Peer Name Update

Thomas,

Please see below...

Thomas Dreibholz wrote:

<snip>
>>>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).

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 :-).

> 
> 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.

> 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.

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

> 
> 
> Best regards
> - -- 
> =======================================================================
>  Dipl.-Inform. Thomas Dreibholz
> 
>  University of Essen,                            Room ES210
>  Inst. for Experimental Mathematics              Ellernstraße 29
>  Computer Networking Technology Group            D-45326 Essen/Germany
> - -----------------------------------------------------------------------
>  E-Mail:     [email protected]
>  Homepage:   http://www.exp-math.uni-essen.de/~dreibh
> =======================================================================
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> 
> iD8DBQFBLbCg32BbsHYPLWURAsGhAJ9fiMHPIJkhby16G6eETpTAD6oL/ACg2E1b
> //mzvhxT1ha19O9AfYzpXXQ=
> =u2dq
> -----END PGP SIGNATURE-----
>