Re: [Gen-art] Gen-ART Telechat review of draft-ietf-pim-port-09.txt

Stig Venaas <> Tue, 08 November 2011 04:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E9D9011E80EA for <>; Mon, 7 Nov 2011 20:03:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id px9semGTllHB for <>; Mon, 7 Nov 2011 20:03:09 -0800 (PST)
Received: from ( [IPv6:2001:700:1:2:158:38:152:126]) by (Postfix) with ESMTP id CC93911E8096 for <>; Mon, 7 Nov 2011 20:03:08 -0800 (PST)
Received: from [] ( []) by (Postfix) with ESMTPSA id F296A8010; Tue, 8 Nov 2011 05:03:01 +0100 (CET)
Message-ID: <>
Date: Mon, 07 Nov 2011 20:02:05 -0800
From: Stig Venaas <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Suresh Krishnan <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: General Area Review Team <>, "" <>
Subject: Re: [Gen-art] Gen-ART Telechat review of draft-ietf-pim-port-09.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Nov 2011 04:03:10 -0000

On 07.11.2011 15:39, Suresh Krishnan wrote:
> 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
>>> 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.

As it says, it is done independently for IPv4 and IPv6. So in that case
you would have IPv6 PIM using SCTP, while IPv4 PIM using TCP.

You would only have connection sharing if IPv6 PIM and IPv4 PIM end up
using the same transport and same end-point addresses. This is all in
the document.

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

It says "SHOULD only initiate a connection on-demand". This means
that it is initiated if a join/prune needs to be sent. I think this
is clear enough, but note that this doesn't have to be very strict. It
is unfortunate if the one with the higher ID always tries to initiate a
connection, but there isn't much harm if it does. It wouldn't break


> Thanks
> Suresh