Re: AD comments on draft-ietf-rserpool-enrp-17, draft-ietf-rserpool-asap-17, draft-ietf-rserpool-common-param-13
Michael Tuexen <[email protected]> Tue, 20 Nov 2007 18:36:27 +0100
| Newsgroups | gmane.ietf.rserpool |
|---|---|
| Message-ID | <[email protected]> |
Hi Magnus, see my comments in-line. Best regards Michael On Nov 20, 2007, at 4:58 PM, Magnus Westerlund wrote: > I have reviewed the changes. Some comments and unfortunately I think > some few additional fixes are needed. No problem, since they improve the document they are welcome! > > > > 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. That is possible. But using the Multicast messages is completely optional. They are not secured by IPSec or TLS so you can not trust them... So what are you expecting here? A sentence or two in the security considerations describing the above? > > > >>> >>> >>> 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. I'm not sure what you want here. If you look at http://www.iana.org/assignments/port-numbers and search for asap you will find: # Yoshikazu Watanabe <nabe&sm.sony.co.jp> asap-tcp 3863/tcp asap tcp port asap-udp 3863/udp asap udp port # Lyndon Ong <lyong&ciena.com> August 2003 asap-sctp 3863/sctp asap sctp # Lyndon Ong <lyong&ciena.com> November 2005 asap-tcp-tls 3864/tcp asap/tls tcp port # Lyndon Ong <lyong&ciena.com> August 2003 asap-sctp-tls 3864/sctp asap-sctp/tls # Lyndon Ong <lyong&ciena.com> June 2006 and for enrp enrp 9901/udp enrp server channel enrp-sctp 9901/sctp enrp server channel # Lyndon Ong <lyong&ciena.com> June 2006 enrp-sctp-tls 9902/sctp enrp/tls server channel # Lyndon Ong <lyong&ciena.com> June 2006 If I look at other entries in the document I do not see references to RFCs. So would it be enough to just list these assignments in the IANA section? I guess that we should also list the PPID assignments and request an update for the reference in http://www.iana.org/assignments/sctp-parameters SCTP Payload Protocol Identifiers Reference -------------------------------------------------------- --------- 0 - Reserved by SCTP [RFC4960] 1 - IUA [RFC4233] 2 - M2UA [RFC3331] 3 - M3UA [RFC4666] 4 - SUA [RFC2960] 5 - M2PA [RFC2960] 6 - V5UA [RFC2960] 7 - H.248 [H.248] 8 - BICC/Q.2150.3 [Q.1902.1] [Q.2150.3] 9 - TALI [RFC3094] 10 - DUA [RFC4129] 11 - ASAP <draft-ietf-rserpool-asap-03.txt> [Ong] 12 - ENRP <draft-ietf-rserpool-enrp-03.txt> [Ong] 13 - H.323 [H.323] 14 - Q.IPC/Q.2150.3 [Q.2631.1] [Q.2150.3] 15 - SIMCO <draft-kiesel-midcom-simco-sctp-00.txt> [Kiesel] 16 - DDP Segment Chunk [RFC5043] 17 - DDP Stream Session Control [RFC5043] Do you agree? > > >>> >>> >>> 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. OK, I need to figure out what we want here... > > > 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] > ---------------------------------------------------------------------- > > > _______________________________________________ > rserpool mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/rserpool >