Re: ENRP Name Server Takeover Problem

Qiaobing,

I discussed this with Thomas yesterday on the phone and we came to
the same conclusion. Since this ASAP Transport Param is not required
for registration it should be an optional parameter, I think.

So I'm suggesting to modify the PE parameter to

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Type = 0x8            |       Length=variable         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         PE Identifier                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Home ENRP Server Identifier                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Registration Life                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                      User Transport param                     :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                 Member Selection Policy param                 :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                       ASAP Transport param                    :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

and the ASAP transport parameter
- MUST be an SCTP transport parameter
- is optional.

Do you agree on that? If yes, I can update the common parameter doc.

Another point came up on the discussion with Thomas. It is regarding
the sequence of TLV fields in parameters/messages. Is the sequence
required to be the one shown in the documents or are other
sequences also acceptable?
I would argue that they should be sent like they are shown, but the
receiver should accepts them also in other orderings. But we have
to state that somewhere ... after agreeing on a way to handle that.

Best regards
Michael


On Aug 26, 2004, at 8:09 AM, Qiaobing Xie wrote:

> Thomas,
>
> This makes a lot of sense to me. My recommendation is to add a "ASAP  
> Transport Param" field to the PE parameter that is a full SCTP  
> transport TLV. Simply adding a SCTP port number field may be too  
> restrictive since some PEs may want to use a separate NIC for its ASAP  
> communications.
>
> regards,
> -Qiaobing
>
> Thomas Dreibholz wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> Dear all,
>> when a NS takes over the ownership of PEs owned by a failed NS, it  
>> sends an ENDPOINT_KEEP_ALIVE message to each of the PEs which change  
>> their ownership. As defined in KA2.4 of section 3.4 of the ASAP  
>> draft, the PE should adapt the sender of an ENDPOINT_KEEP_ALIVE  
>> message as its new NS.
>> But, how does the new NS know the PEs' ASAP endpoint, that is  
>> especially the SCTP port number the PE is listening on for ASAP  
>> ENDPOINT_KEEP_ALIVES? The old (failed) NS has this information,  
>> because the PE established an association to it. But the new NS does  
>> not know. Therefore, a specification of the PE's ASAP endpoint must  
>> be added to the Pool Element Parameter. Simply adding a field for the  
>> SCTP port number should already be sufficient. The addresses to be  
>> used can be assumed to be the same as specified in the User Transport  
>> parameter.
>> 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)
>> iD8DBQFBKd7Z32BbsHYPLWURAtToAKCrnGWS5cBOmqv/PNXPvkxKxVhWEACeNaM2
>> rLi5vLWX8fIYJ9py+2iO1MA=
>> =T53y
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> rserpool mailing list
>> [email protected]
>> https://www1.ietf.org/mailman/listinfo/rserpool
>
>
> _______________________________________________
> rserpool mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rserpool
>