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

Sheng Jiang <jiangsheng@huawei.com> Wed, 21 December 2011 14:46 UTC

Return-Path: <jiangsheng@huawei.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 494B911E8080 for <softwires@ietfa.amsl.com>; Wed, 21 Dec 2011 06:46:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.174
X-Spam-Level:
X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, 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 Fg9YO0OROhoL for <softwires@ietfa.amsl.com>; Wed, 21 Dec 2011 06:46:22 -0800 (PST)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2FD11E8073 for <softwires@ietf.org>; Wed, 21 Dec 2011 06:46:22 -0800 (PST)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWK00LOO6CWX6@szxga04-in.huawei.com> for softwires@ietf.org; Wed, 21 Dec 2011 22:46:09 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWK00CLC6CTMY@szxga04-in.huawei.com> for softwires@ietf.org; Wed, 21 Dec 2011 22:46:08 +0800 (CST)
Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFV86536; Wed, 21 Dec 2011 22:46:07 +0800
Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 21 Dec 2011 22:46:02 +0800
Received: from SZXEML506-MBX.china.huawei.com ([169.254.4.239]) by szxeml405-hub.china.huawei.com ([10.82.67.60]) with mapi id 14.01.0323.003; Wed, 21 Dec 2011 22:46:00 +0800
Date: Wed, 21 Dec 2011 14:45:59 +0000
From: Sheng Jiang <jiangsheng@huawei.com>
In-reply-to: <4EF1E94D.2080006@restena.lu>
X-Originating-IP: [172.24.1.45]
To: Stefan Winter <stefan.winter@restena.lu>, Peter Deacon <peterd@iea-software.com>
Message-id: <5D36713D8A4E7348A7E10DF7437A4B92185856E5@SZXEML506-MBX.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Content-language: en-GB
Content-transfer-encoding: quoted-printable
Accept-Language: en-GB, zh-CN, en-US
Thread-topic: [Softwires] 6rd RADIUS attribute - grouped attributes
Thread-index: AQHMu9aQPTzd97i0lEik0CA/6hS55pXkZG3g//+BCYCAAFWJgIAAR0wAgAECspD//64HgIAAVI6AgAAXD4CAADi6gIAAj02H
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-CFilter-Loop: Reflected
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>
Cc: "softwires@ietf.org" <softwires@ietf.org>, GuoDayong <guodayong@huawei.com>, Alan DeKok <aland@deployingradius.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: Wed, 21 Dec 2011 14:46:23 -0000

No, we don't want to wait for extensions draft. 6rd technical is actually in a little bit emerge. We'd like to get this document published as soon as possible.

6rdPrefixLen and 6rdPrefix are bound together because the 6rdPrefixLen is explain hom many bits with in 6rdPrefix are real valid. They are actually on parameter.

So, looks for me, the format in 04 version is already the best choice.

Cheers,

Sheng
________________________________________
From: Stefan Winter [stefan.winter@restena.lu]
Sent: 21 December 2011 22:12
To: Peter Deacon
Cc: Sheng Jiang; Alan DeKok; GuoDayong; Maglione Roberta; softwires@ietf.org
Subject: Re: [Softwires] 6rd RADIUS attribute - grouped attributes

Hi,

> I don't think this is correct.  The extensions document describes a
> *data type* 'TLV'.  My suggestion simply leverages this type in the same
> way IPv4 Address and IPv6 prefix type from existing RFCs are already
> being leveraged.
>
> If you implement extensions RFC in the future your implementation
> supports the TLV data type giving you the ability to encode and decode
> this attribute with configuration dictionaries.  The wire format of
> IPv6-6rd-Configuration was intentionally made to be the same as a TLV.

Ah! I'm just looking at the -04 with this extra context. It's certainly
close. I think there's only one thing which is not inline: 6rdprefixLen
and 6rdPrefix immediately follow each other. In a version
compatible/analogous to the radius-extensions draft, the former would be
of type integer, the latter of type IPv6Address, and each would have its
own (Subtype,SubLen) tuple.

If that were to change, the two approaches are indeed very nicely
aligned. ASCII-art below:

  0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Length     |    SubType    |    SubLen     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv4MaskLen   |    SubType    |    SubLen     |  Reserved     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  6rdPrefixLen |    SubType    |    SubLen     |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
   |                                                               |
   +                                                               +
   |                     6rdPrefix                                 |
   +                                                               +
   |                                                               |
   +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |   SubType     |    SubLen     |   SubType     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    SubLen     | 6rdBRIPv4Address                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |
   +-+-+-+-+-+-+-+-+

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

> The compromise allowed someone to *choose* to implement the TLV type
> generically OR a much less flexible parser capable of handling just this
> attribute without having to also support extensions.
>
> Some vendors already support the TLV concept as it is necessary for
> wimax. It is possible to configure the -04 draft today with just
> configuration in some systems already supporting TLV.

That's quite good to hear. As said above, the only thing I'm wondering
is why there's a glued datatype for prefixlen+preifx in one go.

> My understanding they were not willing to wait for extensions to move
> ahead with the 6rd draft.  In that light my view was something that
> looked like a "TLV" was better than the alternative fixed format.
>
> If this constraint is invalid and they are willing to wait allowing 6rd
> draft to be dependent on extensions I agree it would certainly be the
> best approach for all concerned.

If you take the ASCII art above and add 16 bits of "reserved" after the
overall length, the rest of the attribute would even be bitwise aligned
with a later extended attribute (the space that an extended-attr would
fill with Extended-Type and Flags. Not sure if that's important or even
helpful for implementers though.

Greetings,

Stefan

--
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473