Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0083B129B91; Wed, 25 Jan 2017 12:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.541 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=calix.onmicrosoft.com 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 BCDm6_XqxWZT; Wed, 25 Jan 2017 12:15:52 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03lp0020.outbound.protection.outlook.com [216.32.181.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 487D8129B8C; Wed, 25 Jan 2017 12:15:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CALIX.onmicrosoft.com; s=selector1-calix-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qjccGiPR1xbz2KbCghINqN46iM7EDK2Ws22uK8VTsOc=; b=dwl4v3JY9vRT8De6GuPI1UUA1HBgrNSSzlTJv45qqa63ZyEX9lr4eWxKLt9nPb628wXweBTcg5zk9tC3xSKcReaC6STnFTSzxEOZLo8bwF/vPcOmUFcB0mJcxDyiD6YNaV0QYWg73qLpkyQYeY4nvcDhxtRW368PGJJK8y4klQ8= Received: from BY2PR0501MB1734.namprd05.prod.outlook.com (10.163.154.20) by BY2PR0501MB1733.namprd05.prod.outlook.com (10.163.154.19) 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 BY2PR0501MB1734.namprd05.prod.outlook.com ([10.163.154.20]) by BY2PR0501MB1734.namprd05.prod.outlook.com ([10.163.154.20]) 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 X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Marta.Seda@calix.com; x-originating-ip: [72.165.117.174] 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; H:BY2PR0501MB1734.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: calix.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR0501MB1734F8A6008509D2EE63D7D39C740BY2PR0501MB1734_" MIME-Version: 1.0 X-OriginatorOrg: calix.com 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: "ie-doctors@ietf.org" , "Khotimsky, Denis A \(denis.khotimsky@verizon.com\)" , "ipfix@ietf.org" , William Lupton Subject: Re: [IPFIX] BBF WT-352 X-BeenThere: ipfix@ietf.org 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 --_000_BY2PR0501MB1734F8A6008509D2EE63D7D39C740BY2PR0501MB1734_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you - P. I am including others at BBF in clarifications we need in W= T-352. I would like clarification on the following IANA Informational Elements: 1) minFlowStartSeconds: The earliest absolute timestamp of the first p= acket within any Flow within the scope containing this Information Element,= rounded down to the second if necessary. This Information Element SHOULD b= e 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-purp= osed 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 sem= antics 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 IAN= A IPFIX IE? 3) dot1qCustomerVlanId: The value represents the Customer VLAN identifi= er in the Customer field as described in IEEE802.1Q]. Q: This definitions seems to point to the C-tag. Is this the correct inte= rpretation of the IANA IPFIX IE? Appreciate your feedback. Regards, Marta From: PJ Aitken [mailto:pjaitken@brocade.com] Sent: Monday, January 16, 2017 1:39 PM To: Marta Seda Cc: ipfix@ietf.org; ie-doctors@ietf.org Subject: Re: [IPFIX] BBF WT-352 Marta, it's good to hear that you're thinking of using some IPFIX Informati= on Elements. The latest IPFIX elements are in IANA's registry. You can contact ie-doctors@ietf.org to discuss = and review new proposals. The formal request for new elements is usually ma= de either in an RFC or through a request to IANA. P. On 15/01/17 21:18, Marta Seda wrote: Hello, I am the editor of Broadband Forum WT-352 Inter-Channel Termination Protoco= l (ICTP) for NGPON2 (Next Generation Passive Optical Networks) protocol. W= e have been discussing in WT-352 the use of IPFIX as a unicast stream proto= col for transporting the following data elements across NGPON2 Channel Term= inations (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-inventi= ng new ones) and BBF introduce new TLVs not covered by IANA (e.g., NGPON2 s= pecific TLVs). WT-352 needs these TLVs to be defined for the purpose of in= teroperability 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 prov= ides guidance for those interested in expanding IANA registries. What I wo= uld like to understand is the following: A) Where can BBF pull the latest (or in progress) IPFIX IE? I have been= using: http://www.iana.org/assignments/ipfix/ipfix.xhtml (is this the most up to date reg= istry) 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 contac= t with respect to this? Regards, Marta Seda _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_ipfix&d=3DDwICAg&c=3DIL_XqQWOjubgfqINi2jTzg&r=3DXx9729xYDYoCgBDdc= p1FKt5PyYd1TCoXNKhyPY8CFp8&m=3DbDtxxCIPW_T3jeiYOQCvkKo800_8HuyXUPQHGVom_6E&= s=3Dvf4XRV9bB7AyXYDckfsLCtJ5IpdRwD9wtGKGbdqcWjk&e=3D --_000_BY2PR0501MB1734F8A6008509D2EE63D7D39C740BY2PR0501MB1734_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

I would like clarif= ication on the following IANA Informational Elements:

1)  &n= bsp;  minFlowStartSeconds:  The earliest absolute timestamp of the first packet within any Fl= ow within the scope containing this Information Element, rounded down to th= e second if necessary. This Information Element SHOULD be bound to its containing IPFIX Transport Session via an options r= ecord and the sessionScope Information Element.

 

Q:  Is this infor= mational element specific to netflow?  Could it be re-purposed for oth= er 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)   &nbs= p; dot1qVlanId:  The value of the 12-bit V= LAN 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.&n= bsp; In WT-352, we need to be able to identify the S-tag and C-tag.  T= his definitions seems to point to the S-tag.  Is this the correct interpretation of the IANA IPFIX IE?

3)   &nbs= p; dot1qCustomerVlanId: The value represents th= e Customer VLAN identifier in the Customer field as described

in IEEE802.1Q].=

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

 

Appreciate your fee= dback.  Regards,

 

Marta

From:= PJ Aitken [mailto:pjaitken@brocade.com]
Sent: Monday, January 16, 2017 1:39 PM
To: Marta Seda <Marta.Seda@calix.com>
Cc: ipfix@ietf.org; ie-doctors@ietf.org
Subject: Re: [IPFIX] BBF WT-352

 

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

The latest IPFIX elements are in IANA's registry.

You can contact ie-doctors@ietf.org<= /a> to discuss and review new proposals. The formal request for new element= s is usually made either in an RFC or through a request to IANA.

P.

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

Hello,

 

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

·       d= hcp leases

·       p= ppoe session information

·       I= gmp data (e.g., channel, uptime, etc)

·       A= RP data

·       O= MCI ME instance (optional)

 

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

 

We are proposing to reuse some IANA TLVs for WT-352 (ra= ther 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 N= GPON2 vendors.

 

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

A)    W= here can BBF pull the latest (or in progress) IPFIX IE?  I have been u= sing: http://www.iana.org/assignments/ipfix/ipfix.xhtml (is this the most up = to date registry)

B)     W= ould 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 w= ith respect to this?

 

Regards,

Marta Seda

 

 

 

 




_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__w=
ww.ietf.org_mailman_listinfo_ipfix&d=3DDwICAg&c=3DIL_XqQWOjubgfqINi=
2jTzg&r=3DXx9729xYDYoCgBDdcp1FKt5PyYd1TCoXNKhyPY8CFp8&m=3DbDtxxCIPW=
_T3jeiYOQCvkKo800_8HuyXUPQHGVom_6E&s=3Dvf4XRV9bB7AyXYDckfsLCtJ5IpdRwD9w=
tGKGbdqcWjk&e=3D

 

--_000_BY2PR0501MB1734F8A6008509D2EE63D7D39C740BY2PR0501MB1734_--