Hi Stig,
On 11/03/2011 02:28 PM, Stig Venaas wrote:
Thanks for the review, see below.
On 11/1/2011 4:18 PM, Suresh Krishnan wrote:
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document: draft-ietf-pim-port-09.txt
Reviewer: Suresh Krishnan
Review Date: 2011/11/01
IESG Telechat date: 2011/11/03
Summary: This document is almost ready for publication as an
Experimental RFC but I have a few comments.
Minor
=====
Section 3.1
* From my reading of the document, it is not clear whether we can have a
node advertise multiple capability options of the same transport
protocol (say PIM-over-TCP-Capable) in the same message. e.g. A dual
stack node might want to advertise its capability to do both IPv4 and
IPv6. Is this possible? If so, how?
For PIM we generally (not just PORT) use Hello Options in IPv4 PIM
Hello's for IPv4 capabilities and Hello Options in IPv6 PIM Hello's
for IPv6 capabilities. The two are completely separate.
If a router supports PORT for both IPv4 and IPv6, it will send one
option in the IPv4 Hello, and another in the IPv6 Hello.
In section 4 it says:
The decisions whether to use PORT, which transport, and which
Connection IDs to use are performed independently for IPv4 and
IPv6. Thus, if PORT is used both for IPv4 and IPv6, both IPv4 and
IPv6 PIM Hello messages MUST be sent, both containing PORT Hello
options.
I think this is pretty clear.
That clarifies a bit, but I am still unclear as to how the protocol
selection takes place. e.g. Does IPv6+SCTP take precedence over IPv4+TCP.
Section 4.7
* Section 4 talks about the router with the lower connection ID
initiating the transport layer connection but this does not really map
into the rules mentioned in Section 4.7. Specifically, I am not sure
Rule 3 for Node A in Section 4.7 conveys the same intent as section 4.
Note that we also allow doing connections on-demand. In that case they
one with the higher address may open a connection. That is the reason
for rule 3.
See end of section 4.5 where it says:
Note that for TCP, it is the router with the lower Connection ID that
decides whether to open a connection immediately, or on-demand. The
router with the higher Connection ID SHOULD only initiate a
connection on-demand. That is, if it needs to send a Join/Prune
message and there is no currently established connection.
Do you still think something is not clear?
The text only describes the when it is *acceptable* for a router with a
higher connection ID to initiate a connection, not when it should
*actually* do so. Specifically section 4.7 should cover this.
Thanks
Suresh
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
