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

Hi Magnus,

Thank you very much for the detailed comments!  

Looking them over quickly it seems to me that the main comment is that
the documents are not clear on where ASAP is used vs. ENRP and how to
distinguish between the two.  In some cases there is text in ENRP
that applies to ASAP. 

Also, you have a number of comments on the use of multicast, plus many
questions for clarification. 

Looks like we have some work to do!

Cheers,

Lyndon

-----Original Message-----
From: Magnus Westerlund [mailto:[email protected]] 
Sent: Tuesday, October 16, 2007 9:38 AM
To: [email protected]
Subject: [Rserpool] AD comments on draft-ietf-rserpool-enrp-17,
draft-ietf-rserpool-asap-17, draft-ietf-rserpool-common-param-13

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.

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.

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.

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?

A2. Section 7.2: Also what is the security solution for multicast.

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.

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.

A5. Section 2.2.5: There is a no explanation of how one turns of dynamic
updates.

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.


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"?

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?

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.

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.

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?

A12. Section 6. IPv4 and IPv6 Multicast addresses and ports to be used
for the ASAP_SERVER_ANNOUNCE?

ENRP:

E1. Section 1.1: ENRP Client channel: "multi-cast" used.

E2. I don't think it is clear if ENRP ID and PE ID space is the same
space or two separate.

E3. Section 2.3: "Each pool entry MUST start with a
         Pool Handle parameter as defined in section 3.1.7"

There is no section 3.1.7 in this document.

E4. Section 2.3: What I don't understand is why the Pool Entry format
isn't a TLV in itself with the sub TLVs so that one can skip all the PEs
to the next Pool Entry.

E5. I think the ENRP spec is missing the text about 32-bit alignment and
padding that is present in ASAP.

E6. TAKEOVER: I am bit frightened that a malicious server that ignore
ENRP_PRESENCE message can force a takeover. No one can protest a single
bit. I also find it strange that there is no "R"eject bit in the
ENRP_INIT_TAKEOVER_ACK. If two servers that initiated takeover at the
sametime reach each other there are no way to indicate that you are the
looser and I reject your initiation because I am the winner.  See also
below.

E7. Section 3.2.2.1: The SHOULDs in the numbered list is a bit strange.
I think one has the alternative to use this procedure or not, which the
SHOULD prior to the list makes sense. However, having SHOULDs in this
list is strange.

E8. Section 3.2.2.2 second last paragraph page 22-23:

  "If this timer expires
   without receiving a response from the mentor peer, the initiating
   server SHOULD abort the current download session and re-start a new
   handlespace download with a backup mentor peer, if one is available."

How does on abort the current download session?

E9. Section 3.3: I think it is totally inappropriate to have normative
ASAP procedures in the ENRP document. If you need this write about it
informative and ensure that the normative description is available in
the ASAP document.

E10. Section 3.3, first paragraph on page 25. "????" section reference.

E11. Section 3.4: similar issue as with 3.3, it seems that only the last
paragraph is what is really needed. So some simpler informative text
before that is needed to provide the context.

E12. Section 3.5 contains more inappropriate normative text.

E13. Section 3.5, second last paragraph on page 26, "Unknown poor
handle"

E14. Section 3.7: Also questionable if this belongs in this spec or not.

E15. Section 3.7, second paragraph: I think one should add the
requirement to check that the PE that one gets ASAP_ENDPOINT_UNREACHABLE
for still is in ones database.

E16. Section 3.7: First paragraph page 29:
"ASAP_ENDPOINT_UNREACHABLE messages it has received reporting
   reachability problem relating to this PE.  If the counter exceeds the
   protocol threshold MAX-BAD-PE-REPORT, the ENRP server SHOULD remove
   the PE from its handlespace and take actions described in
   Section 3.6.2."

I am missing a time period for this BAD PE report counter. There is a
big difference if one receives 3 reports during a week or during 1
minute.

E17. Section 3.8: Last sentence has ?? in Section reference.

E18. Section 3.10.1: Second paragraph: It is unclear if one tries to
send the ENRP_INIT_TAKEOVER to the target also.

E19. Section 3.10.1, bullet 1:
" The initiating server MUST stop the takeover operation."

How does it stop the takeover process?

E20. Section 3.10.1, bullet 2A:
Also in this case does one wonder how one aborts the takeover.

E21. Section 3.10.1: Last paragraph on page 31: "_all_" is not valid
"markup" characters for IETF drafts.

E22, section 3.10.2: How long is the TAKEOVER_ACKS valid? I guess there
is an assumption that the Initiating server will send an enforcement as
soon as it has received ACKs from all other.

E23. Multicast bandwidth sending rules. Needs a way to control this that
scales.

E24. Section 5.3: I assume that there should be both IPv4 and IPv6
addresses registered. Please be explicit.

E25. Section 5: Well known Port registration for ENRP?

E26. Section 6.2: Multicast security solution?

COMMON:

C1. Page 6: There is a editors note that should be removed.

C2. Section 3.3: Is it a SCTP limitation that there needs to be the same
port on all the interfaces or this a limitation created in this
document? Will not this be problematic to get the same port over all
interfaces?

C3. Section 3.3, 3.4, 3.5: Probably a question for the utilizing
protocols. Are it is possible to have multiple transport parameters of
the same type, for example to provide both IPv4 and IPv6 addresses?

C4. Any considerations for UDP-Lite or DCCP transport parameters?

C5. Section 3.6: "   The enforcement rules and handling procedures of
all the policies are defined in Section xxxxx in ASAP [3]."

This is only one of several occurances of "xxxxx" or "????" where there
should be a section number from the other specs. Please look through all
the documents for this type.

See also Section 3.9, Server ID
Section 3.12: last paragraph

C6. Section 3.8: Registration life: I am missing a time reference here.
>From when does the time count? Wouldn't it be better with a NTP time or
something else? The current construct clearly requires a receiver to at
least take a clock time and then save arrival time or combine the two
into an expiration time for the entry.

C7. Section 3.9:

Multicast flag: In what direction that this flag apply? For the sender
or the receiver?

C8. Section 3.10, Figure 16:

I would call this first a figure with the TLV and then the Cause Code
value to cause code list for a "Table". It is a bit confusing.

C9. Section 3.10.2: Can multiple be unrecognized parameter TLVs be
included in this?

C10. Section 6. I am missing a security analysis bringing up any issues
in the parameters themselves.

-- 

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


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