Re: ENRP Name Server Takeover Problem
Qiaobing Xie <[email protected]>
| Newsgroups | gmane.ietf.rserpool |
|---|---|
| Message-ID | <[email protected]> |
Hi, Michael, Michael Tuexen wrote: > 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. 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). > > 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. This makes sense to me. regards, -Qiaobing > > 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 >> > >