Re: [Idr] clarification required in draft-ietf-idr-flow-spec-v6

Ravi M R <mrravi@juniper.net> Mon, 29 December 2014 09:14 UTC

Return-Path: <mrravi@juniper.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C27F1A0046 for <idr@ietfa.amsl.com>; Mon, 29 Dec 2014 01:14:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.502
X-Spam-Level:
X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3RFa4bwUipI for <idr@ietfa.amsl.com>; Mon, 29 Dec 2014 01:14:07 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0145.outbound.protection.outlook.com [65.55.169.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D46021A0006 for <idr@ietf.org>; Mon, 29 Dec 2014 01:14:06 -0800 (PST)
Received: from DM2PR0501MB1019.namprd05.prod.outlook.com (25.160.25.11) by DM2PR0501MB1017.namprd05.prod.outlook.com (25.160.24.155) with Microsoft SMTP Server (TLS) id 15.1.49.12; Mon, 29 Dec 2014 09:14:04 +0000
Received: from DM2PR0501MB1019.namprd05.prod.outlook.com ([25.160.25.11]) by DM2PR0501MB1019.namprd05.prod.outlook.com ([25.160.25.11]) with mapi id 15.01.0049.002; Mon, 29 Dec 2014 09:14:04 +0000
From: Ravi M R <mrravi@juniper.net>
To: "Andy Karch (akarch)" <akarch@cisco.com>, "robert@raszuk.net" <robert@raszuk.net>, "Burjiz Pithawala (bpithaw)" <bpithaw@cisco.com>, "dmcpherson@verisign.com" <dmcpherson@verisign.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: clarification required in draft-ietf-idr-flow-spec-v6
Thread-Index: Ac+9NQcjdPPgj3zOQOaNzIZg1JQtRAAUhW/gANeHBcAYmH5moA==
Date: Mon, 29 Dec 2014 09:14:04 +0000
Message-ID: <DM2PR0501MB1019BF447071487A67F6EA01C7510@DM2PR0501MB1019.namprd05.prod.outlook.com>
References: <36efc752a51544c18f0e31ca5ee534ed@BLUPR05MB120.namprd05.prod.outlook.com> <F2F6B6945CBEC943AB2D5D32A2E4FB6C0EDB7D1D@xmb-aln-x04.cisco.com>
In-Reply-To: <F2F6B6945CBEC943AB2D5D32A2E4FB6C0EDB7D1D@xmb-aln-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [116.197.184.11]
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mrravi@juniper.net;
x-dmarcaction: None
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:DM2PR0501MB1017;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1017;
x-forefront-prvs: 0440AC9990
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(164054003)(479174004)(199003)(189002)(377454003)(92566001)(230783001)(107886001)(2950100001)(107046002)(2900100001)(87936001)(102836002)(86362001)(76576001)(19580395003)(106356001)(68736005)(99286002)(2201001)(54356999)(50986999)(76176999)(62966003)(31966008)(66066001)(54206007)(74316001)(77156002)(21056001)(64706001)(33656002)(2501002)(20776003)(120916001)(19580405001)(40100003)(2656002)(54606007)(4396001)(99396003)(97736003)(122556002)(101416001)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1017; H:DM2PR0501MB1019.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Dec 2014 09:14:04.4414 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1017
Archived-At: http://mailarchive.ietf.org/arch/msg/idr/DJ0jZjRNOEIzNuia0waSvqFSzOE
Subject: Re: [Idr] clarification required in draft-ietf-idr-flow-spec-v6
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Dec 2014 09:14:13 -0000

Hi Andy,

Following text is from new version of draft: draft-ietf-idr-flow-spec-v6-06

----snap----
   The following example demonstrates the new prefix encoding for: "all
   packets to ::1234:5678:9A00:0/64-104 from 192::/8 and port {range
   [137, 139] or 8080}".  In the destination prefix, "80-" represents
   the prefix offset of 80 bits.  In this exmaple, the 0 offset is
   omitted from the printed source prefix.

    +---------------------------+-------------+-------------------------+
    | destination               | source      | port                    |
    +---------------------------+-------------+-------------------------+
    | 0x01 68 50 12 34 56 78 9A | 02 00 08 c0 | 04 03 89 45 8b 91 1f 90 |==> offset is given as 50 but it should be 40.
    +---------------------------+-------------+-------------------------+
----snap----

In example prefix offset is not correct. Offset is given as 50 instead of 40. Please update it in next respin.

Thanks & Regards,
Ravi


-----Original Message-----
From: Andy Karch (akarch) [mailto:akarch@cisco.com] 
Sent: Tuesday, August 26, 2014 9:54 AM
To: Ravi M R; robert@raszuk.net; Burjiz Pithawala (bpithaw); dmcpherson@verisign.com; idr@ietf.org
Subject: RE: clarification required in draft-ietf-idr-flow-spec-v6

Hi Ravi,

My apologies on the previous reply...

The text should read "all packets to ::1234:5678:9A00:0/64-104".  The payload is 5 bytes (40 bits). 

The encoding below remains the same.

-Andy


-----Original Message-----
From: Andy Karch (akarch) 
Sent: Thursday, August 21, 2014 3:05 PM
To: 'Ravi M R'; robert@raszuk.net; Burjiz Pithawala (bpithaw); dmcpherson@verisign.com; idr@ietf.org
Subject: RE: clarification required in draft-ietf-idr-flow-spec-v6

Hi Ravi,

You're correct in pointing out the error. This was already found, but the update hasn't been posted yet.  The intention is to have 80-104 as there is 24 bits (6 bytes) of payload in the prefix, so the hex changes to 0x50 for the offset.

Please note the prefix offset and length have been swapped back to length before offset.  There is some history around this where a request was made to have offset before length (for readability and coding), before any known implantation existed.   Later an implementation was revealed to be shipping, so it was reverted.

In the example, the intention is to demonstrate that the offset "don't care" bits are not included in the prefix encoding.  They would just be 0's anyway.  This is consistent with unicast prefixes where only enough bytes for *length* bits are encoded and the trailing bits are irrelevant.  Similarly, we only need "length minus offset bits" (as worded in draft) to encode FlowSpec's prefix, with the added prefix offset dimension.  This does not require octet boundaries.  For example, the prefix with offset 5 and length 11 would require 6 bits (1 byte -- b 11111100), but if you enforced octet boundaries, it would require 2 bytes (b 00000111 11100000).

I'll include a more verbose example to demonstrate this point.

Thanks,
-Andy



   Type 2 - Source IPv6 Prefix

      Encoding: <type (1 octet), prefix offset (1 octet), prefix length
      (1 octet), prefix>

      Defines the source prefix to match.  Prefix offset has been
      defined to allow for flexible matching on part of the IPv6 address
      where we want to skip (don't care) of N first bits of the address.
      This can be especially useful where part of the IPv6 address
      consists of an embedded IPv4 address and matching needs to happen
      only on the embedded IPv4 address.  The encoded prefix contains
      enough octets for the bits used in matching (length minus offset
      bits).

-----Original Message-----
From: Ravi M R [mailto:mrravi@juniper.net] 
Sent: Thursday, August 21, 2014 4:43 AM
To: robert@raszuk.net; Burjiz Pithawala (bpithaw); dmcpherson@verisign.com; Andy Karch (akarch); idr@ietf.org
Subject: clarification required in draft-ietf-idr-flow-spec-v6

Hi Authors,

In the example given in section-3 of draft, "80-" represents  the prefix offset of 80 bits".
This seems to be wrong and should be 64 instead of 80.

--Extract from draft begin---
   The following example demonstrates the new prefix encoding for: "all
   packets to ::1234:5678:9A00:0/80-104 from 192::/8 and port {range
   [137, 139] or 8080}".  In the destination prefix, "80-" represents
   the prefix offset of 80 bits.  In this exmaple, the 0 offset is
   omitted from the printed source prefix.

    +---------------------------+-------------+-------------------------+
    | destination               | source      | port                    |
    +---------------------------+-------------+-------------------------+
    | 0x01 40 68 12 34 56 78 9A | 02 00 08 c0 | 04 03 89 45 8b 91 1f 90 |
    +---------------------------+-------------+-------------------------+
--Extract from draft end---


Also is it required that prefix-offset should be at byte boundry (i.e. multiples of 8)? 
If not, then providing an example in draft will be helpful as encoding/decoding can involve tedious bit level operations in such cases.
Ex: offset is 13 bits and prefix length is 110 bits for a IPv6 address. In this case, 97 bits from 13th to 110 bit should be encoded in NLRI.

Thanks & Regards,
Ravi