Re: [IPFIX] BBF WT-352

Marta Seda <> Wed, 25 January 2017 20:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0083B129B91; Wed, 25 Jan 2017 12:15:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.541
X-Spam-Status: No, score=-1.541 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BCDm6_XqxWZT; Wed, 25 Jan 2017 12:15:52 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 487D8129B8C; Wed, 25 Jan 2017 12:15:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-calix-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qjccGiPR1xbz2KbCghINqN46iM7EDK2Ws22uK8VTsOc=; b=dwl4v3JY9vRT8De6GuPI1UUA1HBgrNSSzlTJv45qqa63ZyEX9lr4eWxKLt9nPb628wXweBTcg5zk9tC3xSKcReaC6STnFTSzxEOZLo8bwF/vPcOmUFcB0mJcxDyiD6YNaV0QYWg73qLpkyQYeY4nvcDhxtRW368PGJJK8y4klQ8=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.6; Wed, 25 Jan 2017 20:15:50 +0000
Received: from ([]) by ([]) with mapi id 15.01.0874.012; Wed, 25 Jan 2017 20:15:50 +0000
From: Marta Seda <>
To: PJ Aitken <>
Thread-Topic: [IPFIX] BBF WT-352
Thread-Index: AdJvcbik1b38vcHbTAeHPqHB9kiyGgAzzVUAAcFRmjA=
Date: Wed, 25 Jan 2017 20:15:50 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-office365-filtering-correlation-id: 638bcc5a-5ddf-423c-edc1-08d4455ef505
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BY2PR0501MB1733;
x-microsoft-exchange-diagnostics: 1; BY2PR0501MB1733; 7:cT7a2W1WYSfWO48DFul8OGlKkKlSknfNsO4+t/JFBo3r/tlAn6lMaH6QkLuG2fCWJaqhY73J03Ahis4h+2MNNcUN/j6o3iYzBxbnspICAo/e2EE0c3Rikfnc0pCHkGdIZjJKnAKx0tuu+hgIKPkS5AYYI1X/fMXKf+ho9HS1hT3X86ax3T9a1pNI1pMKzsAX6P4guTGMghuZLYjS8nkZf+w/STEQkR/rEZpYW/GdZgOKA0rFApQks4Xhic50Hmbd4dsFB+QulKZqZ7n1Ozi/lZOYe0Ft+rBf1NTFBZmrE2P+CLBOH4FR5qD/dgdH+DWfkIK7+xPJJIuwKTK+U+ove5c3OsO/ijWK+nFEzn87eN22B4onJhDx1DrOd5Ew9ugnzN5O/oFDEQsxJhKxi5ND5NJHvH2cH/O33w5GKsIfN1eyn9F++H3SfGZdXUhKWTQtiXpocQX0pqad2BVb24VEhQ==
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(278428928389397)(131327999870524)(21748063052155)(162037286835866)(1591387915157)(10436049006162);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(6072148); SRVR:BY2PR0501MB1733; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0501MB1733;
x-forefront-prvs: 01986AE76B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(377454003)(189002)(24454002)(199003)(51884002)(236005)(97736004)(5660300001)(3280700002)(68736007)(2906002)(86362001)(53936002)(4326007)(122556002)(2900100001)(66066001)(33656002)(3660700001)(9686003)(6306002)(54896002)(54906002)(101416001)(38730400001)(229853002)(105586002)(106356001)(99286003)(8936002)(8676002)(54356999)(6506006)(25786008)(76176999)(77096006)(6916009)(7696004)(81156014)(50986999)(189998001)(7736002)(3846002)(6116002)(790700001)(92566002)(102836003)(6436002)(110136003)(7906003)(74316002)(81166006)(2950100002)(55016002)(19273905006)(606005)(563064011); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR0501MB1733;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR0501MB1734F8A6008509D2EE63D7D39C740BY2PR0501MB1734_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2017 20:15:50.3298 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ffae2e5-6ff0-4510-bbf3-ca842d7ca55e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0501MB1733
Archived-At: <>
Cc: "" <>, "Khotimsky, Denis A \(\)" <>, "" <>, William Lupton <>
Subject: Re: [IPFIX] BBF WT-352
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IPFIX WG discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Jan 2017 20:15:54 -0000

Thank you - P.  I am including others at BBF in clarifications we need in WT-352.

I would like clarification on the following IANA Informational Elements:

1)     minFlowStartSeconds:  The earliest absolute timestamp of the first packet within any Flow within the scope containing this Information Element, rounded down to the second if necessary. This Information Element SHOULD be bound to its containing IPFIX Transport Session via an options record and the sessionScope Information Element.

Q:  Is this informational element specific to netflow?  Could it be re-purposed for other purposes (e.g., the length of time a PPPoE session started)?  (if not supported in IANA,  BBF can create one for WT-352 purposes)

2)     dot1qVlanId:  The value of the 12-bit VLAN Identifier portion of the Tag Control Information field of an Ethernet frame.  The structure and semantics within the Tag Control Information field are defined in [IEEE802.1Q

Q:  I guess this question is more about confirming this definition.  In WT-352, we need to be able to identify the S-tag and C-tag.  This definitions seems to point to the S-tag.  Is this the correct interpretation of the IANA IPFIX IE?

3)     dot1qCustomerVlanId: The value represents the Customer VLAN identifier in the Customer field as described

in IEEE802.1Q].

Q:  This definitions seems to point to the C-tag.  Is this the correct interpretation of the IANA IPFIX IE?

Appreciate your feedback.  Regards,

From: PJ Aitken []
Sent: Monday, January 16, 2017 1:39 PM
To: Marta Seda <>
Subject: Re: [IPFIX] BBF WT-352

Marta, it's good to hear that you're thinking of using some IPFIX Information Elements.

The latest IPFIX elements are in IANA's registry.

You can contact<> to discuss and review new proposals. The formal request for new elements is usually made either in an RFC or through a request to IANA.


On 15/01/17 21:18, Marta Seda wrote:

I am the editor of Broadband Forum WT-352 Inter-Channel Termination Protocol (ICTP) for NGPON2 (Next Generation Passive Optical Networks) protocol.  We have been discussing in WT-352 the use of IPFIX as a unicast stream protocol for transporting the following data elements across NGPON2 Channel Terminations (CTs):

*       dhcp leases

*       pppoe session information

*       Igmp data (e.g., channel, uptime, etc)

*       ARP data

*       OMCI ME instance (optional)

Any bidirectional TLVs are transported using ICTP (not IPFIX).

We are proposing to reuse some IANA TLVs for WT-352 (rather than re-inventing new ones) and BBF introduce new TLVs not covered by IANA (e.g., NGPON2 specific TLVs).  WT-352 needs these TLVs to be defined for the purpose of interoperability among NGPON2 vendors.

RFC 7013 provides guidance to authors interested in expanding IANA registry (for Flow applications) and the existence of IPFIX doctors.  RFC 7013 provides guidance for those interested in expanding IANA registries.  What I would like to understand is the following:

A)    Where can BBF pull the latest (or in progress) IPFIX IE?  I have been using:<> (is this the most up to date registry)

B)     Would it be possible to have WT-352 proposed TLVs reviewed by IPFIX doctors (to verify there is no overlap in definitions).  Who could I contact with respect to this?

Marta Seda


IPFIX mailing list<>