From internet-drafts@ietf.org Tue Feb 5 21:18:24 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70DD421F8996; Tue, 5 Feb 2013 21:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezeelt8jVxOe; Tue, 5 Feb 2013 21:18:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26B721F89A4; Tue, 5 Feb 2013 21:18:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130206051823.21999.62120.idtracker@ietfa.amsl.com> Date: Tue, 05 Feb 2013 21:18:23 -0800 Cc: forces@ietf.org Subject: [forces] I-D Action: draft-ietf-forces-interop-06.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 05:18:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Forwarding and Control Element Separation= Working Group of the IETF. Title : Interoperability Report for Forwarding and Control Eleme= nt Separation (ForCES) Author(s) : Weiming Wang Kentaro Ogawa Evangelos Haleplidis Ming Gao Jamal Hadi Salim Filename : draft-ietf-forces-interop-06.txt Pages : 36 Date : 2013-02-05 Abstract: This document captures results of the second Forwarding and Control Element Separation (ForCES) interoperability test which took place on February 24-25, 2011 in the Internet Technology Lab (ITL) of Zhejiang Gongshang University, China. The document is an update to RFC 6053, which captured the results of the first ForCES interoperability test. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-forces-interop There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-forces-interop-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-forces-interop-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From adrian@olddog.co.uk Fri Feb 8 08:48:42 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A6D21F8B0A for ; Fri, 8 Feb 2013 08:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.055 X-Spam-Level: X-Spam-Status: No, score=-1.055 tagged_above=-999 required=5 tests=[AWL=-1.456, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_39=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JR1b8UeqMcxF for ; Fri, 8 Feb 2013 08:48:41 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id C615C21F8A7E for ; Fri, 8 Feb 2013 08:48:40 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r18GmdSN006823; Fri, 8 Feb 2013 16:48:39 GMT Received: from 950129200 (89-26-111-90.bruck.stat.salzburg-online.at [89.26.111.90]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r18Gmamw006782 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Feb 2013 16:48:37 GMT From: "Adrian Farrel" To: References: <20130128200315.11251.6339.idtracker@ietfa.amsl.com> In-Reply-To: Date: Fri, 8 Feb 2013 16:48:36 -0000 Message-ID: <00ed01ce061c$241e9cc0$6c5bd640$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKlW8aqsEkAq5dMuDFzx//ZQGfhYgF0i+CIAmgiEpeWopn7sA== Content-Language: en-gb Cc: forces@ietf.org Subject: [forces] FW: [IANA #654410] Last Call: (ForCES Logical Function Block (LFB) Library) to Proposed Standard X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 16:48:42 -0000 Authors, IANA need an answer from you. Let me know if your discussions result in the need to update the = document. Thanks, Adrian > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf = Of Pearl > Liang via RT > Sent: 08 February 2013 16:40 > Cc: draft-ietf-forces-lfb-lib@tools.ietf.org; = forces-chairs@tools.ietf.org; > iesg@ietf.org > Subject: [IANA #654410] Last Call: = (ForCES Logical > Function Block (LFB) Library) to Proposed Standard >=20 > (BEGIN IANA LAST CALL COMMENTS) >=20 > IESG: >=20 > IANA has reviewed draft-ietf-forces-lfb-lib-10 and has the following > comments: >=20 > We have questions about the IANA actions requested in this document. >=20 > We understand that, upon approval of this document, there are four > actions which we must complete. >=20 > First in the Logical Functional Block (LFB) Class Names and Class = Identifiers > subregistry of the Forwarding and Control Element Separation (ForCES) = registry > located at: >=20 > www.iana.org/assignments/forces/forces.xml >=20 > fifteen (15) new entries are to be added to the registry as follows: >=20 > +-----------+---------------+------------------------+--------------+ > | LFB Class | LFB Class Name| Description | Reference | > | Identifier| | | | > +-----------+---------------+------------------------+--------------+ > | 3 | EtherPHYCop | Define an Ethernet port|[ RFC-to-be ] | > | | | abstracted at physical | | > | | | layer. | Section 5.1.1| > | | | | | > | 4 | EtherMACIn | Define an Ethernet |[ RFC-to-be ] | > | | | input port at MAC data | Section 5.1.2| > | | | link layer. | | > | | | | | > | 5 |EtherClassifier| Define the process to |[ RFC-to-be ] | > | | | decapsulate Ethernet | Section 5.1.3| > | | | packets and classify | | > | | | the packets. | | > | | | | | > | 6 | EtherEncap | Define the process to |[ RFC-to-be ] | > | | | encapsulate IP packets | Section 5.1.4| > | | | to Ethernet packets. | | > | | | | | > | 7 | EtherMACOut | Define an Ethernet |[ RFC-to-be ] | > | | | output port at MAC | Section 5.1.5| > | | | data link layer. | | > | | | | | > | 8 | IPv4Validator | Perform IPv4 packets |[ RFC-to-be ] | > | | | validation. | Section 5.2.1| > | | | | | > | 9 | IPv6Validator | Perform IPv6 packets |[ RFC-to-be ] | > | | | validation. | Section 5.2.2| > | | | | | > | 10 | IPv4UcastLPM | Perform IPv4 Longest |[ RFC-to-be ] | > | | | Prefix Match Lookup. | Section 5.3.1| > | | | | | > | 11 | IPv6UcastLPM | Perform IPv6 Longest |[ RFC-to-be ] | > | | | Prefix Match Lookup. | Section 5.3.3| > | | | | | > | 12 | IPv4NextHop | Define the process of |[ RFC-to-be ] | > | | | selecting Ipv4 next hop| Section 5.3.2| > | | | action. | | > | | | | | > | 13 | IPv6NextHop | Define the process of |[ RFC-to-be ] | > | | | selecting Ipv6 next hop| Section 5.3.4| > | | | action. | | > | | | | | > | 14 | RedirectIn | Define the process for |[ RFC-to-be ] | > | | | CE to inject data | Section 5.4.1| > | | | packets into FE LFB | | > | | | topology. | | > | | | | | > | 15 | RedirectOut | Define the process for |[ RFC-to-be ] | > | | | LFBs in FE to deliver | Section 5.4.2| > | | | data packets to CE. | | > | | | | | > | 16 | BasicMetadata | Dispatch input packets |[ RFC-to-be ] | > | | Dispatch | to a group output | Section 5.5.1| > | | | according to a metadata| | > | | | | | > | 17 | Generic | Define a preliminary |[ RFC-to-be ] | > | | Scheduler | generic scheduling | Section 5.5.2| > | | | process. | | > +-----------+---------------+------------------------+--------------+ >=20 > Second, a new registry called the "Metadata ID Namespace" is to be = created in > the Forwarding and Control Element Separation (ForCES) registry = located at: >=20 > www.iana.org/assignments/forces/forces.xml >=20 > Metadata ID values are 32 bits long. >=20 > The rules for registration in this subregistry are: >=20 > For Metadata ID values 0x00000000-0x7FFFFFFF maintenance is done = through > Specification Required as defined by RFC 5226. >=20 > The authors request that for Metadata ID values 0x80000000-0xFFFFFFFF: > "Metadata IDs in this range are reserved for vendor private extensions = and are > the responsibility of individuals." >=20 > Question - Do the authors mean that this range is maintained via = Private Use as > defined in RFC 5226? >=20 > There are initial registrations in this subregistry as follows: >=20 > +--------------+-------------------------+--------------------------+ > | Value | Name | Reference | > +--------------+-------------------------+--------------------------+ > | 0x00000001 | PHYPortID | [ RFC-to-be ] | > | 0x00000002 | SrcMAC | [ RFC-to-be ] | > | 0x00000003 | DstMAC | [ RFC-to-be ] | > | 0x00000004 | LogicalPortID | [ RFC-to-be ] | > | 0x00000005 | EtherType | [ RFC-to-be ] | > | 0x00000006 | VlanID | [ RFC-to-be ] | > | 0x00000007 | VlanPriority | [ RFC-to-be ] | > | 0x00000008 | NextHopIPv4Addr | [ RFC-to-be ] | > | 0x00000009 | NextHopIPv6Addr | [ RFC-to-be ] | > | 0x0000000A | HopSelector | [ RFC-to-be ] | > | 0x0000000B | ExceptionID | [ RFC-to-be ] | > | 0x0000000C | ValidateErrorID | [ RFC-to-be ] | > | 0x0000000D | L3PortID | [ RFC-to-be ] | > | 0x0000000E | RedirectIndex | [ RFC-to-be ] | > | 0x0000000F | MediaEncapInfoIndex | [ RFC-to-be ] | > +--------------+-------------------------+--------------------------+ >=20 >=20 > Third, a new registry called the "Exception ID Namespace" is to be = created in the > Forwarding and Control Element Separation (ForCES) registry located = at: >=20 > www.iana.org/assignments/forces/forces.xml >=20 > Exception ID values are 32 bits long. >=20 > The rules for registration in this subregistry are: >=20 > For Exception ID values 0x00000000-0x7FFFFFFF maintenance is done = through > Specification Required as defined by RFC 5226. >=20 > The authors request that for Exception ID values = 0x80000000-0xFFFFFFFF: > "Exception IDs in this range are reserved for vendor private = extensions and are > the responsibility of individuals." >=20 > Question - Do the authors mean that this range is maintained via = Private Use as > defined in RFC 5226? >=20 > There are initial registrations in this subregistry as follows: >=20 > +--------------+---------------------------------+------------------+ > | Value | Name | Reference | > +--------------+---------------------------------+------------------+ > | 0x00000000 | AnyUnrecognizedExceptionCase | [ RFC-to-be ] | > | 0x00000001 | ClassifyNoMatching | [ RFC-to-be ] | > | 0x00000002 | MediaEncapInfoIndexInvalid | [ RFC-to-be ] | > | 0x00000003 | EncapTableLookupFailed | [ RFC-to-be ] | > | 0x00000004 | BadTTL | [ RFC-to-be ] | > | 0x00000005 | IPv4HeaderLengthMismatch | [ RFC-to-be ] | > | 0x00000006 | RouterAlertOptions | [ RFC-to-be ] | > | 0x00000007 | IPv6HopLimitZero | [ RFC-to-be ] | > | 0x00000008 | IPv6NextHeaderHBH | [ RFC-to-be ] | > | 0x00000009 | SrcAddressExecption | [ RFC-to-be ] | > | 0x0000000A | DstAddressExecption | [ RFC-to-be ] | > | 0x0000000B | LPMLookupFailed | [ RFC-to-be ] | > | 0x0000000C | HopSelectorInvalid | [ RFC-to-be ] | > | 0x0000000D | NextHopLookupFailed | [ RFC-to-be ] | > | 0x0000000E | FragRequired | [ RFC-to-be ] | > | 0x0000000F | MetadataNoMatching | [ RFC-to-be ] | > +--------------+---------------------------------+------------------+ >=20 > Fourth, a new registry called the "Validate Error ID Namespace" is to = be created in > the Forwarding and Control Element Separation (ForCES) registry = located at: >=20 > www.iana.org/assignments/forces/forces.xml >=20 > Validate Error ID values are 32 bits long. >=20 > The rules for registration in this subregistry are: >=20 > For Validate Error ID values 0x00000000-0x7FFFFFFF maintenance is done > through Specification Required as defined by RFC 5226. >=20 > The authors request that for Validate Error ID values = 0x80000000-0xFFFFFFFF: > "Validate Error IDs in this range are reserved for vendor private = extensions and > are the responsibility of individuals." >=20 > Question - Do the authors mean that this range is maintained via = Private Use as > defined in RFC 5226? >=20 > There are initial registrations in this subregistry as follows: >=20 > +--------------+---------------------------------+------------------+ > | Value | Name | Definition | > +--------------+---------------------------------+------------------+ > | 0x00000000 | AnyUnrecognizedValidateErrorCase| [ RFC-to-be ] | > | 0x00000001 | InvalidIPv4PacketSize | [ RFC-to-be ] | > | 0x00000002 | NotIPv4Packet | [ RFC-to-be ] | > | 0x00000003 | InvalidIPv4HeaderLengthSize | [ RFC-to-be ] | > | 0x00000004 | InvalidIPv4LengthFieldSize | [ RFC-to-be ] | > | 0x00000005 | InvalidIPv4Checksum | [ RFC-to-be ] | > | 0x00000006 | InvalidIPv4SrcAddr | [ RFC-to-be ] | > | 0x00000007 | InvalidIPv4DstAddr | [ RFC-to-be ] | > | 0x00000008 | InvalidIPv6PakcetSize | [ RFC-to-be ] | > | 0x00000009 | NotIPv6Packet | [ RFC-to-be ] | > | 0x0000000A | InvalidIPv6SrcAddr | [ RFC-to-be ] | > | 0x0000000B | InvalidIPv6DstAddr | [ RFC-to-be ] | > +--------------+---------------------------------+------------------+ >=20 > We understand that these four actions are the only ones required to be > completed upon approval of this document. >=20 > Note: The actions requested in this document will not be completed > until the document has been approved for publication as an RFC. > This message is only to confirm what actions will be performed. >=20 > Thanks, >=20 > Pearl Liang > ICANN/IANA >=20 > (END IANA LAST CALL COMMENTS) >=20 >=20 > On Mon Jan 28 12:03:42 2013, noreply@ietf.org wrote: > > > > The IESG has received a request from the Forwarding and Control = Element > > Separation WG (forces) to consider the following document: > > - 'ForCES Logical Function Block (LFB) Library' > > as Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and = solicits > > final comments on this action. Please send substantive comments to = the > > ietf@ietf.org mailing lists by 2013-02-11. Exceptionally, comments = may be > > sent to iesg@ietf.org instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > This document defines basic classes of Logical Function Blocks = (LFBs) > > used in the Forwarding and Control Element Separation (ForCES). = The > > basic LFB classes are defined according to ForCES FE model and = ForCES > > protocol specifications, and are scoped to meet requirements of > > typical router functions and considered as the basic LFB library = for > > ForCES. The library includes the descriptions of the LFBs and = the > > XML definitions. > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-forces-lfb-lib/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-forces-lfb-lib/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > From jmh@joelhalpern.com Fri Feb 8 08:54:31 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58C921F8A61 for ; Fri, 8 Feb 2013 08:54:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.261 X-Spam-Level: X-Spam-Status: No, score=-102.261 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUbMEdfp95vK for ; Fri, 8 Feb 2013 08:54:31 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id D737D21F854E for ; Fri, 8 Feb 2013 08:54:30 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 531E5A6992 for ; Fri, 8 Feb 2013 08:54:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 76C5E1CADF0 for ; Fri, 8 Feb 2013 08:54:29 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-134-125.clppva.east.verizon.net [70.106.134.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id CC2271CA7F8 for ; Fri, 8 Feb 2013 08:54:28 -0800 (PST) Message-ID: <51152DC1.5010200@joelhalpern.com> Date: Fri, 08 Feb 2013 11:54:25 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: forces Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [forces] lfb library reservations - Metadata ID X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 16:54:32 -0000 IANA has gone through our reservation requests. In doing so they asked a question which I at least am not sure about. In creating the registry for Metadata ID, we asking the lower half the 32 bit space to Specification Required (good. We assigned the upper half for private use, meaning that there is no registratio, and there is a risk of collision. Did we mean that, or did we want FCFS. Yours, Joel From wmwang2001@hotmail.com Fri Feb 8 18:50:52 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6147121F8814 for ; Fri, 8 Feb 2013 18:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.154 X-Spam-Level: ** X-Spam-Status: No, score=2.154 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_39=0.6, J_CHICKENPOX_66=0.6, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYRj66NSzsvS for ; Fri, 8 Feb 2013 18:50:51 -0800 (PST) Received: from blu0-omc4-s35.blu0.hotmail.com (blu0-omc4-s35.blu0.hotmail.com [65.55.111.174]) by ietfa.amsl.com (Postfix) with ESMTP id C9BFE21F87FA for ; Fri, 8 Feb 2013 18:50:48 -0800 (PST) Received: from BLU0-SMTP380 ([65.55.111.137]) by blu0-omc4-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Feb 2013 18:50:48 -0800 X-EIP: [j7yh4NtmqzrNCa/wV5ExVbVMEGZ+gl5X] X-Originating-Email: [wmwang2001@hotmail.com] Message-ID: Received: from WmwangHome ([125.120.88.88]) by BLU0-SMTP380.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Feb 2013 18:50:46 -0800 From: "Wang,Weiming" To: , References: <20130128200315.11251.6339.idtracker@ietfa.amsl.com> <00ed01ce061c$241e9cc0$6c5bd640$@olddog.co.uk> Date: Sat, 9 Feb 2013 10:50:49 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 09 Feb 2013 02:50:46.0686 (UTC) FILETIME=[42C873E0:01CE0670] Cc: forces@ietf.org Subject: Re: [forces] FW: [IANA #654410] Last Call: (ForCES Logical FunctionBlock (LFB) Library) to Proposed Standard X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2013 02:50:52 -0000 SSdtIHF1aXRlIHN1cmUgdGhhdCBhbGwgdGhlIHNwYWNlcyBtZW50aW9uZWQgYXMgJ3JhbmdlIHJl c2VydmVkIGZvciB2ZW5kb3IgcHJpdmF0ZSBleHRlbnNpb25zIGFuZCBhcmUgdGhlIHJlc3BvbnNp YmlsaXR5IG9mIGluZGl2aWR1YWxzJyBhcmUgaW50ZW5kZWQgZm9yIFByaXZhdGUgTG9jYWwgVXNl IG9ubHkgYW5kIHNob3VsZCBub3QgYXR0ZW1waW5nIEZDRlMuIA0KDQpJJ20gbm90IHN1cmUgaWYg dGhlICdTcGVjaWZpY2F0aW9uIFJlcXVpcmVkJyBpbmNsdWRlIGEgRkNGUyBzZXJ2aWNlPyBpZiBu b3QsIHdlIG1heSBvcGVuIGEgc3BhY2Ugc3BlY2lmaWNhbGx5IGZvciBGQ0ZTIHJlZ2lzdHJ5IHNl cnZpY2UuIA0KDQp0aGFua3MsDQpXZWltaW5nDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0t LS0gDQpGcm9tOiAiQWRyaWFuIEZhcnJlbCIgPGFkcmlhbkBvbGRkb2cuY28udWs+DQpUbzogPGRy YWZ0LWlldGYtZm9yY2VzLWxmYi1saWIuYWxsQHRvb2xzLmlldGYub3JnPg0KQ2M6IDxmb3JjZXNA aWV0Zi5vcmc+DQpTZW50OiBTYXR1cmRheSwgRmVicnVhcnkgMDksIDIwMTMgMTI6NDggQU0NClN1 YmplY3Q6IFtmb3JjZXNdIEZXOiBbSUFOQSAjNjU0NDEwXSBMYXN0IENhbGw6PGRyYWZ0LWlldGYt Zm9yY2VzLWxmYi1saWItMTAudHh0PiAoRm9yQ0VTIExvZ2ljYWwgRnVuY3Rpb25CbG9jayAoTEZC KSBMaWJyYXJ5KSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KDQoNCj4gQXV0aG9ycywNCj4gDQo+IElB TkEgbmVlZCBhbiBhbnN3ZXIgZnJvbSB5b3UuDQo+IExldCBtZSBrbm93IGlmIHlvdXIgZGlzY3Vz c2lvbnMgcmVzdWx0IGluIHRoZSBuZWVkIHRvIHVwZGF0ZSB0aGUgZG9jdW1lbnQuDQo+IA0KPiBU aGFua3MsDQo+IEFkcmlhbg0KPiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBG cm9tOiBpZXNnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppZXNnLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBQZWFybA0KPj4gTGlhbmcgdmlhIFJUDQo+PiBTZW50OiAwOCBGZWJydWFy eSAyMDEzIDE2OjQwDQo+PiBDYzogZHJhZnQtaWV0Zi1mb3JjZXMtbGZiLWxpYkB0b29scy5pZXRm Lm9yZzsgZm9yY2VzLWNoYWlyc0B0b29scy5pZXRmLm9yZzsNCj4+IGllc2dAaWV0Zi5vcmcNCj4+ IFN1YmplY3Q6IFtJQU5BICM2NTQ0MTBdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtZm9yY2VzLWxm Yi1saWItMTAudHh0PiAoRm9yQ0VTIExvZ2ljYWwNCj4+IEZ1bmN0aW9uIEJsb2NrIChMRkIpIExp YnJhcnkpIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+PiANCj4+IChCRUdJTiBJQU5BIExBU1QgQ0FM TCBDT01NRU5UUykNCj4+IA0KPj4gSUVTRzoNCj4+IA0KPj4gSUFOQSBoYXMgcmV2aWV3ZWQgZHJh ZnQtaWV0Zi1mb3JjZXMtbGZiLWxpYi0xMCBhbmQgaGFzIHRoZSBmb2xsb3dpbmcNCj4+IGNvbW1l bnRzOg0KPj4gDQo+PiBXZSBoYXZlIHF1ZXN0aW9ucyBhYm91dCB0aGUgSUFOQSBhY3Rpb25zIHJl cXVlc3RlZCBpbiB0aGlzIGRvY3VtZW50Lg0KPj4gDQo+PiBXZSB1bmRlcnN0YW5kIHRoYXQsIHVw b24gYXBwcm92YWwgb2YgdGhpcyBkb2N1bWVudCwgdGhlcmUgYXJlIGZvdXINCj4+IGFjdGlvbnMg d2hpY2ggd2UgbXVzdCBjb21wbGV0ZS4NCj4+IA0KPj4gRmlyc3QgaW4gdGhlIExvZ2ljYWwgRnVu Y3Rpb25hbCBCbG9jayAoTEZCKSBDbGFzcyBOYW1lcyBhbmQgQ2xhc3MgSWRlbnRpZmllcnMNCj4+ IHN1YnJlZ2lzdHJ5IG9mIHRoZSBGb3J3YXJkaW5nIGFuZCBDb250cm9sIEVsZW1lbnQgU2VwYXJh dGlvbiAoRm9yQ0VTKSByZWdpc3RyeQ0KPj4gbG9jYXRlZCBhdDoNCj4+IA0KPj4gd3d3LmlhbmEu b3JnL2Fzc2lnbm1lbnRzL2ZvcmNlcy9mb3JjZXMueG1sDQo+PiANCj4+IGZpZnRlZW4gKDE1KSBu ZXcgZW50cmllcyBhcmUgdG8gYmUgYWRkZWQgdG8gdGhlIHJlZ2lzdHJ5IGFzIGZvbGxvd3M6DQo+ PiANCj4+ICstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tKw0KPj4gfCBMRkIgQ2xhc3MgfCBMRkIgQ2xhc3MgTmFtZXwgICAg IERlc2NyaXB0aW9uICAgICAgICB8ICBSZWZlcmVuY2UgICB8DQo+PiB8IElkZW50aWZpZXJ8ICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwNCj4+ ICstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tKw0KPj4gfCAgICAgMyAgICAgfCAgRXRoZXJQSFlDb3AgIHwgRGVmaW5lIGFu IEV0aGVybmV0IHBvcnR8WyBSRkMtdG8tYmUgXSB8DQo+PiB8ICAgICAgICAgICB8ICAgICAgICAg ICAgICAgfCBhYnN0cmFjdGVkIGF0IHBoeXNpY2FsIHwgICAgICAgICAgICAgIHwNCj4+IHwgICAg ICAgICAgIHwgICAgICAgICAgICAgICB8IGxheWVyLiAgICAgICAgICAgICAgICAgfCBTZWN0aW9u IDUuMS4xfA0KPj4gfCAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICB8DQo+PiB8ICAgICA0ICAgICB8ICBFdGhlck1BQ0luICAg fCBEZWZpbmUgYW4gRXRoZXJuZXQgICAgIHxbIFJGQy10by1iZSBdIHwNCj4+IHwgICAgICAgICAg IHwgICAgICAgICAgICAgICB8IGlucHV0IHBvcnQgYXQgTUFDIGRhdGEgfCBTZWN0aW9uIDUuMS4y fA0KPj4gfCAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgbGluayBsYXllci4gICAgICAgICAg ICB8ICAgICAgICAgICAgICB8DQo+PiB8ICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwNCj4+IHwgICAgIDUgICAgIHxFdGhl ckNsYXNzaWZpZXJ8IERlZmluZSB0aGUgcHJvY2VzcyB0byAgfFsgUkZDLXRvLWJlIF0gfA0KPj4g fCAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgZGVjYXBzdWxhdGUgRXRoZXJuZXQgICB8IFNl Y3Rpb24gNS4xLjN8DQo+PiB8ICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCBwYWNrZXRzIGFu ZCBjbGFzc2lmeSAgIHwgICAgICAgICAgICAgIHwNCj4+IHwgICAgICAgICAgIHwgICAgICAgICAg ICAgICB8IHRoZSBwYWNrZXRzLiAgICAgICAgICAgfCAgICAgICAgICAgICAgfA0KPj4gfCAgICAg ICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICB8DQo+PiB8ICAgICA2ICAgICB8ICBFdGhlckVuY2FwICAgfCBEZWZpbmUgdGhlIHByb2Nl c3MgdG8gIHxbIFJGQy10by1iZSBdIHwNCj4+IHwgICAgICAgICAgIHwgICAgICAgICAgICAgICB8 IGVuY2Fwc3VsYXRlIElQIHBhY2tldHMgfCBTZWN0aW9uIDUuMS40fA0KPj4gfCAgICAgICAgICAg fCAgICAgICAgICAgICAgIHwgdG8gRXRoZXJuZXQgcGFja2V0cy4gICB8ICAgICAgICAgICAgICB8 DQo+PiB8ICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgIHwNCj4+IHwgICAgIDcgICAgIHwgIEV0aGVyTUFDT3V0ICB8IERlZmlu ZSBhbiBFdGhlcm5ldCAgICAgfFsgUkZDLXRvLWJlIF0gfA0KPj4gfCAgICAgICAgICAgfCAgICAg ICAgICAgICAgIHwgb3V0cHV0IHBvcnQgYXQgTUFDICAgICB8IFNlY3Rpb24gNS4xLjV8DQo+PiB8 ICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCBkYXRhIGxpbmsgbGF5ZXIuICAgICAgIHwgICAg ICAgICAgICAgIHwNCj4+IHwgICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgfA0KPj4gfCAgICAgOCAgICAgfCBJUHY0VmFsaWRh dG9yIHwgUGVyZm9ybSBJUHY0IHBhY2tldHMgICB8WyBSRkMtdG8tYmUgXSB8DQo+PiB8ICAgICAg ICAgICB8ICAgICAgICAgICAgICAgfCB2YWxpZGF0aW9uLiAgICAgICAgICAgIHwgU2VjdGlvbiA1 LjIuMXwNCj4+IHwgICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgfA0KPj4gfCAgICAgOSAgICAgfCBJUHY2VmFsaWRhdG9yIHwg UGVyZm9ybSBJUHY2IHBhY2tldHMgICB8WyBSRkMtdG8tYmUgXSB8DQo+PiB8ICAgICAgICAgICB8 ICAgICAgICAgICAgICAgfCB2YWxpZGF0aW9uLiAgICAgICAgICAgIHwgU2VjdGlvbiA1LjIuMnwN Cj4+IHwgICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgfA0KPj4gfCAgICAgMTAgICAgfCBJUHY0VWNhc3RMUE0gIHwgUGVyZm9y bSBJUHY0IExvbmdlc3QgICB8WyBSRkMtdG8tYmUgXSB8DQo+PiB8ICAgICAgICAgICB8ICAgICAg ICAgICAgICAgfCBQcmVmaXggTWF0Y2ggTG9va3VwLiAgIHwgU2VjdGlvbiA1LjMuMXwNCj4+IHwg ICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgfA0KPj4gfCAgICAgMTEgICAgfCBJUHY2VWNhc3RMUE0gIHwgUGVyZm9ybSBJUHY2 IExvbmdlc3QgICB8WyBSRkMtdG8tYmUgXSB8DQo+PiB8ICAgICAgICAgICB8ICAgICAgICAgICAg ICAgfCBQcmVmaXggTWF0Y2ggTG9va3VwLiAgIHwgU2VjdGlvbiA1LjMuM3wNCj4+IHwgICAgICAg ICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgfA0KPj4gfCAgICAgMTIgICAgfCAgSVB2NE5leHRIb3AgIHwgRGVmaW5lIHRoZSBwcm9jZXNz IG9mICB8WyBSRkMtdG8tYmUgXSB8DQo+PiB8ICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCBz ZWxlY3RpbmcgSXB2NCBuZXh0IGhvcHwgU2VjdGlvbiA1LjMuMnwNCj4+IHwgICAgICAgICAgIHwg ICAgICAgICAgICAgICB8IGFjdGlvbi4gICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfA0K Pj4gfCAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICB8DQo+PiB8ICAgICAxMyAgICB8ICBJUHY2TmV4dEhvcCAgfCBEZWZpbmUg dGhlIHByb2Nlc3Mgb2YgIHxbIFJGQy10by1iZSBdIHwNCj4+IHwgICAgICAgICAgIHwgICAgICAg ICAgICAgICB8IHNlbGVjdGluZyBJcHY2IG5leHQgaG9wfCBTZWN0aW9uIDUuMy40fA0KPj4gfCAg ICAgICAgICAgfCAgICAgICAgICAgICAgIHwgYWN0aW9uLiAgICAgICAgICAgICAgICB8ICAgICAg ICAgICAgICB8DQo+PiB8ICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgIHwNCj4+IHwgICAgIDE0ICAgIHwgIFJlZGlyZWN0SW4g ICB8IERlZmluZSB0aGUgcHJvY2VzcyBmb3IgfFsgUkZDLXRvLWJlIF0gfA0KPj4gfCAgICAgICAg ICAgfCAgICAgICAgICAgICAgIHwgQ0UgdG8gaW5qZWN0IGRhdGEgICAgICB8IFNlY3Rpb24gNS40 LjF8DQo+PiB8ICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCBwYWNrZXRzIGludG8gRkUgTEZC ICAgIHwgICAgICAgICAgICAgIHwNCj4+IHwgICAgICAgICAgIHwgICAgICAgICAgICAgICB8IHRv cG9sb2d5LiAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfA0KPj4gfCAgICAgICAgICAgfCAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8DQo+ PiB8ICAgICAxNSAgICB8ICBSZWRpcmVjdE91dCAgfCBEZWZpbmUgdGhlIHByb2Nlc3MgZm9yIHxb IFJGQy10by1iZSBdIHwNCj4+IHwgICAgICAgICAgIHwgICAgICAgICAgICAgICB8IExGQnMgaW4g RkUgdG8gZGVsaXZlciAgfCBTZWN0aW9uIDUuNC4yfA0KPj4gfCAgICAgICAgICAgfCAgICAgICAg ICAgICAgIHwgZGF0YSBwYWNrZXRzIHRvIENFLiAgICB8ICAgICAgICAgICAgICB8DQo+PiB8ICAg ICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgIHwNCj4+IHwgICAgIDE2ICAgIHwgQmFzaWNNZXRhZGF0YSB8IERpc3BhdGNoIGlucHV0 IHBhY2tldHMgfFsgUkZDLXRvLWJlIF0gfA0KPj4gfCAgICAgICAgICAgfCAgICBEaXNwYXRjaCAg IHwgdG8gYSBncm91cCBvdXRwdXQgICAgICB8IFNlY3Rpb24gNS41LjF8DQo+PiB8ICAgICAgICAg ICB8ICAgICAgICAgICAgICAgfCBhY2NvcmRpbmcgdG8gYSBtZXRhZGF0YXwgICAgICAgICAgICAg IHwNCj4+IHwgICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgfA0KPj4gfCAgICAgMTcgICAgfCAgICBHZW5lcmljICAgIHwgRGVm aW5lIGEgcHJlbGltaW5hcnkgICB8WyBSRkMtdG8tYmUgXSB8DQo+PiB8ICAgICAgICAgICB8ICAg U2NoZWR1bGVyICAgfCBnZW5lcmljIHNjaGVkdWxpbmcgICAgIHwgU2VjdGlvbiA1LjUuMnwNCj4+ IHwgICAgICAgICAgIHwgICAgICAgICAgICAgICB8IHByb2Nlc3MuICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgfA0KPj4gKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0rDQo+PiANCj4+IFNlY29uZCwgYSBuZXcgcmVn aXN0cnkgY2FsbGVkIHRoZSAiTWV0YWRhdGEgSUQgTmFtZXNwYWNlIiBpcyB0byBiZSBjcmVhdGVk IGluDQo+PiB0aGUgRm9yd2FyZGluZyBhbmQgQ29udHJvbCBFbGVtZW50IFNlcGFyYXRpb24gKEZv ckNFUykgcmVnaXN0cnkgbG9jYXRlZCBhdDoNCj4+IA0KPj4gd3d3LmlhbmEub3JnL2Fzc2lnbm1l bnRzL2ZvcmNlcy9mb3JjZXMueG1sDQo+PiANCj4+IE1ldGFkYXRhIElEIHZhbHVlcyBhcmUgMzIg Yml0cyBsb25nLg0KPj4gDQo+PiBUaGUgcnVsZXMgZm9yIHJlZ2lzdHJhdGlvbiBpbiB0aGlzIHN1 YnJlZ2lzdHJ5IGFyZToNCj4+IA0KPj4gRm9yIE1ldGFkYXRhIElEIHZhbHVlcyAweDAwMDAwMDAw LTB4N0ZGRkZGRkYgbWFpbnRlbmFuY2UgaXMgZG9uZSB0aHJvdWdoDQo+PiBTcGVjaWZpY2F0aW9u IFJlcXVpcmVkIGFzIGRlZmluZWQgYnkgUkZDIDUyMjYuDQo+PiANCj4+IFRoZSBhdXRob3JzIHJl cXVlc3QgdGhhdCBmb3IgTWV0YWRhdGEgSUQgdmFsdWVzIDB4ODAwMDAwMDAtMHhGRkZGRkZGRjoN Cj4+ICJNZXRhZGF0YSBJRHMgaW4gdGhpcyByYW5nZSBhcmUgcmVzZXJ2ZWQgZm9yIHZlbmRvciBw cml2YXRlIGV4dGVuc2lvbnMgYW5kIGFyZQ0KPj4gdGhlIHJlc3BvbnNpYmlsaXR5IG9mIGluZGl2 aWR1YWxzLiINCj4+IA0KPj4gUXVlc3Rpb24gLSBEbyB0aGUgYXV0aG9ycyBtZWFuIHRoYXQgdGhp cyByYW5nZSBpcyBtYWludGFpbmVkIHZpYSBQcml2YXRlIFVzZSBhcw0KPj4gZGVmaW5lZCBpbiBS RkMgNTIyNj8NCj4+IA0KPj4gVGhlcmUgYXJlIGluaXRpYWwgcmVnaXN0cmF0aW9ucyBpbiB0aGlz IHN1YnJlZ2lzdHJ5IGFzIGZvbGxvd3M6DQo+PiANCj4+ICstLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPj4gfCAgIFZh bHVlICAgICAgfCAgICAgICAgICAgTmFtZSAgICAgICAgICB8ICAgICAgICBSZWZlcmVuY2UgICAg ICAgICB8DQo+PiArLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+IHwgIDB4MDAwMDAwMDEgIHwgICAgICAgUEhZUG9y dElEICAgICAgICAgfCAgICAgIFsgUkZDLXRvLWJlIF0gICAgICAgfA0KPj4gfCAgMHgwMDAwMDAw MiAgfCAgICAgICAgIFNyY01BQyAgICAgICAgICB8ICAgICAgWyBSRkMtdG8tYmUgXSAgICAgICB8 DQo+PiB8ICAweDAwMDAwMDAzICB8ICAgICAgICAgRHN0TUFDICAgICAgICAgIHwgICAgICBbIFJG Qy10by1iZSBdICAgICAgIHwNCj4+IHwgIDB4MDAwMDAwMDQgIHwgICAgICAgTG9naWNhbFBvcnRJ RCAgICAgfCAgICAgIFsgUkZDLXRvLWJlIF0gICAgICAgfA0KPj4gfCAgMHgwMDAwMDAwNSAgfCAg ICAgICAgIEV0aGVyVHlwZSAgICAgICB8ICAgICAgWyBSRkMtdG8tYmUgXSAgICAgICB8DQo+PiB8 ICAweDAwMDAwMDA2ICB8ICAgICAgICAgIFZsYW5JRCAgICAgICAgIHwgICAgICBbIFJGQy10by1i ZSBdICAgICAgIHwNCj4+IHwgIDB4MDAwMDAwMDcgIHwgICAgICAgVmxhblByaW9yaXR5ICAgICAg fCAgICAgIFsgUkZDLXRvLWJlIF0gICAgICAgfA0KPj4gfCAgMHgwMDAwMDAwOCAgfCAgICAgICBO ZXh0SG9wSVB2NEFkZHIgICB8ICAgICAgWyBSRkMtdG8tYmUgXSAgICAgICB8DQo+PiB8ICAweDAw MDAwMDA5ICB8ICAgICAgIE5leHRIb3BJUHY2QWRkciAgIHwgICAgICBbIFJGQy10by1iZSBdICAg ICAgIHwNCj4+IHwgIDB4MDAwMDAwMEEgIHwgICAgICAgSG9wU2VsZWN0b3IgICAgICAgfCAgICAg IFsgUkZDLXRvLWJlIF0gICAgICAgfA0KPj4gfCAgMHgwMDAwMDAwQiAgfCAgICAgICBFeGNlcHRp b25JRCAgICAgICB8ICAgICAgWyBSRkMtdG8tYmUgXSAgICAgICB8DQo+PiB8ICAweDAwMDAwMDBD ICB8ICAgICAgVmFsaWRhdGVFcnJvcklEICAgIHwgICAgICBbIFJGQy10by1iZSBdICAgICAgIHwN Cj4+IHwgIDB4MDAwMDAwMEQgIHwgICAgICAgICBMM1BvcnRJRCAgICAgICAgfCAgICAgIFsgUkZD LXRvLWJlIF0gICAgICAgfA0KPj4gfCAgMHgwMDAwMDAwRSAgfCAgICAgICBSZWRpcmVjdEluZGV4 ICAgICB8ICAgICAgWyBSRkMtdG8tYmUgXSAgICAgICB8DQo+PiB8ICAweDAwMDAwMDBGICB8ICAg IE1lZGlhRW5jYXBJbmZvSW5kZXggIHwgICAgICBbIFJGQy10by1iZSBdICAgICAgIHwNCj4+ICst LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tKw0KPj4gDQo+PiANCj4+IFRoaXJkLCBhIG5ldyByZWdpc3RyeSBjYWxsZWQgdGhl ICJFeGNlcHRpb24gSUQgTmFtZXNwYWNlIiBpcyB0byBiZSBjcmVhdGVkIGluIHRoZQ0KPj4gRm9y d2FyZGluZyBhbmQgQ29udHJvbCBFbGVtZW50IFNlcGFyYXRpb24gKEZvckNFUykgcmVnaXN0cnkg bG9jYXRlZCBhdDoNCj4+IA0KPj4gd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2ZvcmNlcy9mb3Jj ZXMueG1sDQo+PiANCj4+IEV4Y2VwdGlvbiBJRCB2YWx1ZXMgYXJlIDMyIGJpdHMgbG9uZy4NCj4+ IA0KPj4gVGhlIHJ1bGVzIGZvciByZWdpc3RyYXRpb24gaW4gdGhpcyBzdWJyZWdpc3RyeSBhcmU6 DQo+PiANCj4+IEZvciBFeGNlcHRpb24gSUQgdmFsdWVzIDB4MDAwMDAwMDAtMHg3RkZGRkZGRiBt YWludGVuYW5jZSBpcyBkb25lIHRocm91Z2gNCj4+IFNwZWNpZmljYXRpb24gUmVxdWlyZWQgYXMg ZGVmaW5lZCBieSBSRkMgNTIyNi4NCj4+IA0KPj4gVGhlIGF1dGhvcnMgcmVxdWVzdCB0aGF0IGZv ciBFeGNlcHRpb24gSUQgdmFsdWVzIDB4ODAwMDAwMDAtMHhGRkZGRkZGRjoNCj4+ICJFeGNlcHRp b24gSURzIGluIHRoaXMgcmFuZ2UgYXJlIHJlc2VydmVkIGZvciB2ZW5kb3IgcHJpdmF0ZSBleHRl bnNpb25zIGFuZCBhcmUNCj4+IHRoZSByZXNwb25zaWJpbGl0eSBvZiBpbmRpdmlkdWFscy4iDQo+ PiANCj4+IFF1ZXN0aW9uIC0gRG8gdGhlIGF1dGhvcnMgbWVhbiB0aGF0IHRoaXMgcmFuZ2UgaXMg bWFpbnRhaW5lZCB2aWEgUHJpdmF0ZSBVc2UgYXMNCj4+IGRlZmluZWQgaW4gUkZDIDUyMjY/DQo+ PiANCj4+IFRoZXJlIGFyZSBpbml0aWFsIHJlZ2lzdHJhdGlvbnMgaW4gdGhpcyBzdWJyZWdpc3Ry eSBhcyBmb2xsb3dzOg0KPj4gDQo+PiArLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+IHwgICBWYWx1ZSAgICAgIHwg ICAgICAgICAgIE5hbWUgICAgICAgICAgICAgICAgICB8ICAgUmVmZXJlbmNlICAgICAgfA0KPj4g Ky0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0rDQo+PiB8ICAweDAwMDAwMDAwICB8ICBBbnlVbnJlY29nbml6ZWRFeGNlcHRp b25DYXNlICAgfCAgWyBSRkMtdG8tYmUgXSAgIHwNCj4+IHwgIDB4MDAwMDAwMDEgIHwgICAgICAg IENsYXNzaWZ5Tm9NYXRjaGluZyAgICAgICB8ICBbIFJGQy10by1iZSBdICAgfA0KPj4gfCAgMHgw MDAwMDAwMiAgfCAgIE1lZGlhRW5jYXBJbmZvSW5kZXhJbnZhbGlkICAgIHwgIFsgUkZDLXRvLWJl IF0gICB8DQo+PiB8ICAweDAwMDAwMDAzICB8ICAgICAgIEVuY2FwVGFibGVMb29rdXBGYWlsZWQg ICAgfCAgWyBSRkMtdG8tYmUgXSAgIHwNCj4+IHwgIDB4MDAwMDAwMDQgIHwgICAgICAgICAgICAg QmFkVFRMICAgICAgICAgICAgICB8ICBbIFJGQy10by1iZSBdICAgfA0KPj4gfCAgMHgwMDAwMDAw NSAgfCAgICAgSVB2NEhlYWRlckxlbmd0aE1pc21hdGNoICAgIHwgIFsgUkZDLXRvLWJlIF0gICB8 DQo+PiB8ICAweDAwMDAwMDA2ICB8ICAgICAgICBSb3V0ZXJBbGVydE9wdGlvbnMgICAgICAgfCAg WyBSRkMtdG8tYmUgXSAgIHwNCj4+IHwgIDB4MDAwMDAwMDcgIHwgICAgICAgICBJUHY2SG9wTGlt aXRaZXJvICAgICAgICB8ICBbIFJGQy10by1iZSBdICAgfA0KPj4gfCAgMHgwMDAwMDAwOCAgfCAg ICAgICBJUHY2TmV4dEhlYWRlckhCSCAgICAgICAgIHwgIFsgUkZDLXRvLWJlIF0gICB8DQo+PiB8 ICAweDAwMDAwMDA5ICB8ICAgICAgU3JjQWRkcmVzc0V4ZWNwdGlvbiAgICAgICAgfCAgWyBSRkMt dG8tYmUgXSAgIHwNCj4+IHwgIDB4MDAwMDAwMEEgIHwgICAgICBEc3RBZGRyZXNzRXhlY3B0aW9u ICAgICAgICB8ICBbIFJGQy10by1iZSBdICAgfA0KPj4gfCAgMHgwMDAwMDAwQiAgfCAgICAgICAg TFBNTG9va3VwRmFpbGVkICAgICAgICAgIHwgIFsgUkZDLXRvLWJlIF0gICB8DQo+PiB8ICAweDAw MDAwMDBDICB8ICAgICAgIEhvcFNlbGVjdG9ySW52YWxpZCAgICAgICAgfCAgWyBSRkMtdG8tYmUg XSAgIHwNCj4+IHwgIDB4MDAwMDAwMEQgIHwgICAgICBOZXh0SG9wTG9va3VwRmFpbGVkICAgICAg ICB8ICBbIFJGQy10by1iZSBdICAgfA0KPj4gfCAgMHgwMDAwMDAwRSAgfCAgICAgICAgICBGcmFn UmVxdWlyZWQgICAgICAgICAgIHwgIFsgUkZDLXRvLWJlIF0gICB8DQo+PiB8ICAweDAwMDAwMDBG ICB8ICAgICAgIE1ldGFkYXRhTm9NYXRjaGluZyAgICAgICAgfCAgWyBSRkMtdG8tYmUgXSAgIHwN Cj4+ICstLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tLS0tKw0KPj4gDQo+PiBGb3VydGgsIGEgbmV3IHJlZ2lzdHJ5IGNhbGxlZCB0 aGUgIlZhbGlkYXRlIEVycm9yIElEIE5hbWVzcGFjZSIgaXMgdG8gYmUgY3JlYXRlZCBpbg0KPj4g dGhlIEZvcndhcmRpbmcgYW5kIENvbnRyb2wgRWxlbWVudCBTZXBhcmF0aW9uIChGb3JDRVMpIHJl Z2lzdHJ5IGxvY2F0ZWQgYXQ6DQo+PiANCj4+IHd3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9mb3Jj ZXMvZm9yY2VzLnhtbA0KPj4gDQo+PiBWYWxpZGF0ZSBFcnJvciBJRCB2YWx1ZXMgYXJlIDMyIGJp dHMgbG9uZy4NCj4+IA0KPj4gVGhlIHJ1bGVzIGZvciByZWdpc3RyYXRpb24gaW4gdGhpcyBzdWJy ZWdpc3RyeSBhcmU6DQo+PiANCj4+IEZvciBWYWxpZGF0ZSBFcnJvciBJRCB2YWx1ZXMgMHgwMDAw MDAwMC0weDdGRkZGRkZGIG1haW50ZW5hbmNlIGlzIGRvbmUNCj4+IHRocm91Z2ggU3BlY2lmaWNh dGlvbiBSZXF1aXJlZCBhcyBkZWZpbmVkIGJ5IFJGQyA1MjI2Lg0KPj4gDQo+PiBUaGUgYXV0aG9y cyByZXF1ZXN0IHRoYXQgZm9yIFZhbGlkYXRlIEVycm9yIElEIHZhbHVlcyAweDgwMDAwMDAwLTB4 RkZGRkZGRkY6DQo+PiAiVmFsaWRhdGUgRXJyb3IgSURzIGluIHRoaXMgcmFuZ2UgYXJlIHJlc2Vy dmVkIGZvciB2ZW5kb3IgcHJpdmF0ZSBleHRlbnNpb25zIGFuZA0KPj4gYXJlIHRoZSByZXNwb25z aWJpbGl0eSBvZiBpbmRpdmlkdWFscy4iDQo+PiANCj4+IFF1ZXN0aW9uIC0gRG8gdGhlIGF1dGhv cnMgbWVhbiB0aGF0IHRoaXMgcmFuZ2UgaXMgbWFpbnRhaW5lZCB2aWEgUHJpdmF0ZSBVc2UgYXMN Cj4+IGRlZmluZWQgaW4gUkZDIDUyMjY/DQo+PiANCj4+IFRoZXJlIGFyZSBpbml0aWFsIHJlZ2lz dHJhdGlvbnMgaW4gdGhpcyBzdWJyZWdpc3RyeSBhcyBmb2xsb3dzOg0KPj4gDQo+PiArLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tLSsNCj4+IHwgICBWYWx1ZSAgICAgIHwgICAgICAgICAgIE5hbWUgICAgICAgICAgICAgICAg ICB8ICAgRGVmaW5pdGlvbiAgICAgfA0KPj4gKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0rDQo+PiB8ICAweDAwMDAwMDAw ICB8IEFueVVucmVjb2duaXplZFZhbGlkYXRlRXJyb3JDYXNlfCBbIFJGQy10by1iZSBdICAgIHwN Cj4+IHwgIDB4MDAwMDAwMDEgIHwgICAgICAgIEludmFsaWRJUHY0UGFja2V0U2l6ZSAgICB8IFsg UkZDLXRvLWJlIF0gICAgfA0KPj4gfCAgMHgwMDAwMDAwMiAgfCAgICAgICAgICAgTm90SVB2NFBh Y2tldCAgICAgICAgIHwgWyBSRkMtdG8tYmUgXSAgICB8DQo+PiB8ICAweDAwMDAwMDAzICB8ICAg IEludmFsaWRJUHY0SGVhZGVyTGVuZ3RoU2l6ZSAgfCBbIFJGQy10by1iZSBdICAgIHwNCj4+IHwg IDB4MDAwMDAwMDQgIHwgICAgSW52YWxpZElQdjRMZW5ndGhGaWVsZFNpemUgICB8IFsgUkZDLXRv LWJlIF0gICAgfA0KPj4gfCAgMHgwMDAwMDAwNSAgfCAgICAgICAgIEludmFsaWRJUHY0Q2hlY2tz dW0gICAgIHwgWyBSRkMtdG8tYmUgXSAgICB8DQo+PiB8ICAweDAwMDAwMDA2ICB8ICAgICAgSW52 YWxpZElQdjRTcmNBZGRyICAgICAgICAgfCBbIFJGQy10by1iZSBdICAgIHwNCj4+IHwgIDB4MDAw MDAwMDcgIHwgICAgICBJbnZhbGlkSVB2NERzdEFkZHIgICAgICAgICB8IFsgUkZDLXRvLWJlIF0g ICAgfA0KPj4gfCAgMHgwMDAwMDAwOCAgfCAgICAgIEludmFsaWRJUHY2UGFrY2V0U2l6ZSAgICAg IHwgWyBSRkMtdG8tYmUgXSAgICB8DQo+PiB8ICAweDAwMDAwMDA5ICB8ICAgICAgICAgIE5vdElQ djZQYWNrZXQgICAgICAgICAgfCBbIFJGQy10by1iZSBdICAgIHwNCj4+IHwgIDB4MDAwMDAwMEEg IHwgICAgICBJbnZhbGlkSVB2NlNyY0FkZHIgICAgICAgICB8IFsgUkZDLXRvLWJlIF0gICAgfA0K Pj4gfCAgMHgwMDAwMDAwQiAgfCAgICAgIEludmFsaWRJUHY2RHN0QWRkciAgICAgICAgIHwgWyBS RkMtdG8tYmUgXSAgICB8DQo+PiArLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+IA0KPj4gV2UgdW5kZXJzdGFuZCB0 aGF0IHRoZXNlIGZvdXIgYWN0aW9ucyBhcmUgdGhlIG9ubHkgb25lcyByZXF1aXJlZCB0byBiZQ0K Pj4gY29tcGxldGVkIHVwb24gYXBwcm92YWwgb2YgdGhpcyBkb2N1bWVudC4NCj4+IA0KPj4gTm90 ZTogIFRoZSBhY3Rpb25zIHJlcXVlc3RlZCBpbiB0aGlzIGRvY3VtZW50IHdpbGwgbm90IGJlIGNv bXBsZXRlZA0KPj4gdW50aWwgdGhlIGRvY3VtZW50IGhhcyBiZWVuIGFwcHJvdmVkIGZvciBwdWJs aWNhdGlvbiBhcyBhbiBSRkMuDQo+PiBUaGlzIG1lc3NhZ2UgaXMgb25seSB0byBjb25maXJtIHdo YXQgYWN0aW9ucyB3aWxsIGJlIHBlcmZvcm1lZC4NCj4+IA0KPj4gVGhhbmtzLA0KPj4gDQo+PiBQ ZWFybCBMaWFuZw0KPj4gSUNBTk4vSUFOQQ0KPj4gDQo+PiAoRU5EIElBTkEgTEFTVCBDQUxMIENP TU1FTlRTKQ0KPj4gDQo+PiANCj4+IE9uIE1vbiBKYW4gMjggMTI6MDM6NDIgMjAxMywgbm9yZXBs eUBpZXRmLm9yZyB3cm90ZToNCj4+ID4NCj4+ID4gVGhlIElFU0cgaGFzIHJlY2VpdmVkIGEgcmVx dWVzdCBmcm9tIHRoZSBGb3J3YXJkaW5nIGFuZCBDb250cm9sIEVsZW1lbnQNCj4+ID4gU2VwYXJh dGlvbiBXRyAoZm9yY2VzKSB0byBjb25zaWRlciB0aGUgZm9sbG93aW5nIGRvY3VtZW50Og0KPj4g PiAtICdGb3JDRVMgTG9naWNhbCBGdW5jdGlvbiBCbG9jayAoTEZCKSBMaWJyYXJ5Jw0KPj4gPiAg IDxkcmFmdC1pZXRmLWZvcmNlcy1sZmItbGliLTEwLnR4dD4gYXMgUHJvcG9zZWQgU3RhbmRhcmQN Cj4+ID4NCj4+ID4gVGhlIElFU0cgcGxhbnMgdG8gbWFrZSBhIGRlY2lzaW9uIGluIHRoZSBuZXh0 IGZldyB3ZWVrcywgYW5kIHNvbGljaXRzDQo+PiA+IGZpbmFsIGNvbW1lbnRzIG9uIHRoaXMgYWN0 aW9uLiBQbGVhc2Ugc2VuZCBzdWJzdGFudGl2ZSBjb21tZW50cyB0byB0aGUNCj4+ID4gaWV0ZkBp ZXRmLm9yZyBtYWlsaW5nIGxpc3RzIGJ5IDIwMTMtMDItMTEuIEV4Y2VwdGlvbmFsbHksIGNvbW1l bnRzIG1heSBiZQ0KPj4gPiBzZW50IHRvIGllc2dAaWV0Zi5vcmcgaW5zdGVhZC4gSW4gZWl0aGVy IGNhc2UsIHBsZWFzZSByZXRhaW4gdGhlDQo+PiA+IGJlZ2lubmluZyBvZiB0aGUgU3ViamVjdCBs aW5lIHRvIGFsbG93IGF1dG9tYXRlZCBzb3J0aW5nLg0KPj4gPg0KPj4gPiBBYnN0cmFjdA0KPj4g Pg0KPj4gPiAgICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYmFzaWMgY2xhc3NlcyBvZiBMb2dpY2Fs IEZ1bmN0aW9uIEJsb2NrcyAoTEZCcykNCj4+ID4gICAgdXNlZCBpbiB0aGUgRm9yd2FyZGluZyBh bmQgQ29udHJvbCBFbGVtZW50IFNlcGFyYXRpb24gKEZvckNFUykuICBUaGUNCj4+ID4gICAgYmFz aWMgTEZCIGNsYXNzZXMgYXJlIGRlZmluZWQgYWNjb3JkaW5nIHRvIEZvckNFUyBGRSBtb2RlbCBh bmQgRm9yQ0VTDQo+PiA+ICAgIHByb3RvY29sIHNwZWNpZmljYXRpb25zLCBhbmQgYXJlIHNjb3Bl ZCB0byBtZWV0IHJlcXVpcmVtZW50cyBvZg0KPj4gPiAgICB0eXBpY2FsIHJvdXRlciBmdW5jdGlv bnMgYW5kIGNvbnNpZGVyZWQgYXMgdGhlIGJhc2ljIExGQiBsaWJyYXJ5IGZvcg0KPj4gPiAgICBG b3JDRVMuICBUaGUgbGlicmFyeSBpbmNsdWRlcyB0aGUgZGVzY3JpcHRpb25zIG9mIHRoZSBMRkJz IGFuZCB0aGUNCj4+ID4gICAgWE1MIGRlZmluaXRpb25zLg0KPj4gPg0KPj4gPg0KPj4gPiBUaGUg ZmlsZSBjYW4gYmUgb2J0YWluZWQgdmlhDQo+PiA+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1mb3JjZXMtbGZiLWxpYi8NCj4+ID4NCj4+ID4gSUVTRyBkaXNjdXNz aW9uIGNhbiBiZSB0cmFja2VkIHZpYQ0KPj4gPiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtZm9yY2VzLWxmYi1saWIvYmFsbG90Lw0KPj4gPg0KPj4gPg0KPj4gPiBO byBJUFIgZGVjbGFyYXRpb25zIGhhdmUgYmVlbiBzdWJtaXR0ZWQgZGlyZWN0bHkgb24gdGhpcyBJ LUQuDQo+PiA+DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBmb3JjZXMgbWFpbGluZyBsaXN0DQo+IGZvcmNlc0BpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZvcmNlcw== From joel@stevecrocker.com Fri Feb 8 19:20:57 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4E421F8B14 for ; Fri, 8 Feb 2013 19:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.131 X-Spam-Level: ** X-Spam-Status: No, score=2.131 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DSL=1.129, J_CHICKENPOX_16=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_39=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_66=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBaqMBnYhriK for ; Fri, 8 Feb 2013 19:20:56 -0800 (PST) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 7552C21F8B13 for ; Fri, 8 Feb 2013 19:20:53 -0800 (PST) Received: from dummy.name; Sat, 09 Feb 2013 03:20:59 +0000 Message-ID: <5115C08F.60605@stevecrocker.com> Date: Fri, 08 Feb 2013 22:20:47 -0500 From: Joel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Wang,Weiming" References: <20130128200315.11251.6339.idtracker@ietfa.amsl.com> <00ed01ce061c$241e9cc0$6c5bd640$@olddog.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces@ietf.org, draft-ietf-forces-lfb-lib.all@tools.ietf.org Subject: Re: [forces] FW: [IANA #654410] Last Call: (ForCES Logical FunctionBlock (LFB) Library) to Proposed Standard X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2013 03:20:57 -0000 Specification Required means that you have to provide a spec, but if you do it is FCFS. Pure FCFS means that you simply request a number and you get one. It is quite reasonable to take the view that anything registered should have a spec. I just wanted to makesure that was really the WG agreemet. Yours, Joel On 2/8/2013 9:50 PM, Wang,Weiming wrote: > I'm quite sure that all the spaces mentioned as 'range reserved for vendor private extensions and are the responsibility of individuals' are intended for Private Local Use only and should not attemping FCFS. > > I'm not sure if the 'Specification Required' include a FCFS service? if not, we may open a space specifically for FCFS registry service. > > thanks, > Weiming > > ----- Original Message ----- > From: "Adrian Farrel" > To: > Cc: > Sent: Saturday, February 09, 2013 12:48 AM > Subject: [forces] FW: [IANA #654410] Last Call: (ForCES Logical FunctionBlock (LFB) Library) to Proposed Standard > > >> Authors, >> >> IANA need an answer from you. >> Let me know if your discussions result in the need to update the document. >> >> Thanks, >> Adrian >> >>> -----Original Message----- >>> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Pearl >>> Liang via RT >>> Sent: 08 February 2013 16:40 >>> Cc: draft-ietf-forces-lfb-lib@tools.ietf.org; forces-chairs@tools.ietf.org; >>> iesg@ietf.org >>> Subject: [IANA #654410] Last Call: (ForCES Logical >>> Function Block (LFB) Library) to Proposed Standard >>> >>> (BEGIN IANA LAST CALL COMMENTS) >>> >>> IESG: >>> >>> IANA has reviewed draft-ietf-forces-lfb-lib-10 and has the following >>> comments: >>> >>> We have questions about the IANA actions requested in this document. >>> >>> We understand that, upon approval of this document, there are four >>> actions which we must complete. >>> >>> First in the Logical Functional Block (LFB) Class Names and Class Identifiers >>> subregistry of the Forwarding and Control Element Separation (ForCES) registry >>> located at: >>> >>> www.iana.org/assignments/forces/forces.xml >>> >>> fifteen (15) new entries are to be added to the registry as follows: >>> >>> +-----------+---------------+------------------------+--------------+ >>> | LFB Class | LFB Class Name| Description | Reference | >>> | Identifier| | | | >>> +-----------+---------------+------------------------+--------------+ >>> | 3 | EtherPHYCop | Define an Ethernet port|[ RFC-to-be ] | >>> | | | abstracted at physical | | >>> | | | layer. | Section 5.1.1| >>> | | | | | >>> | 4 | EtherMACIn | Define an Ethernet |[ RFC-to-be ] | >>> | | | input port at MAC data | Section 5.1.2| >>> | | | link layer. | | >>> | | | | | >>> | 5 |EtherClassifier| Define the process to |[ RFC-to-be ] | >>> | | | decapsulate Ethernet | Section 5.1.3| >>> | | | packets and classify | | >>> | | | the packets. | | >>> | | | | | >>> | 6 | EtherEncap | Define the process to |[ RFC-to-be ] | >>> | | | encapsulate IP packets | Section 5.1.4| >>> | | | to Ethernet packets. | | >>> | | | | | >>> | 7 | EtherMACOut | Define an Ethernet |[ RFC-to-be ] | >>> | | | output port at MAC | Section 5.1.5| >>> | | | data link layer. | | >>> | | | | | >>> | 8 | IPv4Validator | Perform IPv4 packets |[ RFC-to-be ] | >>> | | | validation. | Section 5.2.1| >>> | | | | | >>> | 9 | IPv6Validator | Perform IPv6 packets |[ RFC-to-be ] | >>> | | | validation. | Section 5.2.2| >>> | | | | | >>> | 10 | IPv4UcastLPM | Perform IPv4 Longest |[ RFC-to-be ] | >>> | | | Prefix Match Lookup. | Section 5.3.1| >>> | | | | | >>> | 11 | IPv6UcastLPM | Perform IPv6 Longest |[ RFC-to-be ] | >>> | | | Prefix Match Lookup. | Section 5.3.3| >>> | | | | | >>> | 12 | IPv4NextHop | Define the process of |[ RFC-to-be ] | >>> | | | selecting Ipv4 next hop| Section 5.3.2| >>> | | | action. | | >>> | | | | | >>> | 13 | IPv6NextHop | Define the process of |[ RFC-to-be ] | >>> | | | selecting Ipv6 next hop| Section 5.3.4| >>> | | | action. | | >>> | | | | | >>> | 14 | RedirectIn | Define the process for |[ RFC-to-be ] | >>> | | | CE to inject data | Section 5.4.1| >>> | | | packets into FE LFB | | >>> | | | topology. | | >>> | | | | | >>> | 15 | RedirectOut | Define the process for |[ RFC-to-be ] | >>> | | | LFBs in FE to deliver | Section 5.4.2| >>> | | | data packets to CE. | | >>> | | | | | >>> | 16 | BasicMetadata | Dispatch input packets |[ RFC-to-be ] | >>> | | Dispatch | to a group output | Section 5.5.1| >>> | | | according to a metadata| | >>> | | | | | >>> | 17 | Generic | Define a preliminary |[ RFC-to-be ] | >>> | | Scheduler | generic scheduling | Section 5.5.2| >>> | | | process. | | >>> +-----------+---------------+------------------------+--------------+ >>> >>> Second, a new registry called the "Metadata ID Namespace" is to be created in >>> the Forwarding and Control Element Separation (ForCES) registry located at: >>> >>> www.iana.org/assignments/forces/forces.xml >>> >>> Metadata ID values are 32 bits long. >>> >>> The rules for registration in this subregistry are: >>> >>> For Metadata ID values 0x00000000-0x7FFFFFFF maintenance is done through >>> Specification Required as defined by RFC 5226. >>> >>> The authors request that for Metadata ID values 0x80000000-0xFFFFFFFF: >>> "Metadata IDs in this range are reserved for vendor private extensions and are >>> the responsibility of individuals." >>> >>> Question - Do the authors mean that this range is maintained via Private Use as >>> defined in RFC 5226? >>> >>> There are initial registrations in this subregistry as follows: >>> >>> +--------------+-------------------------+--------------------------+ >>> | Value | Name | Reference | >>> +--------------+-------------------------+--------------------------+ >>> | 0x00000001 | PHYPortID | [ RFC-to-be ] | >>> | 0x00000002 | SrcMAC | [ RFC-to-be ] | >>> | 0x00000003 | DstMAC | [ RFC-to-be ] | >>> | 0x00000004 | LogicalPortID | [ RFC-to-be ] | >>> | 0x00000005 | EtherType | [ RFC-to-be ] | >>> | 0x00000006 | VlanID | [ RFC-to-be ] | >>> | 0x00000007 | VlanPriority | [ RFC-to-be ] | >>> | 0x00000008 | NextHopIPv4Addr | [ RFC-to-be ] | >>> | 0x00000009 | NextHopIPv6Addr | [ RFC-to-be ] | >>> | 0x0000000A | HopSelector | [ RFC-to-be ] | >>> | 0x0000000B | ExceptionID | [ RFC-to-be ] | >>> | 0x0000000C | ValidateErrorID | [ RFC-to-be ] | >>> | 0x0000000D | L3PortID | [ RFC-to-be ] | >>> | 0x0000000E | RedirectIndex | [ RFC-to-be ] | >>> | 0x0000000F | MediaEncapInfoIndex | [ RFC-to-be ] | >>> +--------------+-------------------------+--------------------------+ >>> >>> >>> Third, a new registry called the "Exception ID Namespace" is to be created in the >>> Forwarding and Control Element Separation (ForCES) registry located at: >>> >>> www.iana.org/assignments/forces/forces.xml >>> >>> Exception ID values are 32 bits long. >>> >>> The rules for registration in this subregistry are: >>> >>> For Exception ID values 0x00000000-0x7FFFFFFF maintenance is done through >>> Specification Required as defined by RFC 5226. >>> >>> The authors request that for Exception ID values 0x80000000-0xFFFFFFFF: >>> "Exception IDs in this range are reserved for vendor private extensions and are >>> the responsibility of individuals." >>> >>> Question - Do the authors mean that this range is maintained via Private Use as >>> defined in RFC 5226? >>> >>> There are initial registrations in this subregistry as follows: >>> >>> +--------------+---------------------------------+------------------+ >>> | Value | Name | Reference | >>> +--------------+---------------------------------+------------------+ >>> | 0x00000000 | AnyUnrecognizedExceptionCase | [ RFC-to-be ] | >>> | 0x00000001 | ClassifyNoMatching | [ RFC-to-be ] | >>> | 0x00000002 | MediaEncapInfoIndexInvalid | [ RFC-to-be ] | >>> | 0x00000003 | EncapTableLookupFailed | [ RFC-to-be ] | >>> | 0x00000004 | BadTTL | [ RFC-to-be ] | >>> | 0x00000005 | IPv4HeaderLengthMismatch | [ RFC-to-be ] | >>> | 0x00000006 | RouterAlertOptions | [ RFC-to-be ] | >>> | 0x00000007 | IPv6HopLimitZero | [ RFC-to-be ] | >>> | 0x00000008 | IPv6NextHeaderHBH | [ RFC-to-be ] | >>> | 0x00000009 | SrcAddressExecption | [ RFC-to-be ] | >>> | 0x0000000A | DstAddressExecption | [ RFC-to-be ] | >>> | 0x0000000B | LPMLookupFailed | [ RFC-to-be ] | >>> | 0x0000000C | HopSelectorInvalid | [ RFC-to-be ] | >>> | 0x0000000D | NextHopLookupFailed | [ RFC-to-be ] | >>> | 0x0000000E | FragRequired | [ RFC-to-be ] | >>> | 0x0000000F | MetadataNoMatching | [ RFC-to-be ] | >>> +--------------+---------------------------------+------------------+ >>> >>> Fourth, a new registry called the "Validate Error ID Namespace" is to be created in >>> the Forwarding and Control Element Separation (ForCES) registry located at: >>> >>> www.iana.org/assignments/forces/forces.xml >>> >>> Validate Error ID values are 32 bits long. >>> >>> The rules for registration in this subregistry are: >>> >>> For Validate Error ID values 0x00000000-0x7FFFFFFF maintenance is done >>> through Specification Required as defined by RFC 5226. >>> >>> The authors request that for Validate Error ID values 0x80000000-0xFFFFFFFF: >>> "Validate Error IDs in this range are reserved for vendor private extensions and >>> are the responsibility of individuals." >>> >>> Question - Do the authors mean that this range is maintained via Private Use as >>> defined in RFC 5226? >>> >>> There are initial registrations in this subregistry as follows: >>> >>> +--------------+---------------------------------+------------------+ >>> | Value | Name | Definition | >>> +--------------+---------------------------------+------------------+ >>> | 0x00000000 | AnyUnrecognizedValidateErrorCase| [ RFC-to-be ] | >>> | 0x00000001 | InvalidIPv4PacketSize | [ RFC-to-be ] | >>> | 0x00000002 | NotIPv4Packet | [ RFC-to-be ] | >>> | 0x00000003 | InvalidIPv4HeaderLengthSize | [ RFC-to-be ] | >>> | 0x00000004 | InvalidIPv4LengthFieldSize | [ RFC-to-be ] | >>> | 0x00000005 | InvalidIPv4Checksum | [ RFC-to-be ] | >>> | 0x00000006 | InvalidIPv4SrcAddr | [ RFC-to-be ] | >>> | 0x00000007 | InvalidIPv4DstAddr | [ RFC-to-be ] | >>> | 0x00000008 | InvalidIPv6PakcetSize | [ RFC-to-be ] | >>> | 0x00000009 | NotIPv6Packet | [ RFC-to-be ] | >>> | 0x0000000A | InvalidIPv6SrcAddr | [ RFC-to-be ] | >>> | 0x0000000B | InvalidIPv6DstAddr | [ RFC-to-be ] | >>> +--------------+---------------------------------+------------------+ >>> >>> We understand that these four actions are the only ones required to be >>> completed upon approval of this document. >>> >>> Note: The actions requested in this document will not be completed >>> until the document has been approved for publication as an RFC. >>> This message is only to confirm what actions will be performed. >>> >>> Thanks, >>> >>> Pearl Liang >>> ICANN/IANA >>> >>> (END IANA LAST CALL COMMENTS) >>> >>> >>> On Mon Jan 28 12:03:42 2013, noreply@ietf.org wrote: >>>> >>>> The IESG has received a request from the Forwarding and Control Element >>>> Separation WG (forces) to consider the following document: >>>> - 'ForCES Logical Function Block (LFB) Library' >>>> as Proposed Standard >>>> >>>> The IESG plans to make a decision in the next few weeks, and solicits >>>> final comments on this action. Please send substantive comments to the >>>> ietf@ietf.org mailing lists by 2013-02-11. Exceptionally, comments may be >>>> sent to iesg@ietf.org instead. In either case, please retain the >>>> beginning of the Subject line to allow automated sorting. >>>> >>>> Abstract >>>> >>>> This document defines basic classes of Logical Function Blocks (LFBs) >>>> used in the Forwarding and Control Element Separation (ForCES). The >>>> basic LFB classes are defined according to ForCES FE model and ForCES >>>> protocol specifications, and are scoped to meet requirements of >>>> typical router functions and considered as the basic LFB library for >>>> ForCES. The library includes the descriptions of the LFBs and the >>>> XML definitions. >>>> >>>> >>>> The file can be obtained via >>>> http://datatracker.ietf.org/doc/draft-ietf-forces-lfb-lib/ >>>> >>>> IESG discussion can be tracked via >>>> http://datatracker.ietf.org/doc/draft-ietf-forces-lfb-lib/ballot/ >>>> >>>> >>>> No IPR declarations have been submitted directly on this I-D. >>>> >> >> _______________________________________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/listinfo/forces > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From hadi@mojatatu.com Sun Feb 10 08:43:33 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E60121F85FD for ; Sun, 10 Feb 2013 08:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.877 X-Spam-Level: X-Spam-Status: No, score=-102.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYxnawzmprOT for ; Sun, 10 Feb 2013 08:43:33 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9265221F85F0 for ; Sun, 10 Feb 2013 08:43:32 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id l6so3306142vcl.31 for ; Sun, 10 Feb 2013 08:43:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=KNk+6QeELbnFqF8Y7eScBHAKlnfs+iD9/3rOQXn9LL4=; b=Qf3WVB+LK1rm9aHAsLipBrqxecS5dEkeFQgPpKww2hGOB18ZvlefoFWoWzo8TKwSJ8 JhB2aqTZmamUt654IGL4eXeqEVBnaQR2CsdT/jnDnnGwqgoS8gKXm1z2WXah7geWAZOc s+2Ja8Bxe6lteFD/Cqf4gWRI5ckS7/JCZt9jLIM0ft5p/60cE+/nr32fiM5IRbWo5sYk 0jLWjmcBxdPq5U8ThSL6ZVZZtR4/7dmOqHwOiKHh+p1diN5SIm3Sq87Z1boEXxldp/dA uU2+f87/MxcdADMBPVh0wxMha8e+VDcZeVbEd9h8YwqfiZAnC4SznsZCfDCUzA9dTeeF u1iQ== X-Received: by 10.58.253.161 with SMTP id ab1mr15182887ved.55.1360514611779; Sun, 10 Feb 2013 08:43:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.102.136 with HTTP; Sun, 10 Feb 2013 08:43:11 -0800 (PST) In-Reply-To: <5115C08F.60605@stevecrocker.com> References: <20130128200315.11251.6339.idtracker@ietfa.amsl.com> <00ed01ce061c$241e9cc0$6c5bd640$@olddog.co.uk> <5115C08F.60605@stevecrocker.com> From: Jamal Hadi Salim Date: Sun, 10 Feb 2013 11:43:11 -0500 Message-ID: To: Joel Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmnSj7qdmBLDG9KCzg07W41TqPKJyA6t5nOEkNQhD1cqMbKd0/OFc90wrhtwYxHSBd6jDxB Cc: forces@ietf.org, draft-ietf-forces-lfb-lib.all@tools.ietf.org Subject: Re: [forces] FW: [IANA #654410] Last Call: (ForCES Logical FunctionBlock (LFB) Library) to Proposed Standard X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 16:43:33 -0000 On Fri, Feb 8, 2013 at 10:20 PM, Joel wrote: > Specification Required means that you have to provide a spec, but if you do > it is FCFS. Pure FCFS means that you simply request a number and you get > one. > It is quite reasonable to take the view that anything registered should have > a spec. I just wanted to make sure that was really the WG agreemet. > Nod (as in positive ACK) from here. cheers, jamal From ehalep@ece.upatras.gr Mon Feb 11 08:13:12 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1DC21F8A71 for ; Mon, 11 Feb 2013 08:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWm8--L7t+aQ for ; Mon, 11 Feb 2013 08:13:12 -0800 (PST) Received: from mailgate.ece.upatras.gr (mailgate1.ece.upatras.gr [150.140.189.22]) by ietfa.amsl.com (Postfix) with ESMTP id AA0FF21F8A6F for ; Mon, 11 Feb 2013 08:13:11 -0800 (PST) Received: from EhalepXPS (150.140.254.226) by mailgate1 (Axigen) with ESMTPA id 055CC9; Mon, 11 Feb 2013 18:25:39 +0200 From: "Haleplidis Evangelos" To: Date: Mon, 11 Feb 2013 18:13:04 +0200 Message-ID: <00df01ce0872$acd4e350$067ea9f0$@upatras.gr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E0_01CE0883.705DB350" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4IcqvCWnUUHn7FQB60ejeNs92GWw== Content-Language: el Subject: [forces] Event Condition Equal? X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 16:13:12 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00E0_01CE0883.705DB350 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Greetings to the list, While going over implementation, we came upon a case where it would be useful to advertise a state transition an FE has observed. In a state machine where there are more states to the left/right of the state of interest, it is hard to use event thresholds (greater than/less than). Is there a way to do that with the current event conditions? Do you we need to add a new equality condition for events? Regards, Evangelos Haleplidis. ------=_NextPart_000_00E0_01CE0883.705DB350 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings to the list,

 

While going over implementation, we = came upon a case where it would be useful to advertise a state = transition an FE has observed.

In a state machine where there are = more states to the left/right of the state of interest, it is hard to = use event thresholds (greater than/less than).

 

Is there a way to do that with the = current event conditions? Do you we need to add a new equality condition = for events?

 

Regards,

Evangelos = Haleplidis.

------=_NextPart_000_00E0_01CE0883.705DB350-- From joel@stevecrocker.com Mon Feb 11 09:33:04 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C4921F87E1 for ; Mon, 11 Feb 2013 09:33:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.331 X-Spam-Level: X-Spam-Status: No, score=0.331 tagged_above=-999 required=5 tests=[AWL=1.800, BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1gU4XSlbUuC for ; Mon, 11 Feb 2013 09:33:03 -0800 (PST) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 3474C21F87D2 for ; Mon, 11 Feb 2013 09:33:03 -0800 (PST) Received: from dummy.name; Mon, 11 Feb 2013 17:33:14 +0000 Message-ID: <51192B46.7070701@stevecrocker.com> Date: Mon, 11 Feb 2013 12:32:54 -0500 From: Joel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Haleplidis Evangelos References: <00df01ce0872$acd4e350$067ea9f0$@upatras.gr> In-Reply-To: <00df01ce0872$acd4e350$067ea9f0$@upatras.gr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces@ietf.org Subject: Re: [forces] Event Condition Equal? X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 17:33:04 -0000 Does handle what you want? Yours, Joel On 2/11/2013 11:13 AM, Haleplidis Evangelos wrote: > Greetings to the list, > > While going over implementation, we came upon a case where it would be > useful to advertise a state transition an FE has observed. > > In a state machine where there are more states to the left/right of the > state of interest, it is hard to use event thresholds (greater than/less > than). > > Is there a way to do that with the current event conditions? Do you we > need to add a new equality condition for events? > > Regards, > > Evangelos Haleplidis. > > > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From ehalep@gmail.com Mon Feb 11 10:18:18 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D79321F8786 for ; Mon, 11 Feb 2013 10:18:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEc4qOYhigkQ for ; Mon, 11 Feb 2013 10:18:18 -0800 (PST) Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by ietfa.amsl.com (Postfix) with ESMTP id D033021F8780 for ; Mon, 11 Feb 2013 10:18:17 -0800 (PST) Received: by mail-ee0-f48.google.com with SMTP id t10so3429854eei.21 for ; Mon, 11 Feb 2013 10:18:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=qwBiHhxLItUM33S2fNkagzmZnHWOJrFu19PnCVMI76s=; b=kfaz5y2zdeJCC3q/tuGcLTCB4V6AJM1PhmMTJd9TkDQGcdhBkQp98J7d0ge6UxZ6d0 CH81+3v0xIms58WFrRJGdcwYj8VNMaaCFHq/Z7Mq7S0YbrBfOkfvvsArcD2tphiiZlCc HQdro8OwEK4UGECT5ZdngDH4BXpj0lFhsCfexv+k+9TrCKMvbO9bP2/9wxWV8H0LAX+f sBWJYcZJQ1cPb69WPxZyX7d68kAXj66mrg5OEgP0L/aZ8ulB5uloHnQM2D7PIyZmjGC4 phJGl6DN9RQ+eJNx51oQb2qQ2z15GNy7ZQiHic7Ac4ZD4+dgmMK7hu9P16bxPlYxxQEM 9Reg== X-Received: by 10.14.194.4 with SMTP id l4mr53415594een.12.1360606696961; Mon, 11 Feb 2013 10:18:16 -0800 (PST) Received: from EhalepXPS (ppp079166086235.access.hol.gr. [79.166.86.235]) by mx.google.com with ESMTPS id 3sm63868239eej.6.2013.02.11.10.18.14 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 11 Feb 2013 10:18:15 -0800 (PST) From: "Haleplidis Evangelos" To: "'Joel'" References: <00df01ce0872$acd4e350$067ea9f0$@upatras.gr> <51192B46.7070701@stevecrocker.com> In-Reply-To: <51192B46.7070701@stevecrocker.com> Date: Mon, 11 Feb 2013 20:18:09 +0200 Message-ID: <00f601ce0884$26f68b00$74e3a100$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4If5yCIotz1aYpSkm4+RxSgv2V7QAAbU3w Content-Language: el Cc: forces@ietf.org Subject: Re: [forces] Event Condition Equal? X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 18:18:18 -0000 Greetings Joel, Thanks for the reply. I probably didn't elaborate enough in the previous email. Our case involves an issue where we would like to target a specific value of the state instead of any change of the state, therefore an event would be generated if the state reaches that state only. Event changed would not be sufficient as it would report any change. It probably would be done with event changed and event hysteresis property, but it would be very messy. Regards, Evangelos Haleplidis. > -----Original Message----- > From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On > Behalf Of Joel > Sent: Monday, February 11, 2013 7:33 PM > To: Haleplidis Evangelos > Cc: forces@ietf.org > Subject: Re: [forces] Event Condition Equal? > > Does handle what you want? > > Yours, > Joel > > On 2/11/2013 11:13 AM, Haleplidis Evangelos wrote: > > Greetings to the list, > > > > While going over implementation, we came upon a case where it would > be > > useful to advertise a state transition an FE has observed. > > > > In a state machine where there are more states to the left/right of > > the state of interest, it is hard to use event thresholds (greater > > than/less than). > > > > Is there a way to do that with the current event conditions? Do you > we > > need to add a new equality condition for events? > > > > Regards, > > > > Evangelos Haleplidis. > > > > > > > > _______________________________________________ > > forces mailing list > > forces@ietf.org > > https://www.ietf.org/mailman/listinfo/forces > > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From joel@stevecrocker.com Mon Feb 11 11:31:05 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CACE921F87D4 for ; Mon, 11 Feb 2013 11:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.569 X-Spam-Level: X-Spam-Status: No, score=-0.569 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOKiSbwN+0kr for ; Mon, 11 Feb 2013 11:31:05 -0800 (PST) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 532DF21F87D2 for ; Mon, 11 Feb 2013 11:31:04 -0800 (PST) Received: from dummy.name; Mon, 11 Feb 2013 19:31:17 +0000 Message-ID: <511946F0.8000705@stevecrocker.com> Date: Mon, 11 Feb 2013 14:30:56 -0500 From: Joel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Haleplidis Evangelos References: <00df01ce0872$acd4e350$067ea9f0$@upatras.gr> <51192B46.7070701@stevecrocker.com> <00f601ce0884$26f68b00$74e3a100$@com> In-Reply-To: <00f601ce0884$26f68b00$74e3a100$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces@ietf.org Subject: Re: [forces] Event Condition Equal? X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 19:31:05 -0000 Well, one way would be a bit of a hack, but would handle the case where there is only one state were you need the tansition-out reported. That would be to arrange the numeric values of the states so that it is either lowest or highest. Then the comparators will work. Otherwise, we would need a new changeFrom event. I would need to see more details to know whether that makes sense. Yours, Joel On 2/11/2013 1:18 PM, Haleplidis Evangelos wrote: > Greetings Joel, > > Thanks for the reply. I probably didn't elaborate enough in the previous > email. > > Our case involves an issue where we would like to target a specific value of > the state instead of any change of the state, therefore an event would be > generated if the state reaches that state only. > > Event changed would not be sufficient as it would report any change. It > probably would be done with event changed and event hysteresis property, but > it would be very messy. > > Regards, > Evangelos Haleplidis. > >> -----Original Message----- >> From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On >> Behalf Of Joel >> Sent: Monday, February 11, 2013 7:33 PM >> To: Haleplidis Evangelos >> Cc: forces@ietf.org >> Subject: Re: [forces] Event Condition Equal? >> >> Does handle what you want? >> >> Yours, >> Joel >> >> On 2/11/2013 11:13 AM, Haleplidis Evangelos wrote: >>> Greetings to the list, >>> >>> While going over implementation, we came upon a case where it would >> be >>> useful to advertise a state transition an FE has observed. >>> >>> In a state machine where there are more states to the left/right of >>> the state of interest, it is hard to use event thresholds (greater >>> than/less than). >>> >>> Is there a way to do that with the current event conditions? Do you >> we >>> need to add a new equality condition for events? >>> >>> Regards, >>> >>> Evangelos Haleplidis. >>> >>> >>> >>> _______________________________________________ >>> forces mailing list >>> forces@ietf.org >>> https://www.ietf.org/mailman/listinfo/forces >>> >> _______________________________________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/listinfo/forces > From ehalep@gmail.com Sun Feb 17 12:38:32 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBD121E803A for ; Sun, 17 Feb 2013 12:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXMP4zSFCzGN for ; Sun, 17 Feb 2013 12:38:31 -0800 (PST) Received: from mail-ea0-f169.google.com (mail-ea0-f169.google.com [209.85.215.169]) by ietfa.amsl.com (Postfix) with ESMTP id 99DFB21F8A52 for ; Sun, 17 Feb 2013 12:38:31 -0800 (PST) Received: by mail-ea0-f169.google.com with SMTP id d13so2225451eaa.28 for ; Sun, 17 Feb 2013 12:38:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=9canuwyztNx6xTE+sXhj+j2nCET30SR3Q/9lXBD/sm4=; b=WzWwsUM8/QKtS2pkQF3G9dkSusIz0EYjpjO/ysbASLy9PPENz/auuS6DVckyscjc7r BIbSa6gVWhacUdfQ5/7+15hjTRXt5WiXnybr+GaAE4qyMXHd0ZXHE8Vd6H4Ft7kkPSLb qHhS9r4cy1gU3tZReVkO3SfQ5oYemEyFBfbjlrFqIPijX0DZRY5mUhWvg/bbZ6kUkk69 9XxBy9FEVnM5Fu4KVm8xBgwG0PpTT7dYFE8jUHtqW82eeNnbJ38b30ydSXgd37ipyBHH PXMh4nSmHHflImqZjrhhQO3r+WS80aI1M1vTiB6bfGq0pIS9ngvMENyxqnNi18Qh0G7L Vo8Q== X-Received: by 10.14.201.5 with SMTP id a5mr36360573eeo.17.1361133510573; Sun, 17 Feb 2013 12:38:30 -0800 (PST) Received: from EhalepXPS (ppp141237071118.access.hol.gr. [141.237.71.118]) by mx.google.com with ESMTPS id t4sm95033974eel.0.2013.02.17.12.38.28 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 17 Feb 2013 12:38:29 -0800 (PST) From: "Haleplidis Evangelos" To: "'Joel'" References: <00df01ce0872$acd4e350$067ea9f0$@upatras.gr> <51192B46.7070701@stevecrocker.com> <00f601ce0884$26f68b00$74e3a100$@com> <511946F0.8000705@stevecrocker.com> In-Reply-To: <511946F0.8000705@stevecrocker.com> Date: Sun, 17 Feb 2013 22:38:25 +0200 Message-ID: <002301ce0d4e$bded2a90$39c77fb0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4IjlXoouwDeRKkT6+ee12mhNOK2QEreBtg Content-Language: el Cc: forces@ietf.org Subject: Re: [forces] Event Condition Equal? X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 20:38:32 -0000 Greetings Joel, Our current use case is the CEHA. It would be useful for the master CE to know when either a backup CE is associated (one case would be to synchronize) but would be uninterested at the rest of the states. The CE could poll the FE periodically for this info, but it would be more efficient with an event. I agree that the hack you suggest can be useful. Regards, Evangelos Haleplidis. > -----Original Message----- > From: Joel [mailto:joel@stevecrocker.com] > Sent: Monday, February 11, 2013 9:31 PM > To: Haleplidis Evangelos > Cc: forces@ietf.org > Subject: Re: [forces] Event Condition Equal? > > Well, one way would be a bit of a hack, but would handle the case where > there is only one state were you need the tansition-out reported. That > would be to arrange the numeric values of the states so that it is > either lowest or highest. Then the comparators will work. > > Otherwise, we would need a new changeFrom event. I would need to see > more details to know whether that makes sense. > > Yours, > Joel > > On 2/11/2013 1:18 PM, Haleplidis Evangelos wrote: > > Greetings Joel, > > > > Thanks for the reply. I probably didn't elaborate enough in the > > previous email. > > > > Our case involves an issue where we would like to target a specific > > value of the state instead of any change of the state, therefore an > > event would be generated if the state reaches that state only. > > > > Event changed would not be sufficient as it would report any change. > > It probably would be done with event changed and event hysteresis > > property, but it would be very messy. > > > > Regards, > > Evangelos Haleplidis. > > > >> -----Original Message----- > >> From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On > >> Behalf Of Joel > >> Sent: Monday, February 11, 2013 7:33 PM > >> To: Haleplidis Evangelos > >> Cc: forces@ietf.org > >> Subject: Re: [forces] Event Condition Equal? > >> > >> Does handle what you want? > >> > >> Yours, > >> Joel > >> > >> On 2/11/2013 11:13 AM, Haleplidis Evangelos wrote: > >>> Greetings to the list, > >>> > >>> While going over implementation, we came upon a case where it would > >> be > >>> useful to advertise a state transition an FE has observed. > >>> > >>> In a state machine where there are more states to the left/right of > >>> the state of interest, it is hard to use event thresholds (greater > >>> than/less than). > >>> > >>> Is there a way to do that with the current event conditions? Do you > >> we > >>> need to add a new equality condition for events? > >>> > >>> Regards, > >>> > >>> Evangelos Haleplidis. > >>> > >>> > >>> > >>> _______________________________________________ > >>> forces mailing list > >>> forces@ietf.org > >>> https://www.ietf.org/mailman/listinfo/forces > >>> > >> _______________________________________________ > >> forces mailing list > >> forces@ietf.org > >> https://www.ietf.org/mailman/listinfo/forces > > From hadi@mojatatu.com Mon Feb 18 03:20:41 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0757D21F88E5 for ; Mon, 18 Feb 2013 03:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.902 X-Spam-Level: X-Spam-Status: No, score=-102.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4I6hnvsssZo4 for ; Mon, 18 Feb 2013 03:20:39 -0800 (PST) Received: from mail-vb0-f41.google.com (mail-vb0-f41.google.com [209.85.212.41]) by ietfa.amsl.com (Postfix) with ESMTP id A5A2421F88D8 for ; Mon, 18 Feb 2013 03:20:38 -0800 (PST) Received: by mail-vb0-f41.google.com with SMTP id l22so3544632vbn.0 for ; Mon, 18 Feb 2013 03:20:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=xz3N9MIR15QrGLi62sbxXJwrY6wUjtH9Dx6HUAygmzM=; b=Pf2BGyMo9Iz/O2xwP+bhufRtmZELP4M8NOGsmPTEykeJtmvn1Q83KbsJ7SV5j5lTUX VmYIo7lYHN4Ko18iHvuklw/1I4uA1xko/nLw2KSthI2HboSYAdCW0f/BAeYAFkUhhs+H 4TVYSaG7RUUgwYzt2WPZTDFB/30ydvuZEqrDEPvg4M+8Cz2CoRDhB2aYnVihO/6vnP+j Kz+SnW41PfNTL7zqS0YeHtopb4CYCtjioMu+6ajc/4fXhf5ZlAF6eMezOJ6r8+3eD93n JmaO2RlH6HcO1nRTzbJqYS5zyTCKTZSudoC7oibEbakgxnTUvfnhLG+aecFEaA6KwQ9V Pdbg== X-Received: by 10.58.233.210 with SMTP id ty18mr15275145vec.46.1361186433344; Mon, 18 Feb 2013 03:20:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.136.105 with HTTP; Mon, 18 Feb 2013 03:20:13 -0800 (PST) From: Jamal Hadi Salim Date: Mon, 18 Feb 2013 06:20:13 -0500 Message-ID: To: forces@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm25MKAsXD3E6+eR3F7xEaPlc07cHt0QX7gkl2UNJsVdoxRq7J7rBJzw3d6Im6aeA3wMyGC Subject: [forces] FeObject FEState X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 11:20:41 -0000 folks, While doing intense review of the CEHA with Evangelos so we can publish we came across an old issue. FEObject::FEState is tagged as read-only. The CE controls the transition from OperEnable to/from AdminDisable but that cant happen if it is RO. We needed this during testing - so an easy solution is to change FEState to be RW. Q: What is the best practise thing to do amongst: a) use the CEHA as an update to specify that this field is considered RW b) Create an errata for RFC 5812 c) Leave it alone - add a new component in the FEPO LFB to control the forwarding operations (seems more natural from an operational view). cheers, jamal From hadi@mojatatu.com Mon Feb 18 03:31:25 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965D021F8911 for ; Mon, 18 Feb 2013 03:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.917 X-Spam-Level: X-Spam-Status: No, score=-102.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPTGFuDNqWTk for ; Mon, 18 Feb 2013 03:31:25 -0800 (PST) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by ietfa.amsl.com (Postfix) with ESMTP id ECC1721F890D for ; Mon, 18 Feb 2013 03:31:24 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id m18so3494664vcm.22 for ; Mon, 18 Feb 2013 03:31:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to:cc :content-type:x-gm-message-state; bh=/dSpZ+0fQaGbgHydsdw1+TQcYe02vpkbOIqU4pki3kc=; b=liO6Onfuq8tiQ9fIPUxmcFAUm3A5KTVnhyVIILg5BDMkot79zSyPP35dfJNZXEGflL dES4SsOLjXZe7JYmlORtXX4/z8s0MLvKq8q7ZfECdhQJrT+fSCX8a2KPaxrh61WqIDle Cb5QHnbetas00aU3Z9MH23fuPDniWzSbaQdy8XnjU0dzaowayV3/8iJkR5XXpjIsyzPT 1YUB5zc2rLdHCQ/Z8GzQb9aH39KLSbde/o/XdEcNH/bYcSz1cpLWvJ4xd/Vk1sTm6U3M PzySd+lHPjxvTDShQvccQMsnSRcRMBaznWNgZtMxIYVU2Mq5iPSBQ1PwUQeQWCSFw3wm nvlA== X-Received: by 10.220.40.9 with SMTP id i9mr15073875vce.23.1361187084277; Mon, 18 Feb 2013 03:31:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.136.105 with HTTP; Mon, 18 Feb 2013 03:31:04 -0800 (PST) From: Jamal Hadi Salim Date: Mon, 18 Feb 2013 06:31:04 -0500 Message-ID: To: forces@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmMbRe6Xu/vwyUhWzTBWlqkSbEm+DMbLHjOJTckCQAj9b/KlFB2OoR9Y/03Rp3qNVRNUGGd Subject: [forces] CEHA document update X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 11:31:25 -0000 Hi, Based on current implementation and deployment experience, the authors have reached a conclusion we need to simplify things from the previous draft. We have removed from the draft 3 things and added one. For this reason, we would like to allow for time to simmer the changes and hopefully receive comments on the content before going to ask for a WG last call. We hope to publish the updated draft in the next 1-2 days. The changes are: 1) Remove the confirm state therefore reducing the state machine for hot-standby to be very similar to cold-standy with some very small differences. Justification: The elected master CE can already override its mastership to another CE by setting the CEID field. The FE is already well aware of the liveliness of the backup CE, so an extra confirmation does not change things. 2) Remove the filter control for allowing whether backup CEs can do queries. Justification: We found that in all cases we have encountered, associating to a backup CE results in the backup CE needing to find some FE state (as minimal as pulling FEPO or FEObject information from the FE). Implementations are free to put filters via the FEM if really deemed necessary. 3) Simplify Events. We keep the PrimaryCEDown event from RFC 5810 and continue to generate it for both hot and cold stand-by. We change the new PrimaryCEChanged event to only advertise the new master CE. Justification: This gives us backward compatibility for free. 4) Statistics We have added statistics to the ALLCES table for each CE as perceived by the FE. These stats will define receive/transmit packets/bytes as well as errors. During deployment, the statistics turned out to be very useful for debugging. cheers, jamal From joel@stevecrocker.com Mon Feb 18 08:07:54 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E8321F8A89 for ; Mon, 18 Feb 2013 08:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YR13rw-sBt6 for ; Mon, 18 Feb 2013 08:07:53 -0800 (PST) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id AAD9B21F8A84 for ; Mon, 18 Feb 2013 08:07:53 -0800 (PST) Received: from dummy.name; Mon, 18 Feb 2013 16:08:18 +0000 Message-ID: <512251CD.5040300@stevecrocker.com> Date: Mon, 18 Feb 2013 11:07:41 -0500 From: Joel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Jamal Hadi Salim References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces@ietf.org Subject: Re: [forces] FeObject FEState X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 16:07:54 -0000 Given that we simltaneously specified that this was RO and that the CE needed to change this, I would make this an errata. I would inlcude a line in the CEHA draft mentioning the errata to explain t readers why what is describd there is consistent with the existing mechanisms. Yours, Joel On 2/18/2013 6:20 AM, Jamal Hadi Salim wrote: > folks, > > While doing intense review of the CEHA with Evangelos so we can publish > we came across an old issue. FEObject::FEState is tagged as read-only. > The CE controls the transition from OperEnable to/from AdminDisable but > that cant happen if it is RO. > We needed this during testing - so an easy solution is to change FEState > to be RW. > Q: What is the best practise thing to do amongst: > > a) use the CEHA as an update to specify that this field is considered RW > b) Create an errata for RFC 5812 > c) Leave it alone - add a new component in the FEPO LFB to control the > forwarding operations (seems more natural from an operational view). > > cheers, > jamal > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From damascene.joachimpillai@verizon.com Mon Feb 18 09:00:25 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953F121F8C2F for ; Mon, 18 Feb 2013 09:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lMJnXz0QbE0 for ; Mon, 18 Feb 2013 09:00:22 -0800 (PST) Received: from fldsmtpe03.verizon.com (fldsmtpe03.verizon.com [140.108.26.142]) by ietfa.amsl.com (Postfix) with ESMTP id 1F02A21F8C3C for ; Mon, 18 Feb 2013 09:00:21 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe03.verizon.com with ESMTP; 18 Feb 2013 17:00:20 +0000 From: "Joachimpillai, Damascene M" X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; d="scan'208";a="415501626" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi02.verizon.com with ESMTP; 18 Feb 2013 17:00:12 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Mon, 18 Feb 2013 12:00:11 -0500 To: 'Jamal Hadi Salim' , "forces@ietf.org" Date: Mon, 18 Feb 2013 12:00:11 -0500 Thread-Topic: [forces] CEHA document update Thread-Index: Ac4Ny4PVCWLe43zLTC+tbp3jHEejEwALdF5w Message-ID: <689CE984BDBA8B4CAF3EA6E2CDC5CACB0116D4FFED@FHDP1LUMXC7V31.us.one.verizon.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [forces] CEHA document update X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 17:00:25 -0000 Where can I find the draft for CEHA? This is very important for our design. -- DJ -----Original Message----- From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of= Jamal Hadi Salim Sent: Monday, February 18, 2013 6:31 AM To: forces@ietf.org Subject: [forces] CEHA document update Hi, Based on current implementation and deployment experience, the authors have= reached a conclusion we need to simplify things from the previous draft. We have removed from the draft 3 things and added one. For this reason, we would like to allow for time to simmer the changes and = hopefully receive comments on the content before going to ask for a WG last= call. We hope to publish the updated draft in the next 1-2 days. The changes are: 1) Remove the confirm state therefore reducing the state machine for hot-s= tandby to be very similar to cold-standy with some very small differences. Justification: The elected master CE can already override its mastership to another CE by = setting the CEID field. The FE is already well aware of the liveliness of the backup CE, so an extr= a confirmation does not change things. 2) Remove the filter control for allowing whether backup CEs can do queries= . Justification: We found that in all cases we have encountered, associating= to a backup CE results in the backup CE needing to find some FE state (as= minimal as pulling FEPO or FEObject information from the FE). Implementations are free to put filters via the FEM if really deemed necess= ary. 3) Simplify Events. We keep the PrimaryCEDown event from RFC 5810 and continue to generate it f= or both hot and cold stand-by. We change the new PrimaryCEChanged event to only advertise the new master C= E. Justification: This gives us backward compatibility for free. 4) Statistics We have added statistics to the ALLCES table for each CE as perceived by th= e FE. These stats will define receive/transmit packets/bytes as well as err= ors. During deployment, the statistics turned out to be very useful for deb= ugging. cheers, jamal _______________________________________________ forces mailing list forces@ietf.org https://www.ietf.org/mailman/listinfo/forces From hadi@mojatatu.com Mon Feb 18 10:36:38 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A3921F8B1A for ; Mon, 18 Feb 2013 10:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.927 X-Spam-Level: X-Spam-Status: No, score=-102.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pu+YPTmWZ+ub for ; Mon, 18 Feb 2013 10:36:38 -0800 (PST) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by ietfa.amsl.com (Postfix) with ESMTP id BE4DC21F8AED for ; Mon, 18 Feb 2013 10:36:37 -0800 (PST) Received: by mail-ve0-f171.google.com with SMTP id b10so5059328vea.16 for ; Mon, 18 Feb 2013 10:36:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=cUibi0zLmBAQdOGOYBQ9k++WiYB/ImwDvjpLpHisFE8=; b=WArp76KDCUzu0/1JRZXpuki3CQmA9rhwTPgSCXMGH29y8kg97b7xkZvQGkDdHv7hso o+swl1vMHLNRvB4BpVjzJYe8tbu+7moDSQ00BAYRnsBqs81oa7SPUXOFkSthY0ss9I57 20qmq3DH+OWDLAFGgMZq/PII9PWklwSLMswOtu/2QFr1NHWTUShC5WMXtfAAwybpheAz 9c93TUlHqFgbtJ5vEaDb0TxSYlyNx3TWYf97UDpDLggKh+djlyAQ964B7pzz/o1I3Lro 821EA/SXJsKgRajAb3/2fPsGFxzJFT1e8WbZ2uV/4osQqzqNGnK8kH9A8iMCHUAiTW2W IQiQ== X-Received: by 10.58.48.231 with SMTP id p7mr17607619ven.11.1361212597102; Mon, 18 Feb 2013 10:36:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.136.105 with HTTP; Mon, 18 Feb 2013 10:36:17 -0800 (PST) In-Reply-To: <689CE984BDBA8B4CAF3EA6E2CDC5CACB0116D4FFED@FHDP1LUMXC7V31.us.one.verizon.com> References: <689CE984BDBA8B4CAF3EA6E2CDC5CACB0116D4FFED@FHDP1LUMXC7V31.us.one.verizon.com> From: Jamal Hadi Salim Date: Mon, 18 Feb 2013 13:36:17 -0500 Message-ID: To: "Joachimpillai, Damascene M" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnOpVAAzX/JHOBG+/GrHQnkqba4jRGqXsH8xBKzUxnPjFqMjnmRlhUZCv38mIR3tJnWoPr9 Cc: "forces@ietf.org" Subject: Re: [forces] CEHA document update X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 18:36:39 -0000 Hi DJ, Evangelos should be able to post it later today. cheers, jamal On Mon, Feb 18, 2013 at 12:00 PM, Joachimpillai, Damascene M wrote: > Where can I find the draft for CEHA? This is very important for our design. > > -- DJ > > -----Original Message----- > From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of Jamal Hadi Salim > Sent: Monday, February 18, 2013 6:31 AM > To: forces@ietf.org > Subject: [forces] CEHA document update > > Hi, > > Based on current implementation and deployment experience, the authors have reached a conclusion we need to simplify things from the previous draft. > We have removed from the draft 3 things and added one. > For this reason, we would like to allow for time to simmer the changes and hopefully receive comments on the content before going to ask for a WG last call. > We hope to publish the updated draft in the next 1-2 days. > > The changes are: > 1) Remove the confirm state therefore reducing the state machine for hot-standby to be very similar to cold-standy with some very small differences. > Justification: > The elected master CE can already override its mastership to another CE by setting the CEID field. > The FE is already well aware of the liveliness of the backup CE, so an extra confirmation does not change things. > > 2) Remove the filter control for allowing whether backup CEs can do queries. > Justification: We found that in all cases we have encountered, associating to a backup CE results in the backup CE needing to find some FE state (as minimal as pulling FEPO or FEObject information from the FE). > Implementations are free to put filters via the FEM if really deemed necessary. > > 3) Simplify Events. > We keep the PrimaryCEDown event from RFC 5810 and continue to generate it for both hot and cold stand-by. > We change the new PrimaryCEChanged event to only advertise the new master CE. > Justification: This gives us backward compatibility for free. > > 4) Statistics > We have added statistics to the ALLCES table for each CE as perceived by the FE. These stats will define receive/transmit packets/bytes as well as errors. During deployment, the statistics turned out to be very useful for debugging. > > cheers, > jamal > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From wwwrun@rfc-editor.org Mon Feb 18 10:42:30 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9A421F86CC for ; Mon, 18 Feb 2013 10:42:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.364 X-Spam-Level: X-Spam-Status: No, score=-102.364 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exKP4Eg3Zwn2 for ; Mon, 18 Feb 2013 10:42:30 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 707E221F8427 for ; Mon, 18 Feb 2013 10:42:30 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id DF0A6B1E002; Mon, 18 Feb 2013 10:41:46 -0800 (PST) To: jmh@joelhalpern.com, hadi@mojatatu.com, stbryant@cisco.com, adrian@olddog.co.uk, dro@zurich.ibm.com, hadi@mojatatu.com From: RFC Errata System Message-Id: <20130218184146.DF0A6B1E002@rfc-editor.org> Date: Mon, 18 Feb 2013 10:41:46 -0800 (PST) Cc: rfc-editor@rfc-editor.org, forces@ietf.org Subject: [forces] [Editorial Errata Reported] RFC5812 (3487) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 18:42:31 -0000 The following errata report has been submitted for RFC5812, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5812&eid=3487 -------------------------------------- Type: Editorial Reported by: Jamal Hadi Salim Section: 5.1 Original Text ------------- FEState State of this FE FEStateValues Corrected Text -------------- FEState State of this FE FEStateValues Notes ----- FEObject FEState (component ID 7) is read-write. It was mistakenly labelled read-only Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5812 (draft-ietf-forces-model-16) -------------------------------------- Title : Forwarding and Control Element Separation (ForCES) Forwarding Element Model Publication Date : March 2010 Author(s) : J. Halpern, J. Hadi Salim Category : PROPOSED STANDARD Source : Forwarding and Control Element Separation Area : Routing Stream : IETF Verifying Party : IESG From hadi@mojatatu.com Mon Feb 18 10:42:31 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72F621F86E3 for ; Mon, 18 Feb 2013 10:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.934 X-Spam-Level: X-Spam-Status: No, score=-102.934 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckMsspZHbi89 for ; Mon, 18 Feb 2013 10:42:31 -0800 (PST) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by ietfa.amsl.com (Postfix) with ESMTP id 081A221F8427 for ; Mon, 18 Feb 2013 10:42:30 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id fo13so3694456vcb.25 for ; Mon, 18 Feb 2013 10:42:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=PeQ2Cgc9MfpvAp3AOwAW4qGojFCigmg0AZWFk44MHMo=; b=p0eCd4IyN2Wm2ziJmGRzvj0JBXuaHvH8q941Fu3X7ErTD/2FTSVqR7HAx3zcnsSz+Y p52Qwv1nqr8l62IwTQj+YzflL2102woUkhm1yhY6PSaahDDUrNPeanZPG8GQC+eW5snf QTrYJyHZ8aNoKM9aMHnOZscaYyrWpYWahMROuI5fMPt74IzedPauRODMgSYa2tVrIDkr LoADGpinFXILxaSFUVu8w4ylw6nujTz36DuABydmimqJYw2XR7iri+jMyHvGPVm7FzXX OiTF7rcseR9Dr053gMs+HmwheQ4wO1i8Q07vhcfwf0Ger+PZNAhqEyZ8s5cH6Cki77wZ cXAg== X-Received: by 10.58.245.200 with SMTP id xq8mr17593787vec.21.1361212950345; Mon, 18 Feb 2013 10:42:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.136.105 with HTTP; Mon, 18 Feb 2013 10:42:10 -0800 (PST) In-Reply-To: <512251CD.5040300@stevecrocker.com> References: <512251CD.5040300@stevecrocker.com> From: Jamal Hadi Salim Date: Mon, 18 Feb 2013 13:42:10 -0500 Message-ID: To: Joel Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmnK7Msn2ejPjKpbbRocq9Dpz63llwi342yB+s7oSVBPfaK/0K8EUj9X5aZo5pH0X5T8rC+ Cc: forces@ietf.org Subject: Re: [forces] FeObject FEState X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 18:42:31 -0000 Thanks Joel. I will submit an errata - and we have updated the draft to point out this fact. cheers, jamal On Mon, Feb 18, 2013 at 11:07 AM, Joel wrote: > Given that we simltaneously specified that this was RO and that the CE > needed to change this, I would make this an errata. I would inlcude a line > in the CEHA draft mentioning the errata to explain t readers why what is > describd there is consistent with the existing mechanisms. > > Yours, > Joel > > > On 2/18/2013 6:20 AM, Jamal Hadi Salim wrote: >> >> folks, >> >> While doing intense review of the CEHA with Evangelos so we can publish >> we came across an old issue. FEObject::FEState is tagged as read-only. >> The CE controls the transition from OperEnable to/from AdminDisable but >> that cant happen if it is RO. >> We needed this during testing - so an easy solution is to change FEState >> to be RW. >> Q: What is the best practise thing to do amongst: >> >> a) use the CEHA as an update to specify that this field is considered RW >> b) Create an errata for RFC 5812 >> c) Leave it alone - add a new component in the FEPO LFB to control the >> forwarding operations (seems more natural from an operational view). >> >> cheers, >> jamal >> _______________________________________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/listinfo/forces >> > From internet-drafts@ietf.org Tue Feb 19 01:00:25 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB63721F8D69; Tue, 19 Feb 2013 01:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGSebrOW7M9s; Tue, 19 Feb 2013 01:00:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFBD521F8D70; Tue, 19 Feb 2013 01:00:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130219090023.16490.96804.idtracker@ietfa.amsl.com> Date: Tue, 19 Feb 2013 01:00:23 -0800 Cc: forces@ietf.org Subject: [forces] I-D Action: draft-ietf-forces-ceha-06.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 09:00:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Forwarding and Control Element Separation= Working Group of the IETF. Title : ForCES Intra-NE High Availability Author(s) : Kentaro Ogawa Weiming Wang Evangelos Haleplidis Jamal Hadi Salim Filename : draft-ietf-forces-ceha-06.txt Pages : 27 Date : 2013-02-19 Abstract: This document discusses CE High Availability within a ForCES NE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-forces-ceha There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-forces-ceha-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-forces-ceha-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hadi@mojatatu.com Tue Feb 19 17:17:30 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510F621F882F for ; Tue, 19 Feb 2013 17:17:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.94 X-Spam-Level: X-Spam-Status: No, score=-102.94 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBBJ1+8zYUiw for ; Tue, 19 Feb 2013 17:17:29 -0800 (PST) Received: from mail-ve0-f169.google.com (mail-ve0-f169.google.com [209.85.128.169]) by ietfa.amsl.com (Postfix) with ESMTP id B735121F87A3 for ; Tue, 19 Feb 2013 17:17:29 -0800 (PST) Received: by mail-ve0-f169.google.com with SMTP id 15so6563951vea.28 for ; Tue, 19 Feb 2013 17:17:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=MQwewLaUeidfJLm5bwb1nTmEBwbcnBLc76flY4z5O98=; b=Aa/StojR8mURwPZDU7AO/bH15/DnAfbolw+y2rcTGYSBbaDclfWPx0s6xV7GrP4Af4 onmYFBRcI0BCo3Q3GvqpV5tkuNshDPECR5ZeL/kO0tsSUqeG531F+jgXqW3/WtYDRZVb ZkLaMMHFLamrE6HncGWLLwCiNUDJJRXXHqRbLRIq8BsQaLUX4D3gFFD/mtfraQhOUK2Q NxDZyMMIk40e8cnahmjwlalgM7sVGqq2u7E2NAWrSshDoBnr1pqDQCZGXuGWehhMIA9T mpKVHi+LyCfTxZSUSF8dOzMDrsDxOfGRyGGAlni8dO2ztWpBOqFs7sBIygogBmHd7gJD 7/eA== X-Received: by 10.52.96.7 with SMTP id do7mr20068218vdb.115.1361323048993; Tue, 19 Feb 2013 17:17:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.251.210 with HTTP; Tue, 19 Feb 2013 17:17:08 -0800 (PST) From: Jamal Hadi Salim Date: Tue, 19 Feb 2013 20:17:08 -0500 Message-ID: To: forces@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm1SvVOb9EZbwViyGkFqu0fantuVRXv+Rv5aSTVyyvxBBbAzdm9tW5wGCmwSTB837lvHTx3 Subject: [forces] Upcoming meeting X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 01:17:30 -0000 Folks, As a follow up to the WG poll done earlier - the AD has allowed us to have a discussion of a proposed re-charter in the upcoming meeting. There will be a specific focus on some work items - not necessarily the most popular polled items. We are essentially going to have a discussion of advancing the work rather a presentation on why we should work on something. I will post more details later. cheers, jamal From ehalep@gmail.com Sat Feb 23 17:44:18 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C69C21F8F33 for ; Sat, 23 Feb 2013 17:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5mb-+azh5Mt for ; Sat, 23 Feb 2013 17:44:17 -0800 (PST) Received: from mail-ee0-f50.google.com (mail-ee0-f50.google.com [74.125.83.50]) by ietfa.amsl.com (Postfix) with ESMTP id 28B1921F8B60 for ; Sat, 23 Feb 2013 17:44:17 -0800 (PST) Received: by mail-ee0-f50.google.com with SMTP id e51so884038eek.23 for ; Sat, 23 Feb 2013 17:44:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=Dzo43Rbm83UKGU3ZIgxc9Y9BDdIYOl+/SXIsb0nXllQ=; b=CrLNTGKjCYtP7CojuJK3UOgp1vCS4Uu94Fu2zlYsDGma7mblxvlJDfy7tJbigkn/s6 +MSiNQQ1bOuk7VBYjv9YUXcVACd/NhHTj4i3jUHgCax1/KBZKquTVg9kip4t/DJ/PLB1 aGaocznC1CwaRght6JN7Zo6DKhakwk2ENE4p+bKH7U2/zy0sRl8OP9f82dLv/sa+hIuV KpCYaWL+nvGMIsvO8zE/HYrWG4bKRDsVWSki2LsKr5qG5QAHAxrHm1qKUs4vtQpjABdS jNMCcArkyHBjd8TgViL3gVWQPlDg6EsbTnvn/46z8+XuNteqprozTCb156OuJ89R2xB5 YUtw== X-Received: by 10.14.183.198 with SMTP id q46mr23294905eem.1.1361670256247; Sat, 23 Feb 2013 17:44:16 -0800 (PST) Received: from EhalepXPS (ppp079167079056.access.hol.gr. [79.167.79.56]) by mx.google.com with ESMTPS id t4sm11640869eel.0.2013.02.23.17.44.15 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 23 Feb 2013 17:44:15 -0800 (PST) From: "Haleplidis Evangelos" To: Date: Sun, 24 Feb 2013 03:44:13 +0200 Message-ID: <001a01ce1230$739aad50$5ad007f0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4SMCgNPJ6cgR0cS8yJXpGJmwTL2AAAB8Wg Content-Language: el Subject: [forces] FW: New Version Notification for draft-haleplidis-forces-packet-parallelization-02.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 01:44:18 -0000 Greetings to the list, We have just updated the parallelization draft. A small yet important addition to the document. Regards, Evangelos Halelpidis. > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Sunday, February 24, 2013 3:41 AM > To: ehalep@ece.upatras.gr > Cc: joel.halpern@ericsson.com > Subject: New Version Notification for draft-haleplidis-forces-packet- > parallelization-02.txt >=20 >=20 > A new version of I-D, draft-haleplidis-forces-packet-parallelization- > 02.txt > has been successfully submitted by Evangelos Haleplidis and posted to > the IETF repository. >=20 > Filename: draft-haleplidis-forces-packet-parallelization > Revision: 02 > Title: ForCES Packet Parallelization > Creation date: 2013-02-24 > Group: Individual Submission > Number of pages: 28 > URL: = http://www.ietf.org/internet-drafts/draft-haleplidis-forces-packet-parall= elization-02.txt > Status: = http://datatracker.ietf.org/doc/draft-haleplidis-forces-packet-paralleliz= ation > Htmlized: = http://tools.ietf.org/html/draft-haleplidis-forces-packet-parallelization= -02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-haleplidis-forces-packet-paralle= lization-02 >=20 > Abstract: > Forwarding and Control Element Separation (ForCES) defines an > architectural framework and associated protocols to standardize > information exchange between the control plane and the forwarding > plane in a ForCES Network Element (ForCES NE). RFC5812 has defined > the ForCES Model provides a formal way to represent the > capabilities, > state, and configuration of forwarding elements within the context > of > the ForCES protocol, so that control elements (CEs) can control the > FEs accordingly. More specifically, the model describes the = logical > functions that are present in an FE, what capabilities these > functions support, and how these functions are or can be > interconnected. >=20 > Many network devices support parallel packet processing. This > document describes how ForCES can model a network device's > parallelization datapath. >=20 >=20 >=20 >=20 > The IETF Secretariat From hadi@mojatatu.com Mon Feb 25 03:47:05 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E2921F92C4 for ; Mon, 25 Feb 2013 03:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.944 X-Spam-Level: X-Spam-Status: No, score=-102.944 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNymLeseBaQz for ; Mon, 25 Feb 2013 03:47:01 -0800 (PST) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7599D21F92C1 for ; Mon, 25 Feb 2013 03:47:01 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id n11so1620785vch.19 for ; Mon, 25 Feb 2013 03:47:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type:x-gm-message-state; bh=fINeHFZVbQoAjlQku9aRddfGdN16i4l9saGaIhsMmjs=; b=K0gyrKK0TjqO7AF06u3mJ8ntkFVDZzJOopg7fmRqH3V4RMKHmCqEM+i8V9vQm4t8Ea YpqygRXjLsOU6F5wd331CiypOas1q9alBlBOX32bMEalIeDj2of1cqueV2CZwtGGor/P LreHEtXs8dC7Sm4HjG60VmW+8JfD2GghgRObuU0BUdS4O1o50mwZo/x7z+dwXq2s4hDy tbLTShCN6FCPHnO0HW8bCiH+oQvHO78TOtQqsOEPuj+1JFnjhJBcPJCtfXg2W01OzUF2 BRz67jrELKNXgArEbNIlN1l7suMv55H4+bcNbROXTYwI2pM0qSvGZOSS8uoM6eBYtjmh zWHA== X-Received: by 10.52.96.7 with SMTP id do7mr8257495vdb.115.1361792820906; Mon, 25 Feb 2013 03:47:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.251.210 with HTTP; Mon, 25 Feb 2013 03:46:40 -0800 (PST) In-Reply-To: <20130225112953.16123.97093.idtracker@ietfa.amsl.com> References: <20130225112953.16123.97093.idtracker@ietfa.amsl.com> From: Jamal Hadi Salim Date: Mon, 25 Feb 2013 06:46:40 -0500 Message-ID: To: forces@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnbnGnb4+Kx2ebMz6KcOPP7Dx8hXWiFqZlcD55Xmwv5eOPq8l24M79MCK+dq0Pc4u0MYqM6 Subject: [forces] Fwd: New Version Notification for draft-joachimpillai-forces-interfelfb-01.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 11:47:05 -0000 ---------- Forwarded message ---------- From: Date: Mon, Feb 25, 2013 at 6:29 AM Subject: New Version Notification for draft-joachimpillai-forces-interfelfb-01.txt To: hadi@mojatatu.com Cc: damascene.joachimpillai@verizon.com A new version of I-D, draft-joachimpillai-forces-interfelfb-01.txt has been successfully submitted by Jamal Hadi Salim and posted to the IETF repository. Filename: draft-joachimpillai-forces-interfelfb Revision: 01 Title: ForCES Inter-FE LFB Creation date: 2013-02-25 Group: Individual Submission Number of pages: 18 URL: http://www.ietf.org/internet-drafts/draft-joachimpillai-forces-interfelfb-01.txt Status: http://datatracker.ietf.org/doc/draft-joachimpillai-forces-interfelfb Htmlized: http://tools.ietf.org/html/draft-joachimpillai-forces-interfelfb-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-joachimpillai-forces-interfelfb-01 Abstract: Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES Network Element (ForCES NE). RFC5812 has defined the ForCES Model provides a formal way to represent the capabilities, state, and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly. More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected. At the moment the ForCES charter restricts the LFB topology to be within an FE. This documents describes a non-intrusive way to extend the LFB topology across FEs. The IETF Secretariat From joel@stevecrocker.com Mon Feb 25 10:09:18 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9311F21E808C for ; Mon, 25 Feb 2013 10:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qW3mOe5U8zWM for ; Mon, 25 Feb 2013 10:09:17 -0800 (PST) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 19B9D21E808B for ; Mon, 25 Feb 2013 10:09:16 -0800 (PST) Received: from dummy.name; Mon, 25 Feb 2013 18:09:21 +0000 Message-ID: <512BA8BD.7090508@stevecrocker.com> Date: Mon, 25 Feb 2013 13:09:01 -0500 From: Joel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: forces@ietf.org References: <20130225112953.16123.97093.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [forces] Fwd: New Version Notification for draft-joachimpillai-forces-interfelfb-01.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 18:09:18 -0000 Thank you for submitting this draft. It seem to me that the encapsulation needs to include a bit more context information, probably in the form of a fixed header. this would seem to allow us to include a fragmentation mechanisms. Unfortunately, non of the other options liste in the draft seem viable. In conjunction with this, the fixed header could include information about what the target entity for the message is, in he case of virtualized FEs. Ts makes sense since conceptually the determination of which FE the packet is going to has to be done before the LFB in that FE gets a hold of it to process the TLVs. I do wonder if we could use a structure parallel to the existing ForCES protocol fixed header without too much distortion. the format has the relevant IDs and correlators we could use for fragmentation. Given the above, why do we need separate NESelector-TLVs and ExceptionID-TLVs? it seems that there are pieces of metadata, and could be carried easily and appropriately in the Metadata-TLV. Yours, Joel M. Halpern On 2/25/2013 6:46 AM, Jamal Hadi Salim wrote: > ---------- Forwarded message ---------- > From: > Date: Mon, Feb 25, 2013 at 6:29 AM > Subject: New Version Notification for > draft-joachimpillai-forces-interfelfb-01.txt > To: hadi@mojatatu.com > Cc: damascene.joachimpillai@verizon.com > > > > A new version of I-D, draft-joachimpillai-forces-interfelfb-01.txt > has been successfully submitted by Jamal Hadi Salim and posted to the > IETF repository. > > Filename: draft-joachimpillai-forces-interfelfb > Revision: 01 > Title: ForCES Inter-FE LFB > Creation date: 2013-02-25 > Group: Individual Submission > Number of pages: 18 > URL: > http://www.ietf.org/internet-drafts/draft-joachimpillai-forces-interfelfb-01.txt > Status: > http://datatracker.ietf.org/doc/draft-joachimpillai-forces-interfelfb > Htmlized: > http://tools.ietf.org/html/draft-joachimpillai-forces-interfelfb-01 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-joachimpillai-forces-interfelfb-01 > > Abstract: > Forwarding and Control Element Separation (ForCES) defines an > architectural framework and associated protocols to standardize > information exchange between the control plane and the forwarding > plane in a ForCES Network Element (ForCES NE). RFC5812 has defined > the ForCES Model provides a formal way to represent the capabilities, > state, and configuration of forwarding elements within the context of > the ForCES protocol, so that control elements (CEs) can control the > FEs accordingly. More specifically, the model describes the logical > functions that are present in an FE, what capabilities these > functions support, and how these functions are or can be > interconnected. > > At the moment the ForCES charter restricts the LFB topology to be > within an FE. This documents describes a non-intrusive way to extend > the LFB topology across FEs. > > > > > The IETF Secretariat > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From hadi@mojatatu.com Mon Feb 25 11:37:25 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB9E21F92F6 for ; Mon, 25 Feb 2013 11:37:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.947 X-Spam-Level: X-Spam-Status: No, score=-102.947 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tV7DWkSHpYz2 for ; Mon, 25 Feb 2013 11:37:19 -0800 (PST) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id 852E521E804C for ; Mon, 25 Feb 2013 11:37:19 -0800 (PST) Received: by mail-ve0-f182.google.com with SMTP id ox1so2555018veb.13 for ; Mon, 25 Feb 2013 11:37:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=yBemu2s50DYV3VdmpN5gYYoaBsPnCsq3qh2/JwiJ1Gs=; b=h2zGfxMtYAkWiVfy/1HcF0sYtjFMAMJty7ukv3GRlJ6IJnyAZbuL2e8rV/FpFQXI3W M6b/OBimR7JuHUMEM3810ntIeEy7z5fFF5RjpQg13ZDZ9HYpVVl7ICK4HzGp3RzoNO2f ds8l8JXhMhWDj6cmjTvrhTTIn1NXcuYLiQuJ+9l/YCFYUWXvubyKyMBYnDF/Qvv3uBCt MAnfhhfEhlAirBf8uF2UwKnzd5zv9d741HtybpGh7Choa8EXypjQLmbbX1vz9vODJLZr sSkia5e9DPluaWs/tgCzV0yvtlGZlV5ygbv6+BoXymPAEO0xaAMQ4NLJaIBJQaFwNbDk lpfA== X-Received: by 10.220.239.71 with SMTP id kv7mr10341757vcb.46.1361821033962; Mon, 25 Feb 2013 11:37:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.251.210 with HTTP; Mon, 25 Feb 2013 11:36:53 -0800 (PST) In-Reply-To: <512BA8BD.7090508@stevecrocker.com> References: <20130225112953.16123.97093.idtracker@ietfa.amsl.com> <512BA8BD.7090508@stevecrocker.com> From: Jamal Hadi Salim Date: Mon, 25 Feb 2013 14:36:53 -0500 Message-ID: To: Joel Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlNECNe1z5/KnMDsq8WILyCJRmuYBE0RDPJqWH+7ezACrKh32Xp4/MNmmd90kl3UIFQvDI8 Cc: forces@ietf.org Subject: Re: [forces] Fwd: New Version Notification for draft-joachimpillai-forces-interfelfb-01.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 19:37:25 -0000 On Mon, Feb 25, 2013 at 1:09 PM, Joel wrote: > Thank you for submitting this draft. > > It seem to me that the encapsulation needs to include a bit more context > information, probably in the form of a fixed header. > this would seem to > allow us to include a fragmentation mechanisms. Unfortunately, non of the > other options liste in the draft seem viable. What is your thought on carrying fragmentation details as an optional TLV? Unless fragmenting would be considered a norm and non-fragement would be considered an exception. > In conjunction with this, the fixed header could include information about > what the target entity for the message is, in he case of virtualized FEs. Again that would be sensible if the normal path is we always carry that information. The assumption is some people may not be interested. > Ts makes sense since conceptually the determination of which FE the packet > is going to has to be done before the LFB in that FE gets a hold of it to > process the TLVs. > aha, makes a lot of sense. > I do wonder if we could use a structure parallel to the existing ForCES > protocol fixed header without too much distortion. the format has the > relevant IDs and correlators we could use for fragmentation. Our thought process was to try and not use bits that most people dont want to use. But you make a good arguement for a small common header (in the case of virtualized FEs). > Given the above, why do we need separate NESelector-TLVs and > ExceptionID-TLVs? it seems that there are pieces of metadata, and could be > carried easily and appropriately in the Metadata-TLV. Maybe not the NESeletor, but i dont think you can escape the ExceptionID TLV. Exception IDs live in a different namespace from metadata (and a good chunk are IANA controlled just like metadata). cheers, jamal From joel@stevecrocker.com Mon Feb 25 11:45:40 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD33721E80BC for ; Mon, 25 Feb 2013 11:45:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3djI2ca2ym1q for ; Mon, 25 Feb 2013 11:45:40 -0800 (PST) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 91ACF21E80B1 for ; Mon, 25 Feb 2013 11:45:39 -0800 (PST) Received: from dummy.name; Mon, 25 Feb 2013 19:45:40 +0000 Message-ID: <512BBF50.1020503@stevecrocker.com> Date: Mon, 25 Feb 2013 14:45:20 -0500 From: Joel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Jamal Hadi Salim References: <20130225112953.16123.97093.idtracker@ietfa.amsl.com> <512BA8BD.7090508@stevecrocker.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces@ietf.org Subject: Re: [forces] Fwd: New Version Notification for draft-joachimpillai-forces-interfelfb-01.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 19:45:40 -0000 Putting the fragment header inside the TLV construct means that we then have to describe how the TLVs are reassembled around the fragment header. I fear that fragmentation will be a common case, since there are many full MTU size packets, and we are heading information to EVER packet. So just put it in the fixed header. With regard to the exception IDs, I realized that I am having trouble understanding what that TLV is for. After all, the exception IDs are form the information of the CE. Yours Joel On 2/25/2013 2:36 PM, Jamal Hadi Salim wrote: > On Mon, Feb 25, 2013 at 1:09 PM, Joel wrote: >> Thank you for submitting this draft. >> >> It seem to me that the encapsulation needs to include a bit more context >> information, probably in the form of a fixed header. >> this would seem to >> allow us to include a fragmentation mechanisms. Unfortunately, non of the >> other options liste in the draft seem viable. > > What is your thought on carrying fragmentation details as an optional > TLV? Unless fragmenting would be considered a norm and non-fragement > would be considered an exception. > >> In conjunction with this, the fixed header could include information about >> what the target entity for the message is, in he case of virtualized FEs. > > Again that would be sensible if the normal path is we always carry > that information. > The assumption is some people may not be interested. > >> Ts makes sense since conceptually the determination of which FE the packet >> is going to has to be done before the LFB in that FE gets a hold of it to >> process the TLVs. >> > > aha, makes a lot of sense. > >> I do wonder if we could use a structure parallel to the existing ForCES >> protocol fixed header without too much distortion. the format has the >> relevant IDs and correlators we could use for fragmentation. > > Our thought process was to try and not use bits that most people dont > want to use. But you make a good arguement for a small common header > (in the case of virtualized FEs). > >> Given the above, why do we need separate NESelector-TLVs and >> ExceptionID-TLVs? it seems that there are pieces of metadata, and could be >> carried easily and appropriately in the Metadata-TLV. > > Maybe not the NESeletor, but i dont think you can escape the ExceptionID TLV. > Exception IDs live in a different namespace from metadata (and a good chunk > are IANA controlled just like metadata). > > cheers, > jamal > From ehalep@gmail.com Mon Feb 25 14:54:48 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E892C21E8136 for ; Mon, 25 Feb 2013 14:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cj7oiDz9ywmK for ; Mon, 25 Feb 2013 14:54:48 -0800 (PST) Received: from mail-bk0-f52.google.com (mail-bk0-f52.google.com [209.85.214.52]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC1821E8135 for ; Mon, 25 Feb 2013 14:54:48 -0800 (PST) Received: by mail-bk0-f52.google.com with SMTP id jk13so1549203bkc.11 for ; Mon, 25 Feb 2013 14:54:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=pzEpSubI5PUyrCyUHUTu4WK4ib1ahvQrGGvaTruR57o=; b=OT1qzMYLlBdzU5+UK0lEhibJzCitQGels/J25fZCzm6YdxkaLPgVHUFiBFKgN/vvzD MGr+RoFTPfj3vxQzYCgUGGJ/UlFBufSMwMPjK1XGa0nMI6CQ9AcLE1sWM43Vebzj/cYi D2lQfBXY2MjIbE9ocpqD3cLgH95L0ASbdJmo2eW84OPxGxaUAGXoULaZ4WMzFTGZv9Ov k9tFdwMHfUXglRyer5bHmH4Uxe9sJk7zWAvBI6/ye937WhGPzm0hkNerP6JMrIdx+Xlv UYt5JkXcQyecSkvQR2MRRrW2vfiECKjxWiGsg+2k3G2TMEJ7NNJZyQOAzVjrS8bvMTdE EQUw== X-Received: by 10.204.154.199 with SMTP id p7mr5623163bkw.98.1361832887218; Mon, 25 Feb 2013 14:54:47 -0800 (PST) Received: from EhalepXPS (ppp079166071226.access.hol.gr. [79.166.71.226]) by mx.google.com with ESMTPS id o2sm4093473bkv.3.2013.02.25.14.54.46 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 25 Feb 2013 14:54:46 -0800 (PST) From: "Haleplidis Evangelos" To: Date: Tue, 26 Feb 2013 00:54:44 +0200 Message-ID: <00f801ce13ab$1bb1b710$53152530$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4TqkfINfzJ5nfNQLCFayNBKpg/kwAAAUhA Content-Language: el Subject: [forces] FW: New Version Notification for draft-haleplidis-forces-model-extension-02.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 22:54:49 -0000 Greetings to the list, We recently made an update to the model extension draft. We have added three new items for further discussion on the model = extension. Regards, Evangelos Haleplidis. > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, February 26, 2013 12:47 AM > To: ehalep@ece.upatras.gr > Subject: New Version Notification for draft-haleplidis-forces-model- > extension-02.txt >=20 >=20 > A new version of I-D, draft-haleplidis-forces-model-extension-02.txt > has been successfully submitted by Evangelos Haleplidis and posted to > the IETF repository. >=20 > Filename: draft-haleplidis-forces-model-extension > Revision: 02 > Title: ForCES Model Extension > Creation date: 2013-02-25 > Group: Individual Submission > Number of pages: 32 > URL: = http://www.ietf.org/internet-drafts/draft-haleplidis-forces-model-extensi= on-02.txt > Status: = http://datatracker.ietf.org/doc/draft-haleplidis-forces-model-extension > Htmlized: = http://tools.ietf.org/html/draft-haleplidis-forces-model-extension-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-haleplidis-forces-model-extensio= n-02 >=20 > Abstract: > Forwarding and Control Element Separation (ForCES) defines an > architectural framework and associated protocols to standardize > information exchange between the control plane and the forwarding > plane in a ForCES Network Element (ForCES NE). RFC5812 has defined > the ForCES Model provides a formal way to represent the > capabilities, > state, and configuration of forwarding elements within the context > of > the ForCES protocol, so that control elements (CEs) can control the > FEs accordingly. More specifically, the model describes the = logical > functions that are present in an FE, what capabilities these > functions support, and how these functions are or can be > interconnected. >=20 > RFC5812 has been around for two years and experience in its use has > shown room for extensions without a need to alter the protocol = while > retaining backward compatibility with older xml libraries. >=20 >=20 >=20 >=20 > The IETF Secretariat From hadi@mojatatu.com Tue Feb 26 05:25:26 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B4821F88FC for ; Tue, 26 Feb 2013 05:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.95 X-Spam-Level: X-Spam-Status: No, score=-102.95 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4DGYgGg6xxX for ; Tue, 26 Feb 2013 05:25:24 -0800 (PST) Received: from mail-ve0-f175.google.com (mail-ve0-f175.google.com [209.85.128.175]) by ietfa.amsl.com (Postfix) with ESMTP id CE68A21F869F for ; Tue, 26 Feb 2013 05:25:23 -0800 (PST) Received: by mail-ve0-f175.google.com with SMTP id cy12so3367445veb.20 for ; Tue, 26 Feb 2013 05:25:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=aWUCTRWQmxgyrLYiTQrAIGUrEeCleJibwwSBmY/lDsw=; b=CUWTqsHsnCUifLyT1BqIA5zqVupIGrlnMZh8M1MSq3dn0P7HNtPr9ARpAIDNQk6O3L 9oGtzIuqxh+FtEzQFr7Eki152Z2E3A95XBVedzh8KQU1h+ZpSUlkw0hK3QNc74fzkU6n PF1uyU7gZGCLQsj0Ds63qLfiXEC5RxnP3TmJSJBdKaMEZnx2FV5x1IoUC/gjrUY6mpnT 2fcbU8KnWfcPm7ami0VLzZjMcFnTmtSU/cVmiCTQW8PCaLNQWz0gXVAntMnEZoBIO3J8 RdKFMe6POnk4nT8RG3IKHEiNwvAoG4IvLbEi3RdiqWkp/3b9gpAugHGEbaNO68uqshhL Oi/w== X-Received: by 10.52.91.212 with SMTP id cg20mr10337869vdb.63.1361885123269; Tue, 26 Feb 2013 05:25:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.251.210 with HTTP; Tue, 26 Feb 2013 05:25:03 -0800 (PST) In-Reply-To: <512BBF50.1020503@stevecrocker.com> References: <20130225112953.16123.97093.idtracker@ietfa.amsl.com> <512BA8BD.7090508@stevecrocker.com> <512BBF50.1020503@stevecrocker.com> From: Jamal Hadi Salim Date: Tue, 26 Feb 2013 08:25:03 -0500 Message-ID: To: Joel Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnlyoawDSx0RFQGjWKCfMibJ0IyExEffHesmXRSckkMOZZ/RdSm4KdoajHdyOfx5wyhD8tF Cc: forces@ietf.org Subject: Re: [forces] Fwd: New Version Notification for draft-joachimpillai-forces-interfelfb-01.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 13:25:26 -0000 On Mon, Feb 25, 2013 at 2:45 PM, Joel wrote: > Putting the fragment header inside the TLV construct means that we then have > to describe how the TLVs are reassembled around the fragment header. I fear > that fragmentation will be a common case, since there are many full MTU size > packets, and we are heading information to EVER packet. So just put it in > the fixed header. I remember now a good reason we wanted fragmentation as optional: Given we'd like to allow this to work over other transports it is possible (for example over UDP/IP) that the underlying transport can provide the fragmentation service. > > With regard to the exception IDs, I realized that I am having trouble > understanding what that TLV is for. After all, the exception IDs are form > the information of the CE. If i got what you are saying: We _do_ need a new Exception top level, correct? I would say given the name space separation from metadata (per LFB lib) we need it regardless of whether it is used here. cheers, jamal From hadi@mojatatu.com Tue Feb 26 05:29:59 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6FAC21F89B3 for ; Tue, 26 Feb 2013 05:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.952 X-Spam-Level: X-Spam-Status: No, score=-102.952 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NS2adnfUr32I for ; Tue, 26 Feb 2013 05:29:59 -0800 (PST) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by ietfa.amsl.com (Postfix) with ESMTP id 478DE21F8942 for ; Tue, 26 Feb 2013 05:29:59 -0800 (PST) Received: by mail-ve0-f171.google.com with SMTP id b10so3451388vea.30 for ; Tue, 26 Feb 2013 05:29:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=o4D6zGCfIYhawtkGOR6nGX3G0OVEsoJiRT5ReTDTzRA=; b=PQH8NoflT0PHH0B2zj8RtuH/oiEq4HvHDUQuNHhkIHhwNJ7k2G5lAWvvB3GLFznOZc u3i+8tbYgTvcLa5VNF3cNXjbZLNbuPZG1k2VwkLWwgqgo3A6BLgVdDC3hDgV0edHa4wx Y/r3qyMvP8Ut3b16nt5gdgixEsSyjriwOsJGJw+u05OR+SbGbKTy5sLbuNsXhDDsJO6O tFIw1Q4xMV2vwpOsBnFW2XdtMKEp5qiGaMkm0/1CMTbfdqjMnEfpBVct6C/E1WnGnJju M0AMPMyoej1o6t34wbzVQiyOTo+wLThnuyj62PKkP11Hyo9bW9M3Ej4h+evf7ynb/cHD IbAw== X-Received: by 10.58.155.99 with SMTP id vv3mr11649047veb.50.1361885398742; Tue, 26 Feb 2013 05:29:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.251.210 with HTTP; Tue, 26 Feb 2013 05:29:38 -0800 (PST) In-Reply-To: References: <20130225112953.16123.97093.idtracker@ietfa.amsl.com> <512BA8BD.7090508@stevecrocker.com> From: Jamal Hadi Salim Date: Tue, 26 Feb 2013 08:29:38 -0500 Message-ID: To: Joel Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkILHgIf0p+t6ua/GqlG6K7345TsmKrFKSYO12fM+qrJj1gvGc0HasJckbxIM1cXBPfHdwh Cc: forces@ietf.org Subject: Re: [forces] Fwd: New Version Notification for draft-joachimpillai-forces-interfelfb-01.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 13:29:59 -0000 On Mon, Feb 25, 2013 at 2:36 PM, Jamal Hadi Salim wrote: > On Mon, Feb 25, 2013 at 1:09 PM, Joel wrote: >> I do wonder if we could use a structure parallel to the existing ForCES >> protocol fixed header without too much distortion. the format has the >> relevant IDs and correlators we could use for fragmentation. > > Our thought process was to try and not use bits that most people dont > want to use. But you make a good arguement for a small common header > (in the case of virtualized FEs). Joel, if the forces common Header was to be used, this would be a unidirectional message (like redirect to/from CE). Leaving the fragmentation issue aside, would you see a new message type? Can we abuse the correlator to store the NE ID (assuming the message is unidirectional, that space is wasted otherwise). cheers, jamal >> Given the above, why do we need separate NESelector-TLVs and >> ExceptionID-TLVs? it seems that there are pieces of metadata, and could be >> carried easily and appropriately in the Metadata-TLV. > > Maybe not the NESeletor, but i dont think you can escape the ExceptionID TLV. > Exception IDs live in a different namespace from metadata (and a good chunk > are IANA controlled just like metadata). > > cheers, > jamal From joel@stevecrocker.com Tue Feb 26 05:59:33 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B652C21F86C1 for ; Tue, 26 Feb 2013 05:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.169 X-Spam-Level: X-Spam-Status: No, score=-1.169 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNjStAFh9RuV for ; Tue, 26 Feb 2013 05:59:33 -0800 (PST) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 489E721F86BA for ; Tue, 26 Feb 2013 05:59:33 -0800 (PST) Received: from dummy.name; Tue, 26 Feb 2013 13:59:35 +0000 Message-ID: <512CBFA3.7080301@stevecrocker.com> Date: Tue, 26 Feb 2013 08:58:59 -0500 From: Joel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Jamal Hadi Salim References: <20130225112953.16123.97093.idtracker@ietfa.amsl.com> <512BA8BD.7090508@stevecrocker.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces@ietf.org Subject: Re: [forces] Fwd: New Version Notification for draft-joachimpillai-forces-interfelfb-01.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 13:59:33 -0000 My thought was that rather than send an NE ID we could reasonably expect that any physical device supporting multiple NEs could ensure that the FEs had distinct IDs, and could just use the FEID which is already in the fixed header. yours, Joel On 2/26/2013 8:29 AM, Jamal Hadi Salim wrote: > On Mon, Feb 25, 2013 at 2:36 PM, Jamal Hadi Salim wrote: >> On Mon, Feb 25, 2013 at 1:09 PM, Joel wrote: > >>> I do wonder if we could use a structure parallel to the existing ForCES >>> protocol fixed header without too much distortion. the format has the >>> relevant IDs and correlators we could use for fragmentation. >> >> Our thought process was to try and not use bits that most people dont >> want to use. But you make a good arguement for a small common header >> (in the case of virtualized FEs). > > Joel, if the forces common Header was to be used, this would be a unidirectional > message (like redirect to/from CE). Leaving the fragmentation issue aside, > would you see a new message type? Can we abuse the correlator to store > the NE ID (assuming the message is unidirectional, that space is wasted > otherwise). > > cheers, > jamal > > > >>> Given the above, why do we need separate NESelector-TLVs and >>> ExceptionID-TLVs? it seems that there are pieces of metadata, and could be >>> carried easily and appropriately in the Metadata-TLV. >> >> Maybe not the NESeletor, but i dont think you can escape the ExceptionID TLV. >> Exception IDs live in a different namespace from metadata (and a good chunk >> are IANA controlled just like metadata). >> >> cheers, >> jamal From joel@stevecrocker.com Tue Feb 26 06:02:47 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF1CD21F86CE for ; Tue, 26 Feb 2013 06:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.212 X-Spam-Level: X-Spam-Status: No, score=-1.212 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yUAFuFd9OuZ for ; Tue, 26 Feb 2013 06:02:43 -0800 (PST) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id E17F021F86A8 for ; Tue, 26 Feb 2013 06:02:42 -0800 (PST) Received: from dummy.name; Tue, 26 Feb 2013 14:02:47 +0000 Message-ID: <512CC05B.7000605@stevecrocker.com> Date: Tue, 26 Feb 2013 09:02:03 -0500 From: Joel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Jamal Hadi Salim References: <20130225112953.16123.97093.idtracker@ietfa.amsl.com> <512BA8BD.7090508@stevecrocker.com> <512BBF50.1020503@stevecrocker.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces@ietf.org Subject: Re: [forces] Fwd: New Version Notification for draft-joachimpillai-forces-interfelfb-01.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 14:02:48 -0000 Why would we use a transport protocol between two adjacent FEs? I will grant that if we are wrapping it up in IP, we could use the IP fragmentation. But that seems an awful lot of overhead. Between two devices which have layer 2 connectivity to each other. A UDP header does not see to do us any good. And I do not want a flow controlled or retransmitting transport within the IP dataplane. Your, Joel On 2/26/2013 8:25 AM, Jamal Hadi Salim wrote: > On Mon, Feb 25, 2013 at 2:45 PM, Joel wrote: >> Putting the fragment header inside the TLV construct means that we then have >> to describe how the TLVs are reassembled around the fragment header. I fear >> that fragmentation will be a common case, since there are many full MTU size >> packets, and we are heading information to EVER packet. So just put it in >> the fixed header. > > I remember now a good reason we wanted fragmentation as optional: > Given we'd like to allow this to work over other transports it is possible > (for example over UDP/IP) that the underlying transport can provide > the fragmentation service. > >> >> With regard to the exception IDs, I realized that I am having trouble >> understanding what that TLV is for. After all, the exception IDs are form >> the information of the CE. > > If i got what you are saying: We _do_ need a new Exception top level, correct? > I would say given the name space separation from metadata (per LFB lib) we > need it regardless of whether it is used here. > > cheers, > jamal > From hadi@mojatatu.com Tue Feb 26 14:00:59 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A59121F88BF for ; Tue, 26 Feb 2013 14:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.954 X-Spam-Level: X-Spam-Status: No, score=-102.954 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KB7iOVK0gbaB for ; Tue, 26 Feb 2013 14:00:58 -0800 (PST) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id 79A0421F889C for ; Tue, 26 Feb 2013 14:00:58 -0800 (PST) Received: by mail-ve0-f182.google.com with SMTP id ox1so4437979veb.27 for ; Tue, 26 Feb 2013 14:00:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=nGSlawGd8nYGFSJe/1k2E4g877DCUwoknQEtsS1cP9w=; b=SWh3cR1B/hK1Ied89YLsw37EQjOiVr6sk04KRLbLLishXhKoBFg0Nviyps1LnlJtoO q2mM6rN1EzgZlYBRXhPEagqq49Ys9uZz2k5Sa3a0gN7bh/hUUBuLv9mQY+6d5sejSTsR OWgiQS21cuEhbHgHX2bgCvMN1BaksQnrywpU/TJRov2EJ51a2MYEnbI3NySlRO5FzlfY k2zfBCXy7zvWsqj67o1XBrHBXUtn1Jf7sr8jCBc+fp5Mqsr1qsvAjLY9gr8MoPJdQ1EZ K+ySPxWdhjhmyDf6Je+3SpwK7uzV5VrRLkLS/SczqcKsOeJVW30ou1Mutd2heD223Iiu TIMg== X-Received: by 10.52.175.66 with SMTP id by2mr11303846vdc.53.1361916057901; Tue, 26 Feb 2013 14:00:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.251.210 with HTTP; Tue, 26 Feb 2013 14:00:37 -0800 (PST) In-Reply-To: <512CBFA3.7080301@stevecrocker.com> References: <20130225112953.16123.97093.idtracker@ietfa.amsl.com> <512BA8BD.7090508@stevecrocker.com> <512CBFA3.7080301@stevecrocker.com> From: Jamal Hadi Salim Date: Tue, 26 Feb 2013 17:00:37 -0500 Message-ID: To: Joel Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmNQd+qVN1DijiUWwj2tSwLXqXxQpuVcKpnS81baVTmOyXaEvNb+iqp2T1kUu76B+cdYykv Cc: forces@ietf.org Subject: Re: [forces] Fwd: New Version Notification for draft-joachimpillai-forces-interfelfb-01.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 22:00:59 -0000 On Tue, Feb 26, 2013 at 8:58 AM, Joel wrote: > My thought was that rather than send an NE ID we could reasonably expect > that any physical device supporting multiple NEs could ensure that the FEs > had distinct IDs, and could just use the FEID which is already in the fixed > header. >From what i have seen around virtualization, the NEID is an important piece because the FEIDs may infact overlap across tenants. So we need that info somewhere. > Why would we use a transport protocol between two adjacent FEs? > I will grant that if we are wrapping it up in IP, we could use the IP > fragmentation. But that seems an awful lot of overhead. Between two > devices which have layer 2 connectivity to each other. > A UDP header does not see to do us any good. > And I do not want a flow controlled or retransmitting transport within the > IP dataplane. It is feasible that a service chain may go across networks (in particular with virtualization involved) and therefore one has to run over IP. We wanted to leave that option open. Agreed, if you were to go that path, you dont want some reliable transport that will retransmit. Not sure if you want something that handles congestion control (UDP would be out). But the general idea was we did not want to impose connectivity/transport to be used. Our goal is just to get the information across that allows us to continue the service graph. cheers, jamal From joel@stevecrocker.com Tue Feb 26 14:11:02 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EE021F8858 for ; Tue, 26 Feb 2013 14:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.244 X-Spam-Level: X-Spam-Status: No, score=-1.244 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qb3sA7rQOQ2K for ; Tue, 26 Feb 2013 14:11:01 -0800 (PST) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id A438521F87D3 for ; Tue, 26 Feb 2013 14:10:54 -0800 (PST) Received: from dummy.name; Tue, 26 Feb 2013 22:11:00 +0000 Message-ID: <512D32DA.7060302@stevecrocker.com> Date: Tue, 26 Feb 2013 17:10:34 -0500 From: Joel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Jamal Hadi Salim References: <20130225112953.16123.97093.idtracker@ietfa.amsl.com> <512BA8BD.7090508@stevecrocker.com> <512CBFA3.7080301@stevecrocker.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces@ietf.org Subject: Re: [forces] Fwd: New Version Notification for draft-joachimpillai-forces-interfelfb-01.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 22:11:02 -0000 can you elaborate on the case of overlapping FEIDs? I can think of two cases I know of: 1) Each FE is a complete virtual machine. In that case, each one has its own MAC address. 2) The individual FEs are created through the ForCES manipulation of a master FE. In that case, the master can assign the FE-IDs so that they don't overlap. I presume there are other cases I have missed? Yours, Joel On 2/26/2013 5:00 PM, Jamal Hadi Salim wrote: > On Tue, Feb 26, 2013 at 8:58 AM, Joel wrote: >> My thought was that rather than send an NE ID we could reasonably expect >> that any physical device supporting multiple NEs could ensure that the FEs >> had distinct IDs, and could just use the FEID which is already in the fixed >> header. > > From what i have seen around virtualization, the NEID is an important piece > because the FEIDs may infact overlap across tenants. So we need that info > somewhere. > >> Why would we use a transport protocol between two adjacent FEs? >> I will grant that if we are wrapping it up in IP, we could use the IP >> fragmentation. But that seems an awful lot of overhead. Between two >> devices which have layer 2 connectivity to each other. >> A UDP header does not see to do us any good. >> And I do not want a flow controlled or retransmitting transport within the >> IP dataplane. > > It is feasible that a service chain may go across networks (in particular > with virtualization involved) and therefore one has to run over IP. > We wanted to leave that option open. Agreed, if you were to go that path, > you dont want some reliable transport that will retransmit. Not sure if you > want something that handles congestion control (UDP would be out). > But the general idea was we did not want to impose connectivity/transport > to be used. Our goal is just to get the information across that allows > us to continue the service graph. > > cheers, > jamal > From hadi@mojatatu.com Tue Feb 26 15:13:44 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE7C21F8598 for ; Tue, 26 Feb 2013 15:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.956 X-Spam-Level: X-Spam-Status: No, score=-102.956 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BO9snpLbAhU7 for ; Tue, 26 Feb 2013 15:13:44 -0800 (PST) Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) by ietfa.amsl.com (Postfix) with ESMTP id 4228E21F8596 for ; Tue, 26 Feb 2013 15:13:44 -0800 (PST) Received: by mail-ve0-f180.google.com with SMTP id jx10so4510477veb.11 for ; Tue, 26 Feb 2013 15:13:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=VPnUNv0NfP3ePQCAP7D32NcFz0thZZ60XoOfNBav6gg=; b=XRT2cUecydCZGS6tgfM0Y7AqG9g3Aye1lVuujJCCpTCl/S7fn6/Uj4BN4Pc0V6XdPp R9nM0r6Cc/bDcgAgudxeyPYnm7veG2VKtZw45anbovBnv3cvsrQ4K8wooGgka60nbEUz 1tPDSUziVquWgSRPKgB8v9c0QQj5VeHkM7FVOQjI8bZrtQ8+e9oKMj4XBodeFmI8MRhr 06VmrqxFkNFs4XrTeJSfwF71Vip7OnSC5DPmvUQGqyWC4wUgo1LGD8BSlzWJ00djP1ES 0tq4zoarPFZ2xl0mFJ7umYoHWtbQkTb9+SQ7FsGKX+tpuq+eqCyEL46ATdWp5t4FAKaY 0stA== X-Received: by 10.52.29.209 with SMTP id m17mr1639vdh.111.1361920423698; Tue, 26 Feb 2013 15:13:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.251.210 with HTTP; Tue, 26 Feb 2013 15:13:23 -0800 (PST) In-Reply-To: <512D32DA.7060302@stevecrocker.com> References: <20130225112953.16123.97093.idtracker@ietfa.amsl.com> <512BA8BD.7090508@stevecrocker.com> <512CBFA3.7080301@stevecrocker.com> <512D32DA.7060302@stevecrocker.com> From: Jamal Hadi Salim Date: Tue, 26 Feb 2013 18:13:23 -0500 Message-ID: To: Joel Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlJ9iyZkruMX2sRHAIfcBGuqKIdr9pT3Jowqokfs/5ezRFYuvxnSZjaCO0GwbzTchW/4KMZ Cc: forces@ietf.org Subject: Re: [forces] Fwd: New Version Notification for draft-joachimpillai-forces-interfelfb-01.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 23:13:44 -0000 On Tue, Feb 26, 2013 at 5:10 PM, Joel wrote: > can you elaborate on the case of overlapping FEIDs? > I can think of two cases I know of: > 1) Each FE is a complete virtual machine. In that case, each one has its > own MAC address. > 2) The individual FEs are created through the ForCES manipulation of a > master FE. In that case, the master can assign the FE-IDs so that they > don't overlap. > > I presume there are other cases I have missed? > That would cover what i am interested in: The only difference is when you have multiple tenants. All possibly running on the same location. In that case even the MAC address is game to be overlapping. VLANs (one per tenant) could be used to restrict tenant broadcast domains if you are running over 802.1q to resolve that challenge; other proposals have been made in the gazillion tunneling proposals out there like VXLAN and what the nvo3 folks are doing; some network/NEID is needed to map the proposal here to any of these approaches should there be need to - but we are striving for simplicity as well and not depend on their presence (per the fixed header discussion). cheers, jamal From joel@stevecrocker.com Tue Feb 26 16:18:22 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D2721F85C2 for ; Tue, 26 Feb 2013 16:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.269 X-Spam-Level: X-Spam-Status: No, score=-1.269 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGPnxBHgbWMS for ; Tue, 26 Feb 2013 16:18:21 -0800 (PST) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBDF21F85B8 for ; Tue, 26 Feb 2013 16:18:21 -0800 (PST) Received: from dummy.name; Wed, 27 Feb 2013 00:18:28 +0000 Message-ID: <512D50BA.9090501@stevecrocker.com> Date: Tue, 26 Feb 2013 19:18:02 -0500 From: Joel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Jamal Hadi Salim References: <20130225112953.16123.97093.idtracker@ietfa.amsl.com> <512BA8BD.7090508@stevecrocker.com> <512CBFA3.7080301@stevecrocker.com> <512D32DA.7060302@stevecrocker.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces@ietf.org Subject: Re: [forces] Fwd: New Version Notification for draft-joachimpillai-forces-interfelfb-01.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 00:18:22 -0000 If you have multiple tenants, you have to have other means of tenant isolation. Generally, MAC addresses are not duplicated across tenants in the same physical device. Also, there is usually also enforced VLAN segregation. It would seem that combination would cover what ou wanted to accomplish with the NEID. Yours, Joel On 2/26/2013 6:13 PM, Jamal Hadi Salim wrote: > On Tue, Feb 26, 2013 at 5:10 PM, Joel wrote: >> can you elaborate on the case of overlapping FEIDs? >> I can think of two cases I know of: >> 1) Each FE is a complete virtual machine. In that case, each one has its >> own MAC address. >> 2) The individual FEs are created through the ForCES manipulation of a >> master FE. In that case, the master can assign the FE-IDs so that they >> don't overlap. >> >> I presume there are other cases I have missed? >> > > That would cover what i am interested in: > The only difference is when you have multiple tenants. All possibly running > on the same location. In that case even the MAC address is game to be > overlapping. > VLANs (one per tenant) could be used to restrict tenant broadcast domains if > you are running over 802.1q to resolve that challenge; other proposals > have been > made in the gazillion tunneling proposals out there like VXLAN and what the > nvo3 folks are doing; some network/NEID is needed to map the proposal here > to any of these approaches should there be need to - but we are striving for > simplicity as well and not depend on their presence (per the fixed header > discussion). > > cheers, > jamal > From hadi@mojatatu.com Wed Feb 27 04:32:26 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C834721F859D for ; Wed, 27 Feb 2013 04:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHrq6KYaDp6s for ; Wed, 27 Feb 2013 04:32:26 -0800 (PST) Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3C80121F8596 for ; Wed, 27 Feb 2013 04:32:26 -0800 (PST) Received: by mail-vb0-f47.google.com with SMTP id e21so41252vbm.34 for ; Wed, 27 Feb 2013 04:32:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=MoZdaFmZZLukOqYgjIg65tNgdrgW2PFda/ahDa8sWd0=; b=aoDkaeiVuNBAH7l9kZn/FNx1MaNcC9pKK762vnsnPjkZzaMF3gPpQfzMzHa2D9ml86 3CCTqZ5NSgxFOGnzxI2+CoJYehmwgIPGfe+9m3gVhIpbfJn8ET7zBfmN1HKhRSAUokPA LCBSct1o/oTqgrt3p9ZFkTGo+lo8q435j2wendAbHnXn8yK0TWNs0JfyZWIl3r5xDsIN Ukx/JYmUqPbLQcPDjol8Ym4Q4T2RlGuf94Z0eBnAkqZLgLeAOJZWYT1fq1hffwDs3umY z/o2zjyC3S7SO4Ypd03dnUqlsso42+IMFnc+Yw+WFITQcdu2aPaxH7k8ieLH+0GjeOft ZHIw== X-Received: by 10.58.155.99 with SMTP id vv3mr784559veb.50.1361968345613; Wed, 27 Feb 2013 04:32:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.251.210 with HTTP; Wed, 27 Feb 2013 04:32:04 -0800 (PST) In-Reply-To: <512D50BA.9090501@stevecrocker.com> References: <20130225112953.16123.97093.idtracker@ietfa.amsl.com> <512BA8BD.7090508@stevecrocker.com> <512CBFA3.7080301@stevecrocker.com> <512D32DA.7060302@stevecrocker.com> <512D50BA.9090501@stevecrocker.com> From: Jamal Hadi Salim Date: Wed, 27 Feb 2013 07:32:04 -0500 Message-ID: To: Joel Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmmT8ylsqYYvGwaQHWjYCbFmNue8oT8frE1fYtBq/g/IkXhtyD2lw89zpGED8wUqpcS73ym Cc: forces@ietf.org Subject: Re: [forces] Fwd: New Version Notification for draft-joachimpillai-forces-interfelfb-01.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 12:32:26 -0000 On Tue, Feb 26, 2013 at 7:18 PM, Joel wrote: > If you have multiple tenants, you have to have other means of tenant > isolation. Generally, MAC addresses are not duplicated across tenants in > the same physical device. Also, there is usually also enforced VLAN > segregation. We probably dont differ in that thought. We are saying in presence of such infrastructure it could be made use of. i.e someone would take the NEID and map it to a vlanid and we are set. Or if they want to use the VXLAN, they could etc. This is why we were making the NESelector optional. But if they want to use none of the above, they should be able to set the NEID somewhere. If we are going to use a fixed header - then somewhere in there would be an optional NEID. cheers, jamal > It would seem that combination would cover what ou wanted to accomplish with > the NEID. > > Yours, > Joel > > > On 2/26/2013 6:13 PM, Jamal Hadi Salim wrote: >> >> On Tue, Feb 26, 2013 at 5:10 PM, Joel wrote: >>> >>> can you elaborate on the case of overlapping FEIDs? >>> I can think of two cases I know of: >>> 1) Each FE is a complete virtual machine. In that case, each one has its >>> own MAC address. >>> 2) The individual FEs are created through the ForCES manipulation of a >>> master FE. In that case, the master can assign the FE-IDs so that they >>> don't overlap. >>> >>> I presume there are other cases I have missed? >>> >> >> That would cover what i am interested in: >> The only difference is when you have multiple tenants. All possibly >> running >> on the same location. In that case even the MAC address is game to be >> overlapping. >> VLANs (one per tenant) could be used to restrict tenant broadcast domains >> if >> you are running over 802.1q to resolve that challenge; other proposals >> have been >> made in the gazillion tunneling proposals out there like VXLAN and what >> the >> nvo3 folks are doing; some network/NEID is needed to map the proposal here >> to any of these approaches should there be need to - but we are striving >> for >> simplicity as well and not depend on their presence (per the fixed header >> discussion). >> >> cheers, >> jamal >> > From hadi@mojatatu.com Wed Feb 27 05:59:14 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA4EE21F85E7 for ; Wed, 27 Feb 2013 05:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.957 X-Spam-Level: X-Spam-Status: No, score=-102.957 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcsfWQ-mX8dk for ; Wed, 27 Feb 2013 05:59:14 -0800 (PST) Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) by ietfa.amsl.com (Postfix) with ESMTP id 3E97C21F85DA for ; Wed, 27 Feb 2013 05:59:14 -0800 (PST) Received: by mail-ve0-f178.google.com with SMTP id db10so578771veb.9 for ; Wed, 27 Feb 2013 05:59:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=zeSVCT+4O07PM481eaVzs7nEgE7XS9C8QIHDuDHb77c=; b=oRdlpH0K+Z0gkG97hVBcBDBkPEzz1T3YRbJGLB6PL1wtsfEw4sJC4aImrzEEjtTLEV 5NISLlGdw+DXP/rwTnfzJ/3KKuFlZTaNQo1mbutOJ9oKqT0iYWz7+HOkqFLeH6O2OjHW OzFuEZiKBE3pZdxS4yB3U4cbLNVtWvUTjGV2TWvk+/wd1qgWCueqwWnaKkQcN43XhaLQ 1K2JBZHBp6uXlkYIE26ZqjbWj5xvwzqpyN0QRcCSh/y9mOQ1YQd5fNy2ZcAUgzFT7AZR tzrOmUuHaXpTlpoPvPvkgHCH/hxv6uYoX/TWuEiXdUyQz7p55RQ50FytKgbwsDFWU5ki UuYw== X-Received: by 10.58.155.99 with SMTP id vv3mr891771veb.50.1361973553573; Wed, 27 Feb 2013 05:59:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.251.210 with HTTP; Wed, 27 Feb 2013 05:58:53 -0800 (PST) From: Jamal Hadi Salim Date: Wed, 27 Feb 2013 08:58:53 -0500 Message-ID: To: forces@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmnnV4MsfbipG0G8dv4GEv/xIx0KR/8htJMuaDBcTuuqyWkKLo0mWp2Jk1oAxjZfp0GKmIH Subject: [forces] re-charter topics X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 13:59:15 -0000 Folks, While it was hard to leave out some of the popular polled items like OF and virtualization from being explicitly mentioned, the following 5 work items are the tasks that are of relevance to a possible re-charter. The decision was purely based on "What is the minimal we could do and must do to complete the work based on deployment experiences and requirements". Veterans like Joel Halpern helped in narrowing down this list. Essentially it boils down to people committed to doing the work and to deploying it. Having said that virtualization (being the most popular work item) is on the list implicitly from an infrastructure perspective. You could still disagree with this task-list in the mailing list or/and at the meeting, but from a personal level i would like it if we reduced the uncertainty we have around the WG on what we should work on. This seems to turn off some people from more deployments. There are a few drafts out there already on some of these topics and there have been presentations made in the past on all these topics (drafts to come where missing). The list is as follows: o Model Extensions and protocol: This work is to address a set of extensions to the base model and protocol resulting in updates to RFCs 5810 and 5812. The model extensions will: 1. Allow complex metadata. 2. Allow optional default values for datatypes 3. Allow optional access-type for datatypes inside complex components 4. Define new base type: Bitmap The protocol extension will: 1. Table range query. 2. Table append 3. Additional return codes to reduce ambiguity o Inter-FE Connectivity: It has been found that ForCES processing often needs to be spread across multiple FEs. The original framework identified this as the Fi interface. Protocol and LFB mechanisms to carry metadata across this Fi interface are now needed. This effort will produce a standards track doument defining the protocol on the wire to address this need, and the LFBs used to represent the interfaces for sending and receiving such information. o Paralellization: While in theory an FE can implement an LFB chain with paralellization, the current mechanism has no means to represent when synchronization is needed, or to allow the CE to specify where it believes such paralllism is useful. This work item will produce a single standards track document to improve the handling of this case. o Subsidiary Management: Deployment experience has demonstrated usefulness of expressing the FEM with the same semantics as any other LFB and thus be controlled by the CE. This work item assumes the presence of an initially booted FE whose configuration could then be updated at runtime via an FEM LFB for runtime config purposes (eg adding a new CE and its associated IP address). This work item can also be useful in addressing control of virtual FEs where individual FEM Managers can be addressed to control the creation, configuration, and resource assignment of such virtual FEs within a physical FE. This work would result in a standards track LFB FEM library RFC. cheers, jamal From hadi@mojatatu.com Wed Feb 27 06:05:21 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2140C21F859B for ; Wed, 27 Feb 2013 06:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.958 X-Spam-Level: X-Spam-Status: No, score=-102.958 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxaHz5MpWCxd for ; Wed, 27 Feb 2013 06:05:20 -0800 (PST) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by ietfa.amsl.com (Postfix) with ESMTP id 840CE21F8573 for ; Wed, 27 Feb 2013 06:05:20 -0800 (PST) Received: by mail-ve0-f170.google.com with SMTP id 14so586556vea.1 for ; Wed, 27 Feb 2013 06:05:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=4YCiMDS3l26W3hF6TvNzCr5CROyiVbBtdF2T6XXRrFA=; b=mLNyPeIvpNQuUvA6NmIMIV/r1h5JHKmhjd90CAK8N+FPOOQ5OthEt+GavWNvk2BW+6 fpRGaFdh4TIs3MW3OMe52a6nD621ymF10anKIbrQM2teNcog0TQhfR1od7h5Wjc+WO5Q VUHj4GRhHaQAW0LHEa1MpOPJmgWtk2PkIUuBNnpjX3QkXE0lQp4+bDvwglj6g3Q16hw9 w8DU1LLMpeYIYK0GCZ0KAZU3ldqrQe0WLTxRp/ngJfvKXy0vWb+2TRAGPe8d2O95/otL 2tKoIXe7ao/9gsqdTO96tdUZ/u76M2ZUmbSbbDM8axTFCyC7XjR0KWIG67gNlqnC6Lfz 0L0g== X-Received: by 10.58.245.40 with SMTP id xl8mr935204vec.33.1361973919893; Wed, 27 Feb 2013 06:05:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.251.210 with HTTP; Wed, 27 Feb 2013 06:04:59 -0800 (PST) From: Jamal Hadi Salim Date: Wed, 27 Feb 2013 09:04:59 -0500 Message-ID: To: forces@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmCEvbWMQOJz7TjgughL29rPz/cEXnzuIYUuzqEyG07xg1N4NZZfOLZJHyRH9hAWnhgs69C Subject: [forces] call for presentations at the meeting X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 14:05:21 -0000 Hi, If you would like to present at the upcoming meeting please post here or unicast me an email. The topics have to be centred around the posting i just made on recharter topics. I think we already have at least one possible presentation on each "possible recharter" topic based on current drafts and past presentations. If you have alternative approaches to reach the outlined goal, please ask for a slot. If you have a high level generic view for example on the virtualization aspect (hopefully within the "possible recharter scope" that you want to discuss - please ask for a slot) if you have grievances with that task list you may also ask for a slot. cheers, jamal From joel@stevecrocker.com Wed Feb 27 06:08:23 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9174321F84D8 for ; Wed, 27 Feb 2013 06:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30Ly69I+Q5yC for ; Wed, 27 Feb 2013 06:08:23 -0800 (PST) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id BE54821F84F8 for ; Wed, 27 Feb 2013 06:08:22 -0800 (PST) Received: from dummy.name; Wed, 27 Feb 2013 14:08:30 +0000 Message-ID: <512E1343.1090802@stevecrocker.com> Date: Wed, 27 Feb 2013 09:08:03 -0500 From: Joel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Jamal Hadi Salim References: <20130225112953.16123.97093.idtracker@ietfa.amsl.com> <512BA8BD.7090508@stevecrocker.com> <512CBFA3.7080301@stevecrocker.com> <512D32DA.7060302@stevecrocker.com> <512D50BA.9090501@stevecrocker.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces@ietf.org Subject: Re: [forces] Fwd: New Version Notification for draft-joachimpillai-forces-interfelfb-01.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 14:08:23 -0000 Optional fields in the basic message demultiplex path make me nervous. They tend to be less tested and more error prone. Architecturally, prefer if messages are addresses consistently. Among other things, that meas that you have to ensure consistent configuration on the generator and receiver. Which is error-prone. Thus I am looking for simple and consistent. Also, unless there i a case where we need the NEID, we should not have it as addressing / delivery information. Even as piece of extra metadata that a receiving LFB can check if it wants, there really should be a case where it adds value before we define it and expect generators to add it. Yours, Joel On 2/27/2013 7:32 AM, Jamal Hadi Salim wrote: > On Tue, Feb 26, 2013 at 7:18 PM, Joel wrote: >> If you have multiple tenants, you have to have other means of tenant >> isolation. Generally, MAC addresses are not duplicated across tenants in >> the same physical device. Also, there is usually also enforced VLAN >> segregation. > > We probably dont differ in that thought. We are saying in presence of > such infrastructure it could be made use of. i.e someone would take > the NEID and map it to a vlanid and we are set. Or if they want to > use the VXLAN, they could etc. > This is why we were making the NESelector optional. > But if they want to use none of the above, they should be able to set the > NEID somewhere. If we are going to use a fixed header - then somewhere > in there would be an optional NEID. > > cheers, > jamal > >> It would seem that combination would cover what ou wanted to accomplish with >> the NEID. >> > > >> Yours, >> Joel >> >> >> On 2/26/2013 6:13 PM, Jamal Hadi Salim wrote: >>> >>> On Tue, Feb 26, 2013 at 5:10 PM, Joel wrote: >>>> >>>> can you elaborate on the case of overlapping FEIDs? >>>> I can think of two cases I know of: >>>> 1) Each FE is a complete virtual machine. In that case, each one has its >>>> own MAC address. >>>> 2) The individual FEs are created through the ForCES manipulation of a >>>> master FE. In that case, the master can assign the FE-IDs so that they >>>> don't overlap. >>>> >>>> I presume there are other cases I have missed? >>>> >>> >>> That would cover what i am interested in: >>> The only difference is when you have multiple tenants. All possibly >>> running >>> on the same location. In that case even the MAC address is game to be >>> overlapping. >>> VLANs (one per tenant) could be used to restrict tenant broadcast domains >>> if >>> you are running over 802.1q to resolve that challenge; other proposals >>> have been >>> made in the gazillion tunneling proposals out there like VXLAN and what >>> the >>> nvo3 folks are doing; some network/NEID is needed to map the proposal here >>> to any of these approaches should there be need to - but we are striving >>> for >>> simplicity as well and not depend on their presence (per the fixed header >>> discussion). >>> >>> cheers, >>> jamal >>> >> From vumip1@gmail.com Wed Feb 27 08:35:42 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1DB21F87CE for ; Wed, 27 Feb 2013 08:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYF7fWp3uuP4 for ; Wed, 27 Feb 2013 08:35:42 -0800 (PST) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id AC85D21F8569 for ; Wed, 27 Feb 2013 08:35:41 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id t44so649204wey.12 for ; Wed, 27 Feb 2013 08:35:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=PB8fkdSkQkZ5Z1Q44cq1+E4dm4fx4ucx0681kbuS2/A=; b=Cpk08M9vuQ5M0PLIYne5l9HuKZOPv1st8AGAExrms3GzWsCZkGma44AI9R2ysxgO0p ETMonLuT+0DkiFRdH+Fb4+FK3TcjM2wugixlzjWZbL50uUV4wLhbtCxRv0yXe9aR8EU9 sc3SwtIUw331blf3eb7ZWhp32EVyueUXbjxJU9GiJ0HKLeJo9HpfHjn20tmf0q7eggbI yXGl4SYNE1khJDSx0jEhQ3OplkKtzSkiciYLLEud3fnxmOusK3L8hGm8OKRBbQthKwjc 43JlG980poftKOaUPAeisPw9ZJyeFhiHI+J2ZGwxavtFcOB3aJCZT7CXpdLiiaiG5N2C n8ZA== MIME-Version: 1.0 X-Received: by 10.194.133.98 with SMTP id pb2mr5234041wjb.20.1361982940740; Wed, 27 Feb 2013 08:35:40 -0800 (PST) Received: by 10.216.124.5 with HTTP; Wed, 27 Feb 2013 08:35:40 -0800 (PST) In-Reply-To: References: Date: Wed, 27 Feb 2013 11:35:40 -0500 Message-ID: From: "B.Khasnabish@ieee.org" To: Jamal Hadi Salim Content-Type: multipart/alternative; boundary=089e0117742b5f851304d6b75d15 Cc: forces@ietf.org Subject: Re: [forces] call for presentations at the meeting X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 16:35:42 -0000 --089e0117742b5f851304d6b75d15 Content-Type: text/plain; charset=ISO-8859-1 Hello Jamal, Thanks. Sure, if possible I would like request for a short slot to discuss virtualiztion and possible updating of the existing drafts (also explore if we need any new drafts). Best. Bhumip On Wed, Feb 27, 2013 at 9:04 AM, Jamal Hadi Salim wrote: > Hi, > > If you would like to present at the upcoming meeting please > post here or unicast me an email. > The topics have to be centred around the posting i just made > on recharter topics. > I think we already have at least one possible presentation on each > "possible recharter" topic based on current drafts and past presentations. > If you have alternative approaches to reach the outlined goal, please > ask for a slot. > If you have a high level generic view for example on the virtualization > aspect (hopefully within the "possible recharter scope" that > you want to discuss - please ask for a slot) > if you have grievances with that task list you may also ask for a slot. > > cheers, > jamal > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > --089e0117742b5f851304d6b75d15 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Jamal,
=A0
Thanks. Sure, if possible I would like request for a short slot to dis= cuss virtualiztion and possible updating of the existing drafts (also explo= re if we need any new drafts).
=A0
Best.
=A0
Bhumip


=A0
On Wed, Feb 27, 2013 at 9:04 AM, Jamal Hadi Sali= m <hadi@mojatatu.com> wrote:
Hi,

If you would like to prese= nt at the upcoming meeting please
post here or unicast me an email.
The topics have to be centred around the posting i just made
on recharte= r topics.
I think we already have at least one possible presentation on = each
"possible recharter" topic based on current drafts and pa= st presentations.
If you have alternative approaches to reach the outlined goal, please
as= k for a slot.
If you have a high level generic view for example on the v= irtualization
aspect (hopefully within the "possible recharter scop= e" that
you want to discuss - please ask for a slot)
if you have grievances with= that task list you may also ask for a slot.

cheers,
jamal
___= ____________________________________________
forces mailing list
forces@ietf.org
https://www.ietf.= org/mailman/listinfo/forces



=A0 --089e0117742b5f851304d6b75d15-- From jmh@joelhalpern.com Wed Feb 27 09:19:36 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346AA21F854C for ; Wed, 27 Feb 2013 09:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHuX7mYxhc3B for ; Wed, 27 Feb 2013 09:19:35 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 206C421F8549 for ; Wed, 27 Feb 2013 09:19:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id F2F611C6E74 for ; Wed, 27 Feb 2013 09:19:34 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-134-134.clppva.east.verizon.net [70.106.134.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 910131C050E for ; Wed, 27 Feb 2013 09:19:34 -0800 (PST) Message-ID: <512E4013.9030205@joelhalpern.com> Date: Wed, 27 Feb 2013 12:19:15 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: forces Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [forces] InterFE Packet metadata X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 17:19:36 -0000 While discussing a related topic with someone else, I wondered about something. In the redirect TLV (and presumably also in the inter-FE packet transfer) we say taht the metadata indicates what kind of packet is being transferred. But I don't think we ever actually defined the packet-type metadatum. We have packet types in the dataplane flow, but that is not a piece of metadata. have I forgotten something obvios, or do we have a gap? (We can easily fix it in the lfb-library if we have a gap.) Yours, Joel From hadi@mojatatu.com Wed Feb 27 10:22:42 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7EC21F861B for ; Wed, 27 Feb 2013 10:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.959 X-Spam-Level: X-Spam-Status: No, score=-102.959 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwFjmvMxuzCU for ; Wed, 27 Feb 2013 10:22:42 -0800 (PST) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by ietfa.amsl.com (Postfix) with ESMTP id 16B5C21F88C1 for ; Wed, 27 Feb 2013 10:22:41 -0800 (PST) Received: by mail-ve0-f170.google.com with SMTP id 14so921056vea.1 for ; Wed, 27 Feb 2013 10:22:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=qGhIqcXSQTlauPRrzY81B0rX3hLzdbCidCGUsjlmV7o=; b=aqxcG7qB/GVexSYqadFIlGFHsOar3hN7YG3jy4pEGhU666npggG0RwbbCaacQlYm1t hjt2vJjp9dBD4Ln4p6JqtfI1dzfebwsZV82h6BAvRBq0ydAXhaNM1SvPTUt0dY17DA9V FypIiey5tJzrUBretr/Eqw0tDbtxV0BLckm5S9EZzMXMtRS0cnQPC31xFbWNP+xZaox+ NHxxvwauN9LA645Swz5yhTuHCH9lls9qck6FxdY1j4OcfsQcVpG5mcpD7A4Uq32xanAJ wfamV9Mo6ESl1Ovkd1jy0I9sHmqISo+9gcEXB+SVeAhzWpjIc9kYAkAlfb6INNtw8djV 8EEw== X-Received: by 10.220.239.14 with SMTP id ku14mr1234569vcb.57.1361989357513; Wed, 27 Feb 2013 10:22:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.251.210 with HTTP; Wed, 27 Feb 2013 10:22:17 -0800 (PST) In-Reply-To: <512E4013.9030205@joelhalpern.com> References: <512E4013.9030205@joelhalpern.com> From: Jamal Hadi Salim Date: Wed, 27 Feb 2013 13:22:17 -0500 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmzOQmBegJCDKNREYPVhy4AerewBxvhu9FBwbYBllpRVS2ZeN8BvU7Dm96TsCK/rcQTg/HU Cc: forces Subject: Re: [forces] InterFE Packet metadata X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 18:22:42 -0000 We have a REDIRECT-DATA TLV (0x116) which is for the packet data. The METADATA TLV (0x115) carries the metadata. cheers, jamal On Wed, Feb 27, 2013 at 12:19 PM, Joel M. Halpern wrote: > While discussing a related topic with someone else, I wondered about > something. In the redirect TLV (and presumably also in the inter-FE packet > transfer) we say taht the metadata indicates what kind of packet is being > transferred. > But I don't think we ever actually defined the packet-type metadatum. We > have packet types in the dataplane flow, but that is not a piece of > metadata. > have I forgotten something obvios, or do we have a gap? (We can easily fix > it in the lfb-library if we have a gap.) > > Yours, > Joel > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From hadi@mojatatu.com Wed Feb 27 10:48:02 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9847721F8A0C for ; Wed, 27 Feb 2013 10:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.96 X-Spam-Level: X-Spam-Status: No, score=-102.96 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRtLHut9vo2J for ; Wed, 27 Feb 2013 10:48:02 -0800 (PST) Received: from mail-ve0-f172.google.com (mail-ve0-f172.google.com [209.85.128.172]) by ietfa.amsl.com (Postfix) with ESMTP id E176D21F89D3 for ; Wed, 27 Feb 2013 10:48:01 -0800 (PST) Received: by mail-ve0-f172.google.com with SMTP id cz11so936693veb.31 for ; Wed, 27 Feb 2013 10:48:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=3jg55HeqWuT5SlVWtPFfVVaSvu86Z7OLOTCgBUfmgk8=; b=j9jg4VLRqPt6j/8vB9XpnJYQY17X0nB2pF9xeXg5Nxq1z6/jDAZXqaJMwI+YeSH4t+ Q9kbOJKe9vbIm8Lk27ylJxFxfhm8ImnxJTW7yWiNwnnyImLrdo0H5Oi/g8ysyOmhi6UG bIwUduLKHMpQNSu0G47am2VhtqaiojQIBTheA1tCHL/uKmxogLRc8JlFQVa8e+Ye55sG pqi29myTeEr8gKtZ2p30z+1pZ6NWn73QvxB++mO+SBsIWMfkYPB1ZnTTZBe2x0A7CB8M ri6jKaSnTcB79cyOul5QujwORuipofomFv9TsQQyHrFAag7si29Ali/FcbipJvR23J1d 02+Q== X-Received: by 10.52.91.212 with SMTP id cg20mr1161743vdb.63.1361990881117; Wed, 27 Feb 2013 10:48:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.251.210 with HTTP; Wed, 27 Feb 2013 10:47:41 -0800 (PST) In-Reply-To: <512E1343.1090802@stevecrocker.com> References: <20130225112953.16123.97093.idtracker@ietfa.amsl.com> <512BA8BD.7090508@stevecrocker.com> <512CBFA3.7080301@stevecrocker.com> <512D32DA.7060302@stevecrocker.com> <512D50BA.9090501@stevecrocker.com> <512E1343.1090802@stevecrocker.com> From: Jamal Hadi Salim Date: Wed, 27 Feb 2013 13:47:41 -0500 Message-ID: To: Joel Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkXRjZ555hK5KMnwHM4KZzIuyGRMuz8JpGzJdSXuxBuzzWZ1N6N+WrH29X5+jbj5NAeTZnc Cc: forces@ietf.org Subject: Re: [forces] Fwd: New Version Notification for draft-joachimpillai-forces-interfelfb-01.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 18:48:02 -0000 On Wed, Feb 27, 2013 at 9:08 AM, Joel wrote: > Optional fields in the basic message demultiplex path make me nervous. They > tend to be less tested and more error prone. Architecturally, prefer if > messages are addresses consistently. > > Among other things, that meas that you have to ensure consistent > configuration on the generator and receiver. Which is error-prone. > > Thus I am looking for simple and consistent. So it seems like we could just re-use our 24B header then. It would have a slightly different interpretation when it is an interfe redirect message type is used. e.g the from/to would be FEID addresses. > Also, unless there i a case where we need the NEID, we should not have it as > addressing / delivery information. Even as piece of extra metadata that a > receiving LFB can check if it wants, there really should be a case where it > adds value before we define it and expect generators to add it. > So back to my original question Joel: if the message is unidirectional(from one FE to another) and we have this 64bit correlator field available that is not useful (since semantics of correlator are bidirectional) then we could abuse it to store a 32-bit NEID when needed. A value of 0 or in case the NEID is mapped to something like a VLAN or some other tunnelid implies it is to be ignored. cheers, jamal From joel@stevecrocker.com Wed Feb 27 10:54:21 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9F121F8962 for ; Wed, 27 Feb 2013 10:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.305 X-Spam-Level: X-Spam-Status: No, score=-1.305 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7q7FbEXhjKNd for ; Wed, 27 Feb 2013 10:54:20 -0800 (PST) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 050ED21F88DB for ; Wed, 27 Feb 2013 10:54:18 -0800 (PST) Received: from dummy.name; Wed, 27 Feb 2013 18:54:27 +0000 Message-ID: <512E5646.3020607@stevecrocker.com> Date: Wed, 27 Feb 2013 13:53:58 -0500 From: Joel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Jamal Hadi Salim References: <20130225112953.16123.97093.idtracker@ietfa.amsl.com> <512BA8BD.7090508@stevecrocker.com> <512CBFA3.7080301@stevecrocker.com> <512D32DA.7060302@stevecrocker.com> <512D50BA.9090501@stevecrocker.com> <512E1343.1090802@stevecrocker.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces@ietf.org Subject: Re: [forces] Fwd: New Version Notification for draft-joachimpillai-forces-interfelfb-01.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 18:54:21 -0000 We could use the correlator for the NEID. What I was actually thinking of is using it for the fragment numbers (and use some flag bits for fragmenting when the message is carried over a size-limited packet stream. There are probably enough bits that we could use a flag to indicate the correlator is being reused, and then use one piece for the NEID and one for the fragmentation ID. Yours, Joel On 2/27/2013 1:47 PM, Jamal Hadi Salim wrote: > On Wed, Feb 27, 2013 at 9:08 AM, Joel wrote: >> Optional fields in the basic message demultiplex path make me nervous. They >> tend to be less tested and more error prone. Architecturally, prefer if >> messages are addresses consistently. >> >> Among other things, that meas that you have to ensure consistent >> configuration on the generator and receiver. Which is error-prone. >> >> Thus I am looking for simple and consistent. > > So it seems like we could just re-use our 24B header then. It would > have a slightly different interpretation when it is an interfe redirect > message type is used. > e.g the from/to would be FEID addresses. > >> Also, unless there i a case where we need the NEID, we should not have it as >> addressing / delivery information. Even as piece of extra metadata that a >> receiving LFB can check if it wants, there really should be a case where it >> adds value before we define it and expect generators to add it. >> > > So back to my original question Joel: > if the message is unidirectional(from one FE to another) and we > have this 64bit correlator field available that is not useful > (since semantics of correlator are bidirectional) then we could abuse it > to store a 32-bit NEID when needed. A value of 0 or in case the NEID > is mapped to something like a VLAN or some other tunnelid implies > it is to be ignored. > > cheers, > jamal > From hadi@mojatatu.com Wed Feb 27 13:09:41 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B1D21F884C for ; Wed, 27 Feb 2013 13:09:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.961 X-Spam-Level: X-Spam-Status: No, score=-102.961 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ho6Zw2CIjkPJ for ; Wed, 27 Feb 2013 13:09:40 -0800 (PST) Received: from mail-ve0-f179.google.com (mail-ve0-f179.google.com [209.85.128.179]) by ietfa.amsl.com (Postfix) with ESMTP id 726DA21F8838 for ; Wed, 27 Feb 2013 13:09:40 -0800 (PST) Received: by mail-ve0-f179.google.com with SMTP id da11so1078630veb.38 for ; Wed, 27 Feb 2013 13:09:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=5yyB517JBlj0U1/p8tYft1Hbsx8R5JTuEQmG57nbgKw=; b=ZlTGtTCL5kKwGZFDkPJ5Vgm0HbQ6JNG4fjrmLzYcoMP3ia/a4VUm7mfa80Fo1dxENv 6ijdGmCJW1xmlx+PQ3pTrpQOncjRO31ZZvI06XykgCkcKvcu2ED+HtuNc26IvQvrsX0r exKc5/sVAfJEEH+l5VqDZrz4s3vWg3/20B8DUV89MEjbwG40OX86cQDz4xHPBBpO0EJl aMn7lXnRcLgEUlsvXTynBRb2y1/bJ4Jn9vucesLl+JGH+kaLD3IK2mfvZF5lcA/P+rcn hfq8yIGrcYAbSenlTkl1GHQBrvdQAEhHusASbJmwYQ/ifRMXsI4uyiaCLxkcNW1MLWAB XQFg== X-Received: by 10.220.219.73 with SMTP id ht9mr1456952vcb.47.1361999379689; Wed, 27 Feb 2013 13:09:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.251.210 with HTTP; Wed, 27 Feb 2013 13:09:19 -0800 (PST) In-Reply-To: References: <512E4013.9030205@joelhalpern.com> From: Jamal Hadi Salim Date: Wed, 27 Feb 2013 16:09:19 -0500 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnnI6YK3yxdoywUnglu/hK8a7zV2EX9xNxk2rPZNUCKEOKKkRs2y0YgEj/Nn+D3Qo2BFceT Cc: forces Subject: Re: [forces] InterFE Packet metadata X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 21:09:41 -0000 Ok, I finally got what Joel was alluding to. We _cant_ tell the content by looking at the REDIRECT-DATA TLV. The assumption is the receiver knows what the data is. Strangely enough, we havent run into any issues in our implementation - I suppose because we only have one source of redirected data and we know what it is at the receiver. We should be able to define a metadata type which specifies this. Not sure if lfblib would be the right place to do this. cheers, jamal On Wed, Feb 27, 2013 at 1:22 PM, Jamal Hadi Salim wrote: > We have a REDIRECT-DATA TLV (0x116) which is for the packet data. > The METADATA TLV (0x115) carries the metadata. > > cheers, > jamal > > On Wed, Feb 27, 2013 at 12:19 PM, Joel M. Halpern wrote: >> While discussing a related topic with someone else, I wondered about >> something. In the redirect TLV (and presumably also in the inter-FE packet >> transfer) we say taht the metadata indicates what kind of packet is being >> transferred. >> But I don't think we ever actually defined the packet-type metadatum. We >> have packet types in the dataplane flow, but that is not a piece of >> metadata. >> have I forgotten something obvios, or do we have a gap? (We can easily fix >> it in the lfb-library if we have a gap.) >> >> Yours, >> Joel >> _______________________________________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/listinfo/forces From hadi@mojatatu.com Wed Feb 27 13:12:00 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166C421F88AC for ; Wed, 27 Feb 2013 13:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.962 X-Spam-Level: X-Spam-Status: No, score=-102.962 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVavj4X2PDos for ; Wed, 27 Feb 2013 13:11:59 -0800 (PST) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5842421F884C for ; Wed, 27 Feb 2013 13:11:59 -0800 (PST) Received: by mail-ve0-f182.google.com with SMTP id ox1so1102556veb.27 for ; Wed, 27 Feb 2013 13:11:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=ozUA9rvy8BGjJKrLI+ndHhLifriPHahdWuK2SJu31/k=; b=P0CF3mxivjeAlL+SiEguj5jC5xGvMeyTvjYtznYhSCUxdYrWPQFjgkk3bE5+mrs3Jl U34Vl1ELZh7NzLnJW/T12fHLEuE1Lod8F/KocCQQaamsEM9zxjhEFb0LRKosjDtYMxii xAC2YcSwW0nbDop+PCfXjGbiHQGlGOpeKhwFe+ZvX5RzxCdbPbsxpiudpyTD5H2uCGit 4nigmp3Ki8bv3wNzdutnaD5SEwA9EOVgy/mTOzgFqDXWY57bz0EkFMpwPAqPR5uNpx8P 16J7FIJUpy2iAwWRaY9xcv87Y94jiM5ouLyXo9eAPRgwqsnBIqrAvXCK+mp6uDMxkS7J PH6Q== X-Received: by 10.52.175.66 with SMTP id by2mr1350481vdc.53.1361999518613; Wed, 27 Feb 2013 13:11:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.251.210 with HTTP; Wed, 27 Feb 2013 13:11:38 -0800 (PST) In-Reply-To: <512E5646.3020607@stevecrocker.com> References: <20130225112953.16123.97093.idtracker@ietfa.amsl.com> <512BA8BD.7090508@stevecrocker.com> <512CBFA3.7080301@stevecrocker.com> <512D32DA.7060302@stevecrocker.com> <512D50BA.9090501@stevecrocker.com> <512E1343.1090802@stevecrocker.com> <512E5646.3020607@stevecrocker.com> From: Jamal Hadi Salim Date: Wed, 27 Feb 2013 16:11:38 -0500 Message-ID: To: Joel Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlg7OPmKwanIqxYrlq6IzeiUWM/x6r0S7vc7mie9AmldLJJbvJpu+XKy6OCYIHJmKf4QZ2G Cc: forces@ietf.org Subject: Re: [forces] Fwd: New Version Notification for draft-joachimpillai-forces-interfelfb-01.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 21:12:00 -0000 We have enough flag space and a spare 32 bit out of the correlator for the fragmentation info. cheers, jamal On Wed, Feb 27, 2013 at 1:53 PM, Joel wrote: > We could use the correlator for the NEID. What I was actually thinking of > is using it for the fragment numbers (and use some flag bits for fragmenting > when the message is carried over a size-limited packet stream. > There are probably enough bits that we could use a flag to indicate the > correlator is being reused, and then use one piece for the NEID and one for > the fragmentation ID. > > Yours, > Joel > > > On 2/27/2013 1:47 PM, Jamal Hadi Salim wrote: >> >> On Wed, Feb 27, 2013 at 9:08 AM, Joel wrote: >>> >>> Optional fields in the basic message demultiplex path make me nervous. >>> They >>> tend to be less tested and more error prone. Architecturally, prefer if >>> messages are addresses consistently. >>> >>> Among other things, that meas that you have to ensure consistent >>> configuration on the generator and receiver. Which is error-prone. >>> >>> Thus I am looking for simple and consistent. >> >> >> So it seems like we could just re-use our 24B header then. It would >> have a slightly different interpretation when it is an interfe redirect >> message type is used. >> e.g the from/to would be FEID addresses. >> >>> Also, unless there i a case where we need the NEID, we should not have it >>> as >>> addressing / delivery information. Even as piece of extra metadata that >>> a >>> receiving LFB can check if it wants, there really should be a case where >>> it >>> adds value before we define it and expect generators to add it. >>> >> >> So back to my original question Joel: >> if the message is unidirectional(from one FE to another) and we >> have this 64bit correlator field available that is not useful >> (since semantics of correlator are bidirectional) then we could abuse it >> to store a 32-bit NEID when needed. A value of 0 or in case the NEID >> is mapped to something like a VLAN or some other tunnelid implies >> it is to be ignored. >> >> cheers, >> jamal >> >