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

Stig Venaas <> Thu, 03 November 2011 18:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 99C2711E8107 for <>; Thu, 3 Nov 2011 11:28:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6ijS0+V5Tysd for <>; Thu, 3 Nov 2011 11:28:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A99B411E8083 for <>; Thu, 3 Nov 2011 11:28:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2616; q=dns/txt; s=iport; t=1320344912; x=1321554512; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Do07VSif9/Z4JkGG/g2uz86upPHZ7eXs4PYZhSdYF2Q=; b=kMzzW8nrt8vnf+M2Xu4NwoQzfYx9NlNbVvHK0qQv8AR9FtJISE9TGRdx 5u/LW8YCDvxgy9ZSyO5W/6AdPDTya+/dQPxBD6EydughBesllFd5jCJbD ke/9BjFDe19P6T5RJ70AauusjHLkgNntjkibNx1G3OJP+652iDNZoCET0 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.69,451,1315180800"; d="scan'208";a="10783994"
Received: from ([]) by with ESMTP; 03 Nov 2011 18:28:32 +0000
Received: from [] ([]) by (8.14.3/8.14.3) with ESMTP id pA3ISVZS010085; Thu, 3 Nov 2011 18:28:32 GMT
Message-ID: <>
Date: Thu, 03 Nov 2011 11:28:31 -0700
From: Stig Venaas <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; 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
X-Mailman-Approved-At: Thu, 03 Nov 2011 11:47:05 -0700
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: Thu, 03 Nov 2011 18:28:33 -0000

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

I think this is pretty clear.

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


> Thanks
> Suresh