[Gen-art] Russ's Discs on draft-ietf-pim-port [Was: Gen-ART Telechat review of draft-ietf-pim-port-09.txt]

"Adrian Farrel" <adrian@olddog.co.uk> Fri, 25 November 2011 22:04 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C3A21F8B27 for <gen-art@ietfa.amsl.com>; Fri, 25 Nov 2011 14:04:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.586
X-Spam-Level:
X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NizLuvy70jCt for <gen-art@ietfa.amsl.com>; Fri, 25 Nov 2011 14:04:05 -0800 (PST)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id CA2BD21F8B24 for <gen-art@ietf.org>; Fri, 25 Nov 2011 14:04:04 -0800 (PST)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id pAPM3wQP015907; Fri, 25 Nov 2011 22:03:58 GMT
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id pAPM3uAr015898 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 25 Nov 2011 22:03:57 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Stig Venaas' <stig@venaas.com>, 'Suresh Krishnan' <suresh.krishnan@ericsson.com>
Date: Fri, 25 Nov 2011 22:03:56 -0000
Message-ID: <00d401ccabbe$216a6ae0$643f40a0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AcyrvhSn42QivHxqRYmzB+IRCpOO4A==
Content-Language: en-gb
Cc: 'General Area Review Team' <gen-art@ietf.org>, draft-ietf-pim-port.all@tools.ietf.org
Subject: [Gen-art] Russ's Discs on draft-ietf-pim-port [Was: Gen-ART Telechat review of draft-ietf-pim-port-09.txt]
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Nov 2011 22:04:06 -0000

Hi,

This thread seems to have dried up. AFAICS there is no change needed to the
document.

Anything further to say before I ask Russ to clear his Discuss?

Thanks,
Adrian

> -----Original Message-----
> From: Stig Venaas [mailto:stig@venaas.com]
> Sent: 08 November 2011 04:02
> To: Suresh Krishnan
> Cc: draft-ietf-pim-port.all@tools.ietf.org; General Area Review Team; Russ
> Housley
> Subject: Re: Gen-ART Telechat review of draft-ietf-pim-port-09.txt
> 
> 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
> >>> 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.
> 
> 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
> anything.
> 
> Stig
> 
> > Thanks
> > Suresh