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

I have reviewed the changes. Some comments and unfortunately I think
some few additional fixes are needed.


Michael Tuexen skrev:
> 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.

Thanks, this makes this clear.

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

Yes, that should resolve it.

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

Okay, then it maybe should be explicit about that the multicast messages
are not at all trustworthy. I am also worried that one basically can
inject a lot of server announcement messages and that way push the valid
servers into minority so that a client will try all this invalid servers
and never find a valid one.


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

Sure, I can live with it.

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

Ok.

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

Ok, the changes solves this.


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

Please include in the IANA section a listing of the well known ports
that have been assigned. I also think you should include a request to
update the reference for these ports to this document.

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

I think you need to expand on this request to correctly request the type
of multicast address you like. Please see RFC 3171.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email protected]
----------------------------------------------------------------------