Re: [Softwires] 6rd RADIUS attribute - grouped attributes

Peter Deacon <peterd@iea-software.com> Thu, 22 December 2011 12:07 UTC

Return-Path: <peterd@iea-software.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E03921F8B59 for <softwires@ietfa.amsl.com>; Thu, 22 Dec 2011 04:07:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 yEzomPgLUm+V for <softwires@ietfa.amsl.com>; Thu, 22 Dec 2011 04:07:50 -0800 (PST)
Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8B321F8B4E for <softwires@ietf.org>; Thu, 22 Dec 2011 04:07:50 -0800 (PST)
Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id <B0005782065@aspen.internal.iea-software.com>; Thu, 22 Dec 2011 04:07:49 -0800
Date: Thu, 22 Dec 2011 04:07:45 -0800
From: Peter Deacon <peterd@iea-software.com>
To: Stefan Winter <stefan.winter@restena.lu>
In-Reply-To: <4EF2DE99.7050207@restena.lu>
Message-ID: <alpine.WNT.2.00.1112220026080.2472@SMURF>
References: <4EC1BD65.4040205@restena.lu> <4EEB1014.1030307@restena.lu> <5D36713D8A4E7348A7E10DF7437A4B9218583E44@SZXEML506-MBX.china.huawei.com> <4EF047A3.5090906@restena.lu> <4EF08F63.1010600@deployingradius.com> <alpine.WNT.2.00.1112200950300.2472@SMURF> <5D36713D8A4E7348A7E10DF7437A4B9218584374@SZXEML506-MBX.china.huawei.com> <alpine.WNT.2.00.1112201948210.2472@SMURF> <4EF1A65F.9080609@restena.lu> <alpine.WNT.2.00.1112210204010.2472@SMURF> <4EF1E94D.2080006@restena.lu> <alpine.WNT.2.00.1112210807180.2472@SMURF> <4EF2DE99.7050207@restena.lu>
User-Agent: Alpine 2.00 (WNT 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Mailman-Approved-At: Tue, 03 Jan 2012 08:09:36 -0800
Cc: softwires@ietf.org, Alan DeKok <aland@deployingradius.com>, GuoDayong <guodayong@huawei.com>
Subject: Re: [Softwires] 6rd RADIUS attribute - grouped attributes
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Dec 2011 12:07:51 -0000

On Thu, 22 Dec 2011, Stefan Winter wrote:

> Hi,
>>> Any particular reason why the 6rdPrefixLen and 6rdPrefix are glued into
>>> one blob in -04?

>> If you ignore the 6rd references it is describing prefix data type
>> defined a decade back in RFC3162 2.3 (Framed-IPv6-Prefix).  Logically it
>> counts as one field.

> Framed-IPv6-Prefix and your data type are different. Frames-IPv6-Prefix
> is of variable length, and requires to insert only those parts of the
> IPv6 address which are relevant for the prefix length. You can pad with
> more zeroes if you feel like it, but don't have to. (That in itself is a
> rather inconvenient construct, and I like yours more than that one
> actually.) Sure, if you opt to always pad with zeroes to the full 128
> bit, even if not necessary, you get the same fixed length as your
> datatype requires.

> Still, you have introduced a new data type
> "almost-but-not-quite-Framed-IPv6-Address".

There are a few areas implementors should take care to read the draft 
carefully.  I don't have a better idea.

> If you consider it a good idea, then fine - I'm sure you have much more
> experience in terms of actual implementations than I do. From a design
> point of view, I'd consider a pair of (int,IPv6-Address) cleaner than an
> implicit struct. The "belong together" can be expressed in the RFC as
> "both of the sub-TLVs have to appear exactly once".

A IPv6 prefix describes one thing not a collection of related things 
belonging together.  You can't pull apart a prefix into pieces that mean 
anything by themselves.

By convention a prefix is always expressed as a single field wherever it 
is entered or displayed (fe80::/16)

A prefix does not contain an IP Address.

TLVs have no global type space.  Elements of generally applicable 
composite types must be redefined separately within each instance they are 
used.

regards,
Peter