IETF Logo Mail Archive

RE: draft-ietf-mboned-64-multicast-address-format

"Manfredi, Albert E" <albert.e.manfredi@boeing.com> Fri, 04 May 2012 19:29 UTC

Return-Path: <albert.e.manfredi@boeing.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED06311E8080; Fri, 4 May 2012 12:29:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.023
X-Spam-Level:
X-Spam-Status: No, score=-6.023 tagged_above=-999 required=5 tests=[AWL=-3.425, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 9I+Y3TMYLfa3; Fri, 4 May 2012 12:29:34 -0700 (PDT)
Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 6268611E8072; Fri, 4 May 2012 12:29:34 -0700 (PDT)
Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q44JTXed005546; Fri, 4 May 2012 12:29:33 -0700
Received: from blv-relay-01.boeing.com (blv-relay-01.boeing.com [130.247.16.37]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q44JTWHi005538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 4 May 2012 12:29:33 -0700
Received: from blv-relay-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-relay-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q44JTW9R027014; Fri, 4 May 2012 12:29:32 -0700
Received: from XCH-MWHT-01.mw.nos.boeing.com (xch-mwht-01.mw.nos.boeing.com [134.57.113.35]) by blv-relay-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q44JTVFX026958 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 4 May 2012 12:29:32 -0700
Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.119.191]) by XCH-MWHT-01.mw.nos.boeing.com ([134.57.113.35]) with mapi; Fri, 4 May 2012 14:29:32 -0500
From: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "mboned-chairs@ietf.org" <mboned-chairs@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
Date: Fri, 04 May 2012 14:29:30 -0500
Subject: RE: draft-ietf-mboned-64-multicast-address-format
Thread-Topic: draft-ietf-mboned-64-multicast-address-format
Thread-Index: Ac0p9HxleWTdQ5BUQkuVPrhA9CFoFwANhJxA
Message-ID: <B0147C3DD45E42478038FC347CCB65FE02BB8BA441@XCH-MW-08V.mw.nos.boeing.com>
References: <94C682931C08B048B7A8645303FDC9F36E299468D7@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E299468D7@PUEXCB1B.nanterre.francetelecom.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_B0147C3DD45E42478038FC347CCB65FE02BB8BA441XCHMW08Vmwnos_"
MIME-Version: 1.0
X-TM-AS-MML: No
Cc: "draft-ietf-mboned-64-multicast-address-format@tools.ietf.org" <draft-ietf-mboned-64-multicast-address-format@tools.ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 May 2012 19:29:36 -0000

I don't know why IPv6 becomes more arcane with every new I-D. Why not work to make it simpler, rather than more complex and confusing, with every new iteration?

In this particular case, it is really confusing to change the location of this new field, 64IX, depending whether it's ASM or SSM. And I might suggest to drop the 64IX nibble altogether. Use the remaining bit of the flgs field instead of the M bit of the 64IX field, and then allow for different combinations of the flgs bits for future codes?

Bert

From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: Friday, May 04, 2012 8:50 AM
To: mboned-chairs@ietf.org; ipv6@ietf.org
Cc: Brian Haberman; draft-ietf-mboned-64-multicast-address-format@tools.ietf.org
Subject: draft-ietf-mboned-64-multicast-address-format

Dear all,

During the IETF LC for draft-ietf-mboned-64-multicast-address-format, Brian suggested to use the remaining flag instead of reserving ff3x:0:8000/33 (SSM) and ffxx:8000/17 (ASM) blocks. FYI, we have considered that approach in an early version of the document but it has been abandoned because of comments we received at that time. We recorded the rationale behind our design choice in:
http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-01#appendix-A.2.

We are seeking more feedback from 6man and mboned on the following:

(1) Should we maintain the current design choice
(2) Or adopt the suggestion from Brian?

FWIW, discussion related to this issue can be found here: http://www.ietf.org/mail-archive/web/mboned/current/msg01508.html.
The latest version of the draft is available at: http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-01

Your help is appreciated.

Cheers,
Med

v2.23.0 | Report a Bug | By Email