Subject: [Rserpool] ENRP Name Server Takeover Problem

From: Thomas Dreibholz <[email-masked]>
Date: Mon, 23 Aug 2004 14:11:02 +0200

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-masked]
 Homepage:   http://www.exp-math.uni-essen.de/~dreibh
=======================================================================

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

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 26 Aug 2004 14:09:30 +0800

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,
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> 
> iD8DBQFBKd7Z32BbsHYPLWURAtToAKCrnGWS5cBOmqv/PNXPvkxKxVhWEACeNaM2
> rLi5vLWX8fIYJ9py+2iO1MA=
> =T53y
> -----END PGP SIGNATURE-----
>

---

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

Am Donnerstag, 26. August 2004 08:09 schrieb Qiaobing Xie:
> 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.

Yes, this is the best solution.

The "ASAP Transport Parameter" should be an optional SCTP Transport Parameter, 
to be appended to the end of the "Pool Element Parameter" in the common 
parameters draft. For ASAP (Registration), there should be no such parameter 
(the home NS has to find out the peer addresses anyway, therefore the NS 
itself can fill this information into the namespace). For ENRP 
(PeerNameUpdate and PeerNameTableResponse), this parameter has to be 
mandatory.

Best regards
- --

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 26 Aug 2004 12:14:20 +0200

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:

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

---

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

Hi, Michael,

> So I'm suggesting to modify the PE parameter to

Yes, I agree. But the ASAP Trans Param probably need to have its own type/length with its 
data an SCTP trans param. Otherwise you won't be able to receive it if the order is allowed 
to be flexible (as you suggest below).

> to state that somewhere ... after agreeing on a way to handle that.

This makes sense to me.

regards,
-Qiaobing

>> restrictive since some PEs may want to use a separate NIC for its 
>> ASAP  communications.
>>
>> regards,
>> -Qiaobing
>>
>> Thomas Dreibholz wrote:
>>
>>> 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
>>> - --  
>>> ====================================================================== =
>>> ---------------------------------------------------------------------- -
>>> ====================================================================== =

---

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

> sequences also acceptable?

PeerOwnershipChange for example requires a sequence (PE Identifier Parameter 
belong to the pool specified by the latest Pool Handle Parameter). Therefore,
it is consistent to make the order mandatory.

Best regards
- --