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

Stig Venaas <svenaas@cisco.com> Mon, 28 November 2011 17:59 UTC

Return-Path: <svenaas@cisco.com>
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 BF8B221F8D1C for <gen-art@ietfa.amsl.com>; Mon, 28 Nov 2011 09:59:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 8q3rTgV10zEK for <gen-art@ietfa.amsl.com>; Mon, 28 Nov 2011 09:59:19 -0800 (PST)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 436B521F8B05 for <gen-art@ietf.org>; Mon, 28 Nov 2011 09:59:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=svenaas@cisco.com; l=3300; q=dns/txt; s=iport; t=1322503159; x=1323712759; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=mslUgL4+r6lkj/Uvw17TDQVUBjLZ4CaKh/iopTuVDP0=; b=aiEdlIXixqlb/sBl6fuwGDK04s4Ynx+jPTraO2pJdE4+HDV4ex6d0i0x /dK3/WqPlutLE0hvbq5bPiPsM5jD2+RquDhdvAPMRYMfi4vJl2cuKHvUm ZzxoKUh/IKmcbQ7BLFdFqoIeS96bt5p243DqJOTU3ng4BpryZKBFWQppW g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhgFAJLL006rRDoI/2dsb2JhbABDqDyCL4EFgXIBAQEDARIBJS8RAQULCxgJFgQLCQMCAQIBRQYNAQcBAR6HY5hoAZ5IimIEiCGMKYVAjGw
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; d="scan'208";a="16551779"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 28 Nov 2011 17:59:16 +0000
Received: from [10.33.12.86] ([10.33.12.86]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pASHxDeu006714; Mon, 28 Nov 2011 17:59:14 GMT
Message-ID: <4ED3CBF1.9050303@cisco.com>
Date: Mon, 28 Nov 2011 09:59:13 -0800
From: Stig Venaas <svenaas@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Suresh Krishnan <suresh.krishnan@ericsson.com>
References: <00d401ccabbe$216a6ae0$643f40a0$@olddog.co.uk> <4ED1860F.3080501@ericsson.com>
In-Reply-To: <4ED1860F.3080501@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, 'General Area Review Team' <gen-art@ietf.org>, "draft-ietf-pim-port.all@tools.ietf.org" <draft-ietf-pim-port.all@tools.ietf.org>, 'Stig Venaas' <stig@venaas.com>
Subject: Re: [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
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: Mon, 28 Nov 2011 17:59:19 -0000

On 11/26/2011 4:36 PM, Suresh Krishnan wrote:
> Hi Adrian,
>
> On 11/25/2011 05:03 PM, Adrian Farrel wrote:
>> 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?
>
> I had a chat about this draft with Stig at the IETF meeting in Taipei.
> He clarified how PIM PORT connections can be shared across address
> families.
>
> I believe the following text change would resolve my concern with the draft.
>
> OLD:
> If two neighbors announce the same transport (TCP or SCTP) and the same
> Connection IDs in the IPv4 and IPv6 Hello messages, then only one
> connection is established and is shared. Otherwise, two connections
> are established and are used separately.

I guess something needs to be added. I think it is said implicitly here
since we are stating "the same ConnectionIDs in the IPv4 and IPv6"...,
also there would not be much use for the AFI in the hello option if it
was always the same as the hello itself. Anyway, I agree it should be
pointed out.

> NEW:
> If two neighbors announce the same transport (TCP or SCTP) and the same
> Connection IDs in the IPv4 and IPv6 Hello messages, then only one
> connection is established and is shared. Otherwise, two connections
> are established and are used separately.
>
> Please note that the Connection ID AFI in the PORT Hello Option does not
> need to match the address family of PIM Hello message that carries it.
> e.g. an IPv6 PIM Hello message could contain a PORT Hello Option with a
> TCP Connection ID AFI of 1 (IPv4).

While I am OK with this text, wouldn't it be better to add this to 3.1
and 3.2 where we formally define the hello options?

My proposal would be:

End of 3.1:

OLD:
    TCP Connection ID AFI:   The AFI value to describe the address-family
       of the address of the TCP Connection ID field.  When this field is
       0, a mechanism outside the scope of this document is used to
       obtain the addresses used to establish the TCP connection.

NEW:
    TCP Connection ID AFI:   The AFI value to describe the address-family
       of the address of the TCP Connection ID field. Note that this
       value does not need to match the address-family of the PIM Hello
       message that carries it. When this field is 0, a mechanism
       outside the scope of this document is used to obtain the
       addresses used to establish the TCP connection.

End of 3.2:

OLD:
    SCTP Connection ID AFI:   The AFI value to describe the address-
       family of the address of the SCTP Connection ID field.  When this
       field is 0, a mechanism outside the scope of this document is used
       to obtain the addresses used to establish the SCTP connection.

NEW:
    SCTP Connection ID AFI:   The AFI value to describe the address-
       family of the address of the SCTP Connection ID field. Note that
       this value does not need to match the address-family of the PIM
       Hello message that carries it. When this field is 0, a mechanism
       outside the scope of this document is used to obtain the
       addresses used to establish the SCTP connection.

What do you think?

Stig

> Thanks
> Suresh