Re: AD comments on draft-ietf-rserpool-enrp-17, draft-ietf-rserpool-asap-17, draft-ietf-rserpool-common-param-13

Hi Magnus,

please see my comments regarding the ASAP document in-line. Please
note that my comments are based on a telephone conference between
the authors.

A new version addressing all your comments has been uploaded and
is available at
http://www.ietf.org/internet-drafts/draft-ietf-rserpool-asap-18.txt

I'll remove text from your mail not related to ASAP.

Best regards
Michael

On Oct 16, 2007, at 6:37 PM, Magnus Westerlund wrote:

> Hi,
>
> I will bring up all my comments on the core protocol specs in this
> email. I will do my best to keep it structured.
>
> Generally:
>
> G1. There is some confusion over text and where it is defined. I think
> the document would benefit from trying to be more clear on what is  
> used
> in what communications scopes. It is also important to be clear on  
> when
> one is referring to a process in another scope that result in a
> procedure in the scope one currently describes.
>
> I think the specs may need to clarify what needs to be implemented by
> what type of entity. For example the PUs implementation burden is  
> quite
> different from a PE or a ENRP server.
A new section "Roles of Endpoints" has been added to clarify this.
>
>
> G2. At least to me it there are some confusion on how one identifies
> what type of messages are arriving on a server. To my understanding  
> this
> is done by well known ports and also the PPID in SCTP. But this is
> confusing but quite important as the message type space are  
> overlapping
> so the receiver must know which protocol to expect.
A new section "SCTP considerations" has been added to clarify this.
>
>
> G3. I think that section 1, should contain some text on practices used
> in this spec. One is the constants and variables used without
> explanation until one have come through the whole text.
We have added text to section 1 which refers to section 5.
>
>
> ASAP:
>
> A1. Section 3.6: The usage of multicast is very unclear. It seem to be
> very underspecified. For example how does one control the rate of ASAP
> multicasted requests? This seem to be strictly timer based so the
> bandwidth will depend on the number of ENRP servers. So how can one
> congestion control the ENRP to PEs announcement traffic?
We have added text that an ENRP Server sends out a multicast message
every (N+1) * T6, where N is the number of detected ENRP servers.
Therefore there should only be approx. one message every T6.
>
>
> A2. Section 7.2: Also what is the security solution for multicast.
Not sure what the problem is... The receiver should trust the  
information
in the received multicast message the same way as preconfigured  
information.
It gets an address which might or might no belong to a trustworthy
ENRP server. Other mechanisms have t be used for authentication.
>
>
> A3. Section 3.6:
>  "If multicast capabilities are used within the operational scope an
>   ENRP server MUST send periodically every T6-Serverannounce an
>   ASAP_SERVER_ANNOUNCE message (Section 2.2.10) which includes all the
>   transport addresses available for ASAP communication on the  
> multicast
>   ENRP client channel."
>
> Which ASAP communication are there transport addresses available in  
> the
> ASAP_SERVER_ANNOUNCE message? To my understanding this is for the
> PE-ENRP communciation.
and for the PU<-> ENRP Server communication.
>
>
> A4. PE ID uniqueness. The text somewhere says that there are no  
> serious
> issue with having two PE pick the same ID. However, it clearly affects
> the pool performance as only one will be able to provide service at  
> any
> given point. And as I understand it they will be performing a tug of  
> war
> around whos values will be registered. I still think that you should
> have implemented a mechanism identifying this and have the PEs draw a
> new PE ID and reregister.
>
This has been discussed a long time ago and the decision was to do
it like it is now...
The collision is not likely, but it can happen. When it happens the
PE which registers later takes over new PU from the old one. No big
deal. It would be much harder to synchronize the ID over the pool.
So for simplicity, we decided just to be able to handle the collision
with no critical consequences.
> A5. Section 2.2.5: There is a no explanation of how one turns of  
> dynamic
> updates.
Dynamic updates happen as long as the SCTP stays up. Text has been added
to specify this.
>
>
> A6. Section 3: "(or equivilant mapped
>   function if using TCP)."
>
> As this can't be a general function, maybe there should be better
> explanation on what type of demultiplexing is needed on a joint data  
> and
> control channel between server and client.
We just removed the TCP mapping.
>
>
>
> A7. Section 3.1: "      R2.3)  Fill in the Registration Life time
> parameter with the
>         number of seconds that this registration is valid for.  Note a
>         PE that wishes to continue service MUST re-register after the
>         registration expires."
>
> Shouldn't "after" in the last sentence be "before"?
Done.
>
>
> A8. Section 3.3: How does one know how long a cache entry is valid?  
> For
> most other protocols it is the serving entity that indicate the  
> validity
> when caching, rather than local policy. Also isn't the stale timer
> associated with the entry rather than the whole cache?
>
The impact of cache-usage depends on the application and policy. I have
added text to state this. I also changed the text that the timer is
for an cache-entry.
> A9. Section 3.5:
>
> How does a PU/PE find the home ENRP server for a particular PE? To my
> understanding the PU/PE only has the ID of the ENRP server, not the
> address. Please include the necessary step to map the ID to an  
> address.
The PU/PE can send the message to any ENRP server. Therefore the  
function
you are talking about is not needed. I clarified the text.
>
>
> A10. Section 3.8, third paragraph:
> "If the PU's ASAP endpoint detects a failure and initiates a failover
>   to a different PE, it SHOULD send the lastest received cookie
>   parameter in an ASAP_COOKIE_ECHO message to the new PE."
>
> When should it send that cookie? Please specify in what protocol  
> step it
> should happen.
The cookie is sent as the first message on the control channel. The
text has been clarified.
>
>
> A11. Section 6:
>
> ASAP well known port registration? Is this not needed as the ENRP
> protocol will always provide the port? Is that true both for PE and  
> ENRP?
Well, only if multicast is used. In the other case, the well known port
is used.
>
>
> A12. Section 6. IPv4 and IPv6 Multicast addresses and ports to be used
> for the ASAP_SERVER_ANNOUNCE?
We already have port numbers assigned by IANA. So we need only multicast
addresses. I have added a sentence about this.