From ancp-bounces@ietf.org Thu Apr 3 03:38:02 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC9B028C0FD; Thu, 3 Apr 2008 03:38:02 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0589E3A6A5E for ; Thu, 3 Apr 2008 03:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.106 X-Spam-Level: ** X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0jdoZTG44qD for ; Thu, 3 Apr 2008 03:38:01 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [61.144.161.55]) by core3.amsl.com (Postfix) with ESMTP id 9ADC228C0DB for ; Thu, 3 Apr 2008 03:38:00 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JYQ00CHNVTF0N@szxga03-in.huawei.com> for ancp@ietf.org; Thu, 03 Apr 2008 18:29:40 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JYQ00HANVTF3Z@szxga03-in.huawei.com> for ancp@ietf.org; Thu, 03 Apr 2008 18:29:39 +0800 (CST) Received: from z24109b ([10.70.76.172]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JYQ00MLZVTF1A@szxml04-in.huawei.com> for ancp@ietf.org; Thu, 03 Apr 2008 18:29:39 +0800 (CST) Date: Thu, 03 Apr 2008 18:29:39 +0800 From: Tina TSOU To: ancp@ietf.org Message-id: <006701c89575$9f4d61a0$ac4c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <1B6169C658325341A3B8066E23919E1C81F76F@S4DE8PSAANK.mitte.t-com.de> <47B94869.8030905@alcatel-lucent.be> <1B6169C658325341A3B8066E23919E1C81F782@S4DE8PSAANK.mitte.t-com.de> <47BAE191.5040406@alcatel-lucent.be> <1B6169C658325341A3B8066E23919E1C81F785@S4DE8PSAANK.mitte.t-com.de> <47BC2A44.4050104@alcatel-lucent.be> <83153A1EB675AF4F82E134FA27F95F6702F9C8D0@ilptex01.ecitele.com> <1B6169C658325341A3B8066E23919E1C81F78C@S4DE8PSAANK.mitte.t-com.de> <83153A1EB675AF4F82E134FA27F95F6702F9CA89@ilptex01.ecitele.com> <47BD83E7.4040009@alcatel-lucent.be> <83153A1EB675AF4F82E134FA27F95F6702FE934A@ilptex01.ecitele.com> <1B6169C658325341A3B8066E23919E1C81F869@S4DE8PSAANK.mitte.t-com.de> <7A6D4815C5E8F74988784FEBD50F2F1E017D7C29@FRVELSMBS22.ad2.ad.alcatel.com> <1B6169C658325341A3B8066E23919E1C81F86B@S4DE8PSAANK.mitte.t-com.de> <1B6169C658325341A3B8066E23919E1C81F897@S4DE8PSAANK.mitte.t-com.de> <7A6D4815C5E8F74988784FEBD50F2F1E01866986@FRVELSMBS22.ad2.ad.alcatel.com> Subject: Re: [ANCP] White-List and Black-List definition X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1716385297==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1716385297== Content-type: multipart/alternative; boundary="Boundary_(ID_mb9SXpm/+AsDzGZY6+kwxw)" This is a multi-part message in MIME format. --Boundary_(ID_mb9SXpm/+AsDzGZY6+kwxw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi all, Besides White-List and Black-List usage description, do we need formal definitions for them respectively in some ANCP WG draft? B. R. Tina --Boundary_(ID_mb9SXpm/+AsDzGZY6+kwxw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi all,
Besides White-List and Black-List usage description, do we need formal definitions for them respectively in some ANCP WG draft?
 
B. R.
Tina
 
--Boundary_(ID_mb9SXpm/+AsDzGZY6+kwxw)-- --===============1716385297== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============1716385297==-- From ancp-bounces@ietf.org Thu Apr 3 05:03:30 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EED8D28C68D; Thu, 3 Apr 2008 05:03:29 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 673D228C66B for ; Thu, 3 Apr 2008 05:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RH4i009bKoqr for ; Thu, 3 Apr 2008 05:03:27 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9864F28C6BC for ; Thu, 3 Apr 2008 05:03:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,598,1199660400"; d="scan'208,217";a="5271910" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 03 Apr 2008 14:03:20 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m33C3IVU008185; Thu, 3 Apr 2008 14:03:18 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m33C3IID003939; Thu, 3 Apr 2008 12:03:18 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 14:03:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 14:03:15 +0200 Message-ID: In-Reply-To: <006701c89575$9f4d61a0$ac4c460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] White-List and Black-List definition thread-index: AciVds/2oKr8l6rRSU+COBTYMJTflgACgJpg References: <1B6169C658325341A3B8066E23919E1C81F76F@S4DE8PSAANK.mitte.t-com.de><47B94869.8030905@alcatel-lucent.be><1B6169C658325341A3B8066E23919E1C81F782@S4DE8PSAANK.mitte.t-com.de><47BAE191.5040406@alcatel-lucent.be><1B6169C658325341A3B8066E23919E1C81F785@S4DE8PSAANK.mitte.t-com.de><47BC2A44.4050104@alcatel-lucent.be><83153A1EB675AF4F82E134FA27F95F6702F9C8D0@ilptex01.ecitele.com><1B6169C658325341A3B8066E23919E1C81F78C@S4DE8PSAANK.mitte.t-com.de><83153A1EB675AF4F82E134FA27F95F6702F9CA89@ilptex01.ecitele.com><47BD83E7.4040009@alcatel-lucent.be><83153A1EB675AF4F82E134FA27F95F6702FE934A@ilptex01.ecitele.com><1B6169C658325341A3B8066E23919E1C81F869@S4DE8PSAANK.mitte.t-com.de><7A6D4815C5E8F74988784FEBD50F2F1E017D7C29@FRVELSMBS22.ad2.ad.alcatel.com><1B6169C658325341A3B8066E23919E1C81F86B@S4DE8PSAANK.mitte.t-com.de><1B6169C658325341A3B8066E23919E1C81F897@S4DE8PSAANK.mitte.t-com.de><7A6D4815C5E8F74988784FEBD50F2F1E01866986@FRVELSMBS22.ad2.ad.alcatel.com> <006701c89575$9f4d61a0$ac4c46 0a@china .huawei.com> From: "Wojciech Dec (wdec)" To: "Tina TSOU" , X-OriginalArrivalTime: 03 Apr 2008 12:03:18.0456 (UTC) FILETIME=[B4605B80:01C89582] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3290; t=1207224198; x=1208088198; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20[ANCP]=20White-List=20and=20Black-List= 20definition |Sender:=20; bh=mgs2zk3GrpC4XddO6ooa0bA8Vr7xf3GxPhk+IuJkIGI=; b=YqohwWeG/R4RPycKR9+c4MXCu/HXlcdyLhearZqF1PnuUJxeZOxP/bP+65 IlKOXyh0SX/6vB49WCIGouWM+H1GNsWEHl81XHmTNZ6kR//A4K3GiKq2YUt/ 7oWNSLgfR7; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [ANCP] White-List and Black-List definition X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0613156866==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0613156866== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89582.B40AFF96" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89582.B40AFF96 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tina, =20 Are you asking for an additional description to what the framework draft (draft-ietf-ancp-framework) already describes in terms of white/black/grey list? If so, could you share in what areas would you see as needing more formal definition? =20 Regards, Woj. ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Tina TSOU Sent: 03 April 2008 12:30 To: ancp@ietf.org Subject: Re: [ANCP] White-List and Black-List definition =09 =09 Hi all, Besides White-List and Black-List usage description, do we need formal definitions for them respectively in some ANCP WG draft? =20 B. R. Tina =20 ------_=_NextPart_001_01C89582.B40AFF96 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Tina,
 
Are you asking for an additional description to what the = framework draft=20 (draft-ietf-ancp-framework) already describes in terms of  = white/black/grey=20 list? If so, could you share in what areas would you see as needing = more=20 formal definition?
 
Regards,
Woj.

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Tina = TSOU
Sent:=20 03 April 2008 12:30
To: ancp@ietf.org
Subject: Re: = [ANCP]=20 White-List and Black-List definition

Hi all,
Besides White-List and Black-List = usage=20 description, do we need formal definitions for them respectively = in some=20 ANCP WG draft?
 
B. R.
Tina
 
------_=_NextPart_001_01C89582.B40AFF96-- --===============0613156866== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============0613156866==-- From ancp-bounces@ietf.org Tue Apr 8 01:42:35 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31D0C3A6BA1; Tue, 8 Apr 2008 01:42:35 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 754E93A68A5 for ; Tue, 8 Apr 2008 01:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.967 X-Spam-Level: * X-Spam-Status: No, score=1.967 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_40=-0.185, FAKE_REPLY_C=2.012, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJne2hdpGai3 for ; Tue, 8 Apr 2008 01:42:33 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [61.144.161.53]) by core3.amsl.com (Postfix) with ESMTP id 102673A6BA1 for ; Tue, 8 Apr 2008 01:42:33 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JZ000MI807A22@szxga01-in.huawei.com> for ancp@ietf.org; Tue, 08 Apr 2008 16:42:46 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JZ00039X07ARW@szxga01-in.huawei.com> for ancp@ietf.org; Tue, 08 Apr 2008 16:42:46 +0800 (CST) Received: from z24109b ([10.70.76.172]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JZ0005DC079CS@szxml04-in.huawei.com> for ancp@ietf.org; Tue, 08 Apr 2008 16:42:46 +0800 (CST) Date: Tue, 08 Apr 2008 16:42:45 +0800 From: Tina TSOU To: ancp@ietf.org Message-id: <014101c89954$847a9db0$ac4c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal Subject: Re: [ANCP] White-List and Black-List definition X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0585277284==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0585277284== Content-type: multipart/alternative; boundary="Boundary_(ID_5duczQy7lfuSIMNH0fgL+w)" This is a multi-part message in MIME format. --Boundary_(ID_5duczQy7lfuSIMNH0fgL+w) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi Woj, http://www.ietf.org/mail-archive/web/ancp/current/msg00543.html Thank you for your reply. It describes the concept, not the specific definition. It says that white/black/grey list use line configuration message expansion to implement; I guess the main content of white/black/grey list is below: the program ordered by user, the program corresponding group IP, order program purview. I did not see the complete message format for it. Would you like to give me a hint where it is? B. R. Tina --Boundary_(ID_5duczQy7lfuSIMNH0fgL+w) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi Woj,
 
Thank you for your reply.
 

It describes the concept, not the specific definition.

It says that white/black/grey list use line configuration message expansion to implement; I guess the main content of white/black/grey list is below: the program ordered by user, the program corresponding group IP, order program purview.

I did not see the complete message format for it. Would you like to give me a hint where it is?

 
 
B. R.
Tina
--Boundary_(ID_5duczQy7lfuSIMNH0fgL+w)-- --===============0585277284== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============0585277284==-- From ancp-bounces@ietf.org Tue Apr 8 09:30:49 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E07633A6C0A; Tue, 8 Apr 2008 09:30:49 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9640B28C3F7 for ; Tue, 8 Apr 2008 09:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7jbc8Ps-0wM for ; Tue, 8 Apr 2008 09:30:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C150A28C3C3 for ; Tue, 8 Apr 2008 09:30:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,624,1199660400"; d="scan'208";a="5714858" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Apr 2008 18:30:34 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m38GUY5C017837; Tue, 8 Apr 2008 18:30:34 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m38GUY6c026641; Tue, 8 Apr 2008 16:30:34 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Apr 2008 18:30:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Apr 2008 18:30:24 +0200 Message-ID: In-Reply-To: <014101c89954$847a9db0$ac4c460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] White-List and Black-List definition thread-index: AciZVJW3ueV2QvAMRPqTau4atBDyIwAP+AQg References: <014101c89954$847a9db0$ac4c460a@china.huawei.com> From: "Wojciech Dec (wdec)" To: "Tina TSOU" , X-OriginalArrivalTime: 08 Apr 2008 16:30:34.0628 (UTC) FILETIME=[DEBEC440:01C89995] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1428; t=1207672234; x=1208536234; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20[ANCP]=20White-List=20and=20Black-List= 20definition |Sender:=20; bh=Ad9dgAA3KKAWqhCUKQl8lSmH+7E5aQKpdYXXBgqAjFY=; b=rA2Z+xk1XommPXUgAYAEmP5HZ3JsuE51Vq+Q+VHGGLY1SE2HeL6XckecHO ONdxozlmQ7mqnWmHZE+aj2luvyqVwVGaTnORmFch4HjQPjvfFijnpB/qbELt T6KdxNRDb+; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [ANCP] White-List and Black-List definition X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hi Tina, the point you raise indeed still needs to be addressed on two fronts: i) The definition, modification and execution strategy of the various lists on the access-node needs to be more tightly defined (this is a personal opinion). This should happen in the framework draft. ii) The message format for the lists needs to be defined and placed in the protocol draft. The design team will tackle this after they complete in order of priority; multicast control (solicited/unsolicited); Reporting; List configuration; Flow grouping. Throughout we welcome proposals from you and the rest of the WG. Regards, Woj. ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Tina TSOU Sent: 08 April 2008 01:43 To: ancp@ietf.org Subject: Re: [ANCP] White-List and Black-List definition Hi Woj, http://www.ietf.org/mail-archive/web/ancp/current/msg00543.html Thank you for your reply. It describes the concept, not the specific definition. It says that white/black/grey list use line configuration message expansion to implement; I guess the main content of white/black/grey list is below: the program ordered by user, the program corresponding group IP, order program purview. I did not see the complete message format for it. Would you like to give me a hint where it is? B. R. Tina _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Apr 9 01:15:04 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B2E53A6BDC; Wed, 9 Apr 2008 01:15:04 -0700 (PDT) X-Original-To: ancp@ietf.org Delivered-To: ancp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0DC783A6BDC; Wed, 9 Apr 2008 01:15:02 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080409081503.0DC783A6BDC@core3.amsl.com> Date: Wed, 9 Apr 2008 01:15:02 -0700 (PDT) Cc: ancp@ietf.org Subject: [ANCP] I-D Action:draft-ietf-ancp-security-threats-04.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access Node Control Protocol Working Group of the IETF. Title : Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) Author(s) : H. Moustafa, et al. Filename : draft-ietf-ancp-security-threats-04.txt Pages : 16 Date : 2008-04-09 The Access Node Control Protocol (ANCP) aims to communicate QoS- related, service-related and subscriber-related configurations and operations between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)). The main goal of this protocol is to allow the NAS to configure, manage and control access equipments including the ability for the access nodes to report information to the NAS. The present document investigates security threats that all ANCP nodes could encounter. This document develops a threat model for ANCP security aiming to decide which security functions are required. Based on this, security requirements regarding the Access Node Control Protocol are defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-security-threats-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ancp-security-threats-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-09010425.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --NextPart-- From ancp-bounces@ietf.org Wed Apr 9 02:15:03 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B12528C1D9; Wed, 9 Apr 2008 02:15:03 -0700 (PDT) X-Original-To: ancp@ietf.org Delivered-To: ancp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 61CA43A6BF8; Wed, 9 Apr 2008 02:15:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080409091501.61CA43A6BF8@core3.amsl.com> Date: Wed, 9 Apr 2008 02:15:01 -0700 (PDT) Cc: ancp@ietf.org Subject: [ANCP] I-D Action:draft-ietf-ancp-security-threats-05.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access Node Control Protocol Working Group of the IETF. Title : Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) Author(s) : H. Moustafa, et al. Filename : draft-ietf-ancp-security-threats-05.txt Pages : 16 Date : 2008-04-09 The Access Node Control Protocol (ANCP) aims to communicate QoS- related, service-related and subscriber-related configurations and operations between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)). The main goal of this protocol is to allow the NAS to configure, manage and control access equipments including the ability for the access nodes to report information to the NAS. The present document investigates security threats that all ANCP nodes could encounter. This document develops a threat model for ANCP security aiming to decide which security functions are required. Based on this, security requirements regarding the Access Node Control Protocol are defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-security-threats-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ancp-security-threats-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-09021258.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --NextPart-- From ancp-bounces@ietf.org Mon Apr 14 08:00:51 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD1B63A6CF0; Mon, 14 Apr 2008 08:00:51 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C48963A6CC4 for ; Mon, 14 Apr 2008 08:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6oZbCF1yxNl for ; Mon, 14 Apr 2008 08:00:48 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D61BD28C1CD for ; Mon, 14 Apr 2008 08:00:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,655,1199660400"; d="scan'208";a="6233621" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 14 Apr 2008 17:00:35 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3EF0ZPs006483; Mon, 14 Apr 2008 17:00:35 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3EF0ZVD020412; Mon, 14 Apr 2008 15:00:35 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Apr 2008 17:00:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Apr 2008 17:00:26 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANCP Multicast Control Message thread-index: AcieEVmGGiNqxJsfTu6YY/jux+SZrwALfVfQ From: "Wojciech Dec (wdec)" To: X-OriginalArrivalTime: 14 Apr 2008 15:00:35.0579 (UTC) FILETIME=[4B23C4B0:01C89E40] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7820; t=1208185235; x=1209049235; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20ANCP=20Multicast=20Control=20Message |Sender:=20; bh=hy4oL8Y8KMaKXuH+xBbKCAJs++xeYCL68TRZJY00tIE=; b=fMpBGtBJ50+PW1hf4Or7zjf4palO3p6A+HuCtb3JnxV/9MAn01AB/ZAjem WZBZUZCOE2xabL8Ilus8p0W6xBhAHfnNBVltvSujIC3ocEMveMIWt3zej8c2 jAAqe5rZZo; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [ANCP] ANCP Multicast Control Message X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hi All, As discussed during our recent IETF 71 meeting, our protocol design team has forged ahead with prioritized list of problems to address, the first of which was defining the ANCP message extensions for multicast control, aka unsolicited multicast control. The DT is working on the response message and also the solicited multicast control mode. Below, we present the outcome of the work, which represents both a design team consensus as well as a proposal for adoption into the ANCP protocol spec, draft-ietf-ancp-protocol (some editorial work will be still required). Please review the proposal and share your comments. We will assume acceptance of the proposal in principle otherwise. Regards, Woj & Matthew. 2 Replication Control Message This message is sent by the ANCP Server (NAS) to the ANCP Client (AN) with a directive to either add (join) or delete (leave) a port to or from a multicast flow. Its format is as follow: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=Replication-Control (0x01)| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 (Access-Loop-Circuit-ID) | Client-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Port Client-ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Following the Port Client-ID information, one or more Command TLV components can be included and the Access Node should process them in the order in which they are listed. The Access Node (ANCP Client) should threat all the commands as a single command block to be viewed as a whole and bail out immediately when one of them fails. The format of command TLV is as follow: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = CommandCode | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Multicast Group Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Multicast Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where CommandCode specifies the command and can be one of the following: 0x01 Add Adds the specified multicast flow to the specified port (join) 0x02 Delete Deletes the specified multicast flow (leave) on the specified port. 0x04 DeleteAll Deletes All multicast flow on the specified port (leave all). No addresses are supplied. When we have more than one command, Deletes should always be listed first. The unicast source address/mask follows the format defined in RFC 2362 Section 4.1 case 1 which is duplicated here for quick review: Encoded-Unicast-address: Takes the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Unicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Addr Family The address family of the `Unicast Address' field of this address. Here is the address family numbers assigned by IANA: Number Description -------- --------------------------------------------------------- 0 Reserved 1 IP (IP version 4) 2 IP6 (IP version 6) 3 NSAP 4 HDLC (8-bit multidrop) 5 BBN 1822 6 802 (includes all 802 media plus Ethernet "canonical format") 7 E.163 8 E.164 (SMDS, Frame Relay, ATM) 9 F.69 (Telex) 10 X.121 (X.25, Frame Relay) 11 IPX 12 Appletalk 13 Decnet IV 14 Banyan Vines 15 E.164 with NSAP format subaddress Encoding Type The type of encoding used within a specific Address Family. The value `0' is reserved for this field, and represents the native encoding of the Address Family. Unicast Address The unicast address as represented by the given Address Family and Encoding Type. Finally, although the length could be derived from the Addr Family and the Encoding type, it is kept for future possible extension to this command where other entry would be added to this command segment. The equivalent of a swap command where the NAS would want to switch from multicast group 239.23.2.2 to 239.55.3.2 will have the following format: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x88-0C) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub |MessageType=90 | Result| Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier = 0001 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 (Replication-Control) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 (Access-Loop-Circuit-ID) | Client-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Port Client-ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=CommandCode: Delete(0x02)| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast group: 239.23.2.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | AddrFamily 01 | EncType 0x0 | Mcast Source: 10.1.1.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | Type=CommandCode: Add (0x01) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast group: 239.55.3.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | AddrFamily 01 | EncType 0x0 | Mcast Source: 10.1.1.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| Each command in the list is attributed an identification number based on its occurrence in the message. In this case, the Delete command will be attributed command number 1 while the Add will be attributed command number 2. During the processing of these commands, upon the first failure of a command, the sequence is interrupted and an error message (via Multicast Status Message) will be returned with the command number identifying the command that failed. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Apr 16 07:43:45 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95EE33A6B08; Wed, 16 Apr 2008 07:43:45 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A98063A6A1C for ; Wed, 16 Apr 2008 07:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.477 X-Spam-Level: X-Spam-Status: No, score=-0.477 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994, SARE_UNSUB18=0.131] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGOao5dK4bP5 for ; Wed, 16 Apr 2008 07:43:42 -0700 (PDT) Received: from wipro-blr-out01.wipro.com (wipro-blr-out01.wipro.com [203.91.198.74]) by core3.amsl.com (Postfix) with ESMTP id B54793A6B08 for ; Wed, 16 Apr 2008 07:43:41 -0700 (PDT) X-AuditID: cb5bdd57-a9a4abb000002981-a1-480610bfb80e Received: from blr-ec-bh02.wipro.com (unknown [10.201.50.92]) by wipro-blr-out01.wipro.com (Symantec Mail Security) with ESMTP id B4ECB4E4003 for ; Wed, 16 Apr 2008 20:14:15 +0530 (IST) Received: from BLR-EC-MBX07.wipro.com ([10.201.52.182]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Apr 2008 20:14:15 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Apr 2008 20:11:24 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANCP Multicast Control Message Thread-Index: AcieEVmGGiNqxJsfTu6YY/jux+SZrwALfVfQAGQoukU= References: From: To: , X-OriginalArrivalTime: 16 Apr 2008 14:44:15.0356 (UTC) FILETIME=[57B51BC0:01C89FD0] X-Brightmail-Tracker: AAAAAA== Subject: Re: [ANCP] ANCP Multicast Control Message X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0419084556==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0419084556== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89FD0.57A94448" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89FD0.57A94448 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Woj, Currently, the command codes for replication control message are 1. add (0x01) 2. delete (0x02) 3. delete all (0x04). =20 Looking at the multicast Swap message format, which is used when the NAS = wants to switch from one group to another,can we not handle this = situation by having a message type Modify (0x08). By using this message type we can mention the multicast group address = which needs to be swapped by new multicast group address. Since the Command Code is 2 bytes, the second byte can be used to = mention the number of multicast groups that needs to be swapped. This will allow, for multiple multicast group swaps. This will also = reduce the size of the packet. Since these messages intended only = between the NAS and AN, the introduction of modify command type gives = further ease to the Access boxes in implementing the swaps, which = attributes to zap latency. =20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x88-0C) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub |MessageType=3D90 | Result| Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier =3D 0001 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 (Replication-Control) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 (Access-Loop-Circuit-ID) | Client-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Port Client-ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=3DCommandCode: Modify(0x08)| Length = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast group: 239.23.2.2 = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | AddrFamily 01 | EncType 0x0 | Mcast Source: 10.1.1.1 = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | AddrFamily 01 | EncType 0x0 | New Mcast group: 239.55.3.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | AddrFamily 01 | EncType 0x0 | New Mcast Source: 10.1.1.1 = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| =20 Looking into the DSL TR 101, it also discusses about the multicast flow = being associated with a VLAN (Multicast-Vlan). In this case, the Access = Node, needs to be informed about the VLAN ID on which a particular = Multicast group is being associated by the NAS. Can this information = also be added as part of the TLV in message. =20 Thanks Vish ________________________________ From: ancp-bounces@ietf.org on behalf of Wojciech Dec (wdec) Sent: Mon 4/14/2008 11:00 AM To: ancp@ietf.org Subject: [ANCP] ANCP Multicast Control Message Hi All, As discussed during our recent IETF 71 meeting, our protocol design team has forged ahead with prioritized list of problems to address, the first of which was defining the ANCP message extensions for multicast control, aka unsolicited multicast control. The DT is working on the response message and also the solicited multicast control mode. Below, we present the outcome of the work, which represents both a design team consensus as well as a proposal for adoption into the ANCP protocol spec, draft-ietf-ancp-protocol (some editorial work will be still required). Please review the proposal and share your comments. We will assume acceptance of the proposal in principle otherwise. Regards, Woj & Matthew. 2 Replication Control Message This message is sent by the ANCP Server (NAS) to the ANCP Client (AN) with a directive to either add (join) or delete (leave) a port to or from a multicast flow. Its format is as follow: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=3DReplication-Control (0x01)| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 (Access-Loop-Circuit-ID) | Client-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Port Client-ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Following the Port Client-ID information, one or more Command TLV components can be included and the Access Node should process them in the order in which they are listed. The Access Node (ANCP Client) should threat all the commands as a single command block to be viewed as a whole and bail out immediately when one of them fails. The format of command TLV is as follow: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D CommandCode | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Multicast Group Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Multicast Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where CommandCode specifies the command and can be one of the following: 0x01 Add Adds the specified multicast flow to the specified port (join) 0x02 Delete Deletes the specified multicast flow (leave) on the specified port. 0x04 DeleteAll Deletes All multicast flow on the specified port (leave all). No addresses are supplied. When we have more than one command, Deletes should always be listed first. The unicast source address/mask follows the format defined in RFC 2362 Section 4.1 case 1 which is duplicated here for quick review: Encoded-Unicast-address: Takes the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Unicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Addr Family The address family of the `Unicast Address' field of this address. Here is the address family numbers assigned by IANA: Number Description -------- --------------------------------------------------------- 0 Reserved 1 IP (IP version 4) 2 IP6 (IP version 6) 3 NSAP 4 HDLC (8-bit multidrop) 5 BBN 1822 6 802 (includes all 802 media plus Ethernet "canonical format") 7 E.163 8 E.164 (SMDS, Frame Relay, ATM) 9 F.69 (Telex) 10 X.121 (X.25, Frame Relay) 11 IPX 12 Appletalk 13 Decnet IV 14 Banyan Vines 15 E.164 with NSAP format subaddress Encoding Type The type of encoding used within a specific Address Family. The value `0' is reserved for this field, and represents the native encoding of the Address Family. Unicast Address The unicast address as represented by the given Address Family and Encoding Type. Finally, although the length could be derived from the Addr Family and the Encoding type, it is kept for future possible extension to this command where other entry would be added to this command segment. The equivalent of a swap command where the NAS would want to switch from multicast group 239.23.2.2 to 239.55.3.2 will have the following format: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x88-0C) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub |MessageType=3D90 | Result| Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier =3D 0001 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 (Replication-Control) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 (Access-Loop-Circuit-ID) | Client-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Port Client-ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=3DCommandCode: Delete(0x02)| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast group: 239.23.2.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | AddrFamily 01 | EncType 0x0 | Mcast Source: 10.1.1.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | Type=3DCommandCode: Add (0x01) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast group: 239.55.3.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | AddrFamily 01 | EncType 0x0 | Mcast Source: 10.1.1.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| Each command in the list is attributed an identification number based on its occurrence in the message. In this case, the Delete command will be attributed command number 1 while the Add will be attributed command number 2. During the processing of these commands, upon the first failure of a command, the sequence is interrupted and an error message (via Multicast Status Message) will be returned with the command number identifying the command that failed. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp ------_=_NextPart_001_01C89FD0.57A94448 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [ANCP] ANCP Multicast Control = Message=0A= =0A= =0A= =0A=
=0A=
=0A=

Hi Woj,

=0A=

Currently, the command codes for replication control = message are

=0A=

1. add (0x01)

=0A=

2. delete (0x02)

=0A=

3. delete all (0x04).

=0A=

 

=0A=

Looking at the multicast Swap message format, which = is used when the NAS wants to switch from one group to = another,can we not handle = this situation by having a message type Modify (0x08).

=0A=

By using this message type we can mention the = multicast group address which needs to be swapped by new multicast group = address.

=0A=

Since the Command Code is 2 bytes, the second byte = can be used to mention the number of multicast groups that needs to be = swapped.

=0A=

This will allow, for multiple multicast group swaps. = This will also reduce the size of the packet. Since these messages = intended only between the NAS and AN, the introduction of modify command = type gives further ease to the Access boxes in implementing the swaps, = which attributes to zap latency.

=0A=

 

=0A=

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    |        Type = (0x88-0C)         = |           = Length           &= nbsp;  |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    | Vers  |  Sub  |MessageType=3D90 | = Result|        = Code           = |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    | Partition ID  = |            = Transaction Identifier =3D 0001      = |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    |I|      SubMessage = Number      = |           = Length           &= nbsp;  |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    | 0x01 (Replication-Control)    = |            = = Length            = |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    | 0x01 (Access-Loop-Circuit-ID) = |        Client-ID = Length       |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    = |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;  |
     = ~            =           Port = Client-ID          &nbs= p;            = ;    ~
     = |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;  |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    | Type=3DCommandCode: = Modify(0x08)|        &nb= sp;  = Length           &= nbsp;           &n= bsp;   |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    | AddrFamily 01 | EncType 0x0    = |  Mcast group: = 239.23.2.2           =  |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
&nbs= p;    | AddrFamily 01 | EncType 0x0    = |  Mcast Source: = 10.1.1.1           = ;    |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
&nbs= p;     | AddrFamily 01 | EncType = 0x0   |  New Mcast group: 239.55.3.2   = |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|=
     | AddrFamily 01 | EncType = 0x0    |  New Mcast Source: = 10.1.1.1  =     |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|<= /SPAN>

=0A=

 

=0A=

Looking into the DSL TR 101, it also discusses about = the multicast flow being associated with a VLAN (Multicast-Vlan). In = this case, the Access Node, needs to be informed about the VLAN ID on = which a particular Multicast group is being associated by the NAS. Can = this information also be added as part of the TLV in message.

=0A=

 

=0A=

Thanks

=0A=

Vish

=0A=

=0A=
=0A= From: ancp-bounces@ietf.org on = behalf of Wojciech Dec (wdec)
Sent: Mon 4/14/2008 11:00 = AM
To: ancp@ietf.org
Subject: [ANCP] ANCP Multicast = Control Message

=0A=

=0A=

Hi All,

As discussed during our recent IETF 71 = meeting, our protocol design team
has forged ahead with prioritized = list of problems to address, the first
of which was defining the ANCP = message extensions for multicast control,
aka unsolicited multicast = control. The DT is working on the response
message and also the = solicited multicast control mode.
Below, we present the outcome of = the work, which represents both a
design team consensus as well as a = proposal for adoption into the ANCP
protocol spec, = draft-ietf-ancp-protocol (some editorial work will be
still = required). Please review the proposal and share your comments. = We
will assume acceptance of the proposal in principle = otherwise.

Regards,
Woj & = Matthew.


2       Replication = Control Message


This message is sent by the ANCP Server (NAS) = to the ANCP Client (AN)
with a directive to either add (join) or = delete (leave) a port to or
from a multicast flow. Its format is as = follow:
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 = 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    |Type=3DReplication-Control = (0x01)|           =   = Length            = |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    | 0x01 (Access-Loop-Circuit-ID) = |        Client-ID = Length       |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    = |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;  |
     = ~            =           Port = Client-ID          &nbs= p;            = ;    ~
     = |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;  |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

= Following the Port Client-ID information, one or more Command = TLV
components can be included and the Access Node should process = them in
the order in which they are listed. The Access Node (ANCP = Client) should
threat all the commands as a single command block to = be viewed as a
whole and bail out immediately when one of them = fails.
The format of command TLV is as = follow:

      = 0            =        = 1            =        = 2            =        3
      = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    |  Type =3D = CommandCode           = |          = Length           &= nbsp;   |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    | Addr Family   | Encoding Type |  = Multicast Group Address      = |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    | Addr Family   | Encoding Type |  = Multicast Source Address     = |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

= Where CommandCode specifies the command and can be one of the = following:

0x01  Add       = Adds the specified multicast flow to the specified = port
(join)
0x02  Delete    Deletes the = specified multicast flow (leave) on the
specified port.
0x04  = DeleteAll Deletes All multicast flow on the specified port = (leave
all). No addresses are supplied.

When we have more than = one command, Deletes should always be listed
first. The unicast = source address/mask follows the format defined in RFC
2362 Section = 4.1 case 1 which is duplicated here for quick = review:

Encoded-Unicast-address: Takes the following = format:

  = 0            =        = 1            =        = 2            =        3
  0 1 2 3 4 5 6 7 8 9 0 1 = 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+
 | Addr Family   | Encoding Type = |     Unicast = Address           = |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+

     Addr = Family
           = The address family of the `Unicast Address' field  = of
           this = address.

          = Here is the address family numbers assigned by = IANA:

 Number    = Description
 --------  = ---------------------------------------------------------
  =     0    = Reserved
      1    IP (IP = version 4)
      2    IP6 (IP = version 6)
      3    = NSAP
      4    HDLC (8-bit = multidrop)
      5    BBN = 1822
      6    802 (includes = all 802 media plus Ethernet "canonical = format")
      7    = E.163
      8    E.164 (SMDS, = Frame Relay, ATM)
      9    = F.69 (Telex)
     10    X.121 = (X.25, Frame Relay)
     11    = IPX
     12    = Appletalk
     13    Decnet = IV
     14    Banyan = Vines
     15    E.164 with NSAP = format subaddress

     Encoding = Type
          The type = of encoding used within a specific = Address
          = Family.  The value `0' is reserved for this = field,
          and = represents the native encoding of the = Address
          = Family.

     Unicast = Address
          The = unicast address as represented by the = given
          Address = Family and Encoding Type.

Finally, although the length could be = derived from the Addr Family and
the Encoding type, it is kept for = future possible extension to this
command where other entry would be = added to this command segment.
The equivalent of a swap command where = the NAS would want to switch from
multicast group 239.23.2.2 to = 239.55.3.2 will have the following = format:

      0 1 2 3 4 5 6 7 8 9 0 1 2 = 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    |        Type = (0x88-0C)         = |           = Length           &= nbsp;  |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    | Vers  |  Sub  |MessageType=3D90 | = Result|        = Code           = |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    | Partition ID  = |            = Transaction Identifier =3D 0001      = |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    |I|      SubMessage = Number      = |           = Length           &= nbsp;  |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    | 0x01 (Replication-Control)    = |            = = Length            = |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    | 0x01 (Access-Loop-Circuit-ID) = |        Client-ID = Length       |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    = |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;  |
     = ~            =           Port = Client-ID          &nbs= p;            = ;    ~
     = |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;  |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    | Type=3DCommandCode: = Delete(0x02)|          = = Length           &= nbsp;  |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    | AddrFamily 01 | EncType 0x0   |  = Mcast group: 239.23.2.2      = |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
&nbs= p;    | AddrFamily 01 | EncType 0x0   |  = Mcast Source: 10.1.1.1       = |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
&nbs= p;    | Type=3DCommandCode: Add (0x01)  = |           = Length           &= nbsp;  |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    | AddrFamily 01 | EncType 0x0   |  = Mcast group: 239.55.3.2      = |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
&nbs= p;    | AddrFamily 01 | EncType 0x0   |  = Mcast Source: 10.1.1.1       = |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|

= Each command in the list is attributed an identification number based = on
its occurrence in the message. In this case, the Delete command = will be
attributed command number 1 while the Add will be attributed = command
number 2. During the processing of these  commands, upon = the first
failure of a command, the sequence is interrupted and an = error message
(via Multicast Status Message) will be returned with = the command number
identifying the command that = failed.

_______________________________________________
ANCP = mailing list
ANCP@ietf.org
https://www.ietf.org/= mailman/listinfo/ancp

------_=_NextPart_001_01C89FD0.57A94448-- --===============0419084556== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============0419084556==-- From ancp-bounces@ietf.org Fri Apr 18 08:04:13 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E82013A696F; Fri, 18 Apr 2008 08:04:12 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D93943A68B2 for ; Fri, 18 Apr 2008 08:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PFKcWXKW2yV for ; Fri, 18 Apr 2008 08:04:11 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 7DA263A6A91 for ; Fri, 18 Apr 2008 08:04:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,677,1199660400"; d="scan'208,217";a="6710488" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 18 Apr 2008 17:04:02 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3IF42Eq032285 for ; Fri, 18 Apr 2008 17:04:02 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3IF42lM029998 for ; Fri, 18 Apr 2008 15:04:02 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Apr 2008 17:04:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 18 Apr 2008 17:03:48 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Bulk Transaction Message thread-index: AcihZWeDZVeOVtxMS1uttRBEffcNEw== From: "Wojciech Dec (wdec)" To: X-OriginalArrivalTime: 18 Apr 2008 15:04:02.0652 (UTC) FILETIME=[703799C0:01C8A165] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1326; t=1208531042; x=1209395042; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20Bulk=20Transaction=20Message |Sender:=20; bh=42gXoEiezv68WrVtVqs7CpWoaxmkKDezl/zxI/GBGHo=; b=lcAn5BSdsc568m908oYbAbihuYcrO81YXpdZzc/1xuf4GmeIrxK2AlV4tg pt1Q1LxbKffgWMVGp0fcLYJbhCDbe8WhG9Uizs6SJusUaS+Ah1pqjisMOple 6o0oEBJpSn; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [ANCP] Bulk Transaction Message X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0182581009==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0182581009== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A165.700CB723" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A165.700CB723 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, Could you please let me/us know if you currently have an implementation of ANCP that supports the Bulk Transaction Capability and Message? Thanks, Woj. ------_=_NextPart_001_01C8A165.700CB723 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bulk Transaction Message

Hi = Folks,

Could you please = let me/us know if you currently have an implementation of ANCP that = supports the Bulk Transaction Capability and Message?

Thanks,
Woj.

------_=_NextPart_001_01C8A165.700CB723-- --===============0182581009== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============0182581009==-- From ancp-bounces@ietf.org Fri Apr 18 18:07:33 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA9033A6CC8; Fri, 18 Apr 2008 18:07:32 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF2213A67FC for ; Fri, 18 Apr 2008 18:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIbzBJQa-lMe for ; Fri, 18 Apr 2008 18:07:27 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id DF3333A6AC6 for ; Fri, 18 Apr 2008 18:07:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id C22B24914CE; Fri, 18 Apr 2008 18:07:30 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12813-04; Fri, 18 Apr 2008 18:07:30 -0700 (PDT) Received: from rbsjx.ad.redback.com (rbsjxh1.redback.com [155.53.14.105]) by prattle.redback.com (Postfix) with ESMTP id 9F6E14914CD; Fri, 18 Apr 2008 18:07:30 -0700 (PDT) Received: from RBSJX.ad.redback.com ([155.53.14.103]) by rbsjxh1.ad.redback.com ([155.53.14.105]) with mapi; Fri, 18 Apr 2008 18:07:30 -0700 From: Peter Arberg To: "Wojciech Dec (wdec)" , "ancp@ietf.org" Date: Fri, 18 Apr 2008 18:07:29 -0700 Thread-Topic: [ANCP] Bulk Transaction Message Thread-Index: AcihZWeDZVeOVtxMS1uttRBEffcNEwAVDjfg Message-ID: <48C276B536524E478C659685995F6AA539DBA2CA93@RBSJX.ad.redback.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at redback.com Subject: Re: [ANCP] Bulk Transaction Message X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1321386099==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org --===============1321386099== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_48C276B536524E478C659685995F6AA539DBA2CA93RBSJXadredbac_" --_000_48C276B536524E478C659685995F6AA539DBA2CA93RBSJXadredbac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Woj, can you give a little background to why you are looking for vendor implementation support for this specific capability & message ? thanks, Peter ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Woj= ciech Dec (wdec) Sent: 18. april 2008 08:04 To: ancp@ietf.org Subject: [ANCP] Bulk Transaction Message Hi Folks, Could you please let me/us know if you currently have an implementation of = ANCP that supports the Bulk Transaction Capability and Message? Thanks, Woj. --_000_48C276B536524E478C659685995F6AA539DBA2CA93RBSJXadredbac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bulk Transaction Message
Hi Woj,
 
can you give a little background to why you are lo= oking for=20 vendor
implementation support for this specific capabilit= y &=20 message ?
 
thanks,
Peter

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec=20 (wdec)
Sent: 18. april 2008 08:04
To:=20 ancp@ietf.org
Subject: [ANCP] Bulk Transaction=20 Message

Hi Folks,=

Could you please let me= /us know if=20 you currently have an implementation of ANCP that supports the Bulk=20 Transaction Capability and Message?

Thanks, <= BR>Woj.=20

--_000_48C276B536524E478C659685995F6AA539DBA2CA93RBSJXadredbac_-- --===============1321386099== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============1321386099==-- From ancp-bounces@ietf.org Sun Apr 20 05:42:13 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC89328C1E6; Sun, 20 Apr 2008 05:42:13 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F296B28C1E6 for ; Sun, 20 Apr 2008 05:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUMh5rUUzy0o for ; Sun, 20 Apr 2008 05:42:12 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 847093A6E8A for ; Sun, 20 Apr 2008 05:42:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,685,1199660400"; d="scan'208,217";a="6787735" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Apr 2008 14:42:10 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3KCgAgc026187; Sun, 20 Apr 2008 14:42:10 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3KCgAGk004043; Sun, 20 Apr 2008 12:42:10 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Apr 2008 14:42:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 20 Apr 2008 14:38:45 +0200 Message-ID: In-Reply-To: <48C276B536524E478C659685995F6AA539DBA2CA93@RBSJX.ad.redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Bulk Transaction Message thread-index: AcihZWeDZVeOVtxMS1uttRBEffcNEwAVDjfgAEod1tA= References: <48C276B536524E478C659685995F6AA539DBA2CA93@RBSJX.ad.redback.com> From: "Wojciech Dec (wdec)" To: "Peter Arberg" , X-OriginalArrivalTime: 20 Apr 2008 12:42:10.0349 (UTC) FILETIME=[F350BDD0:01C8A2E3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5472; t=1208695330; x=1209559330; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20[ANCP]=20Bulk=20Transaction=20Message |Sender:=20; bh=nd98aiHhJLAGmCAzhzTUPQSLSl55oj9KxX/iONPDnyg=; b=e+EZHHDqHtxHBFwP1ESYWOViKM6VWs8RiI63yDRZ0NVV6Hyqf2Gz+8MaFw oNP1uTkuW8x3/HzwTeONGoOcuoTD6tMpoXXceXU0/7+tIn+lPfA3pKczNZLp 4+sYuaugec; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [ANCP] Bulk Transaction Message X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1696425545==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1696425545== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A2E3.F30C96CE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A2E3.F30C96CE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It's all simple: - the Design Team is looking at the possibility of using this message - the message in its current form does not appear to be terribly useful, and could be removed from the spec. =20 -Woj. =20 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Peter Arberg Sent: 19 April 2008 03:07 To: Wojciech Dec (wdec); ancp@ietf.org Subject: Re: [ANCP] Bulk Transaction Message =09 =09 Hi Woj, =20 can you give a little background to why you are looking for vendor implementation support for this specific capability & message ? =20 thanks, Peter ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: 18. april 2008 08:04 To: ancp@ietf.org Subject: [ANCP] Bulk Transaction Message =09 =09 Hi Folks,=20 Could you please let me/us know if you currently have an implementation of ANCP that supports the Bulk Transaction Capability and Message? Thanks,=20 Woj.=20 ------_=_NextPart_001_01C8A2E3.F30C96CE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bulk Transaction Message
It's all simple:
- the Design Team is looking at the possibility of using = this=20 message
-=20 the message in its current form does not appear to be terribly useful, = and could=20 be removed from the spec.
 
-Woj.
 

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Peter=20 Arberg
Sent: 19 April 2008 03:07
To: Wojciech Dec = (wdec);=20 ancp@ietf.org
Subject: Re: [ANCP] Bulk Transaction=20 Message

Hi Woj,
 
can you give a little background to why you = are looking=20 for vendor
implementation support for this specific = capability &=20 message ?
 
thanks,
Peter

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec=20 (wdec)
Sent: 18. april 2008 08:04
To:=20 ancp@ietf.org
Subject: [ANCP] Bulk Transaction=20 Message

Hi = Folks,

Could you please = let me/us know=20 if you currently have an implementation of ANCP that supports the = Bulk=20 Transaction Capability and Message?

Thanks,
Woj.

------_=_NextPart_001_01C8A2E3.F30C96CE-- --===============1696425545== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============1696425545==-- From ancp-bounces@ietf.org Sun Apr 20 06:18:11 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17B8C3A688F; Sun, 20 Apr 2008 06:18:11 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E7A83A6866 for ; Sun, 20 Apr 2008 06:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-75NHhlAKIE for ; Sun, 20 Apr 2008 06:18:09 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 857623A6AC0 for ; Sun, 20 Apr 2008 06:18:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,685,1199660400"; d="scan'208,217";a="6788490" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Apr 2008 15:18:09 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3KDI9ta003526; Sun, 20 Apr 2008 15:18:09 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3KDI9pk009696; Sun, 20 Apr 2008 13:18:09 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Apr 2008 15:18:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 20 Apr 2008 15:18:04 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Bulk Transaction Message thread-index: AcihZWeDZVeOVtxMS1uttRBEffcNEwAVDjfgAEod1tAAAWRvoA== References: <48C276B536524E478C659685995F6AA539DBA2CA93@RBSJX.ad.redback.com> From: "Wojciech Dec (wdec)" To: "Peter Arberg" , X-OriginalArrivalTime: 20 Apr 2008 13:18:09.0489 (UTC) FILETIME=[FA435C10:01C8A2E8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7328; t=1208697489; x=1209561489; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20[ANCP]=20Bulk=20Transaction=20Message |Sender:=20; bh=bBTa6wIYnZMBoPVs13xflTAqxi84wvpI1D8Jjma47IQ=; b=aPcjTMb2FInzhBV+meCQBhaX8isQ/DrMegF9Vo1JO3GBQk2WI1LFZv11te pvryRcZlLLypk9GHs0axCY48h19fCX5G2j76CWKshjVJbFX7w8Uf+TW1VULt 8Jd54tRr/Y; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [ANCP] Bulk Transaction Message X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1443684517==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1443684517== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A2E8.F9FE4BDF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A2E8.F9FE4BDF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Should also have added: Given that currently the bulk message does not appear to have had any practical adoption, having the DTeam adopt it/modify it, or possibly have it removed from the spec all together are all valid options. =20 -Woj. ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: 20 April 2008 14:39 To: Peter Arberg; ancp@ietf.org Subject: Re: [ANCP] Bulk Transaction Message =09 =09 It's all simple: - the Design Team is looking at the possibility of using this message - the message in its current form does not appear to be terribly useful, and could be removed from the spec. =20 -Woj. =20 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Peter Arberg Sent: 19 April 2008 03:07 To: Wojciech Dec (wdec); ancp@ietf.org Subject: Re: [ANCP] Bulk Transaction Message =09 =09 Hi Woj, =20 can you give a little background to why you are looking for vendor implementation support for this specific capability & message ? =20 thanks, Peter ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: 18. april 2008 08:04 To: ancp@ietf.org Subject: [ANCP] Bulk Transaction Message =09 =09 Hi Folks,=20 Could you please let me/us know if you currently have an implementation of ANCP that supports the Bulk Transaction Capability and Message? Thanks,=20 Woj.=20 ------_=_NextPart_001_01C8A2E8.F9FE4BDF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bulk Transaction Message
Should also have added: Given that currently the bulk = message does=20 not appear to have had any practical adoption, having the DTeam = adopt=20 it/modify it, or possibly have it removed from the spec all = together are=20 all valid options.
 
-Woj.

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec=20 (wdec)
Sent: 20 April 2008 14:39
To: Peter Arberg; = ancp@ietf.org
Subject: Re: [ANCP] Bulk Transaction=20 Message

It's all simple:
- the Design Team is looking at the possibility of using = this=20 message
- the message in its current form does not appear to be = terribly=20 useful, and could be removed from the spec.
 
-Woj.
 

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Peter=20 Arberg
Sent: 19 April 2008 03:07
To: Wojciech = Dec=20 (wdec); ancp@ietf.org
Subject: Re: [ANCP] Bulk Transaction = Message

Hi Woj,
 
can you give a little background to why you = are looking=20 for vendor
implementation support for this specific = capability=20 & message ?
 
thanks,
Peter

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec=20 (wdec)
Sent: 18. april 2008 08:04
To:=20 ancp@ietf.org
Subject: [ANCP] Bulk Transaction=20 Message

Hi = Folks,

Could you please = let me/us=20 know if you currently have an implementation of ANCP that supports = the=20 Bulk Transaction Capability and Message?

Thanks,=20
Woj. =

------_=_NextPart_001_01C8A2E8.F9FE4BDF-- --===============1443684517== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============1443684517==-- From ancp-bounces@ietf.org Sun Apr 20 08:12:24 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43EF73A6AB0; Sun, 20 Apr 2008 08:12:24 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B76B53A68C2 for ; Sun, 20 Apr 2008 08:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.871 X-Spam-Level: X-Spam-Status: No, score=-1.871 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_UNSUB18=0.131] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZywGlvzb0Zrf for ; Sun, 20 Apr 2008 08:12:10 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 1F7983A6850 for ; Sun, 20 Apr 2008 08:12:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,686,1199660400"; d="scan'208,217";a="6790444" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Apr 2008 17:12:10 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3KFCAHx011264; Sun, 20 Apr 2008 17:12:10 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3KFCAA8026654; Sun, 20 Apr 2008 15:12:10 GMT Received: from xmb-ams-336.cisco.com ([144.254.231.81]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Apr 2008 17:12:09 +0200 Received: from 10.82.248.215 ([10.82.248.215]) by xmb-ams-336.emea.cisco.com ([144.254.231.81]) with Microsoft Exchange Server HTTP-DAV ; Sun, 20 Apr 2008 15:12:09 +0000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Sun, 20 Apr 2008 16:12:04 +0100 From: einarnn To: , , Message-ID: Thread-Topic: [ANCP] ANCP Multicast Control Message Thread-Index: AcieEVmGGiNqxJsfTu6YY/jux+SZrwALfVfQAGQoukUAyjyKeQ== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 20 Apr 2008 15:12:09.0914 (UTC) FILETIME=[E77961A0:01C8A2F8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=37855; t=1208704330; x=1209568330; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=einarnn@cisco.com; z=From:=20einarnn=20 |Subject:=20Re=3A=20[ANCP]=20ANCP=20Multicast=20Control=20M essage |Sender:=20; bh=yBO9Hd2tkmg74CvZMdloK+SAmYirOUSBKTjPm+ltLx0=; b=NDG7TdCJDoZuK74N5feDQTJori3Bk4OlcMx+C8n3ZpYIaQJHe80LZuqRNR k85bkmd05Wfbm4lgzzsgKq1AebHYaVmCG44qlwdc0mD/3Mhr1fd9WzMAqdSy FhVKkb2j4R; Authentication-Results: ams-dkim-1; header.From=einarnn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [ANCP] ANCP Multicast Control Message X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0783702527==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0783702527== Content-type: multipart/alternative; boundary="B_3291552725_776548" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3291552725_776548 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Vish, Overloading the second byte of the command code to contain the number of =B3modifications=B2 doesn=B9t seem a good approach and the space saving per packet, which will probably be only 4 bytes most of the time, seems almost irrelevant. I think it would be better to keep the fields in the message fo= r a single task. Treating a sequence of commands as an atomic operation, as detailed in the text, and implementing a swap via a delete follow by an add, should give AN= s the freedom to implement what are, in effect, swap operations quite efficiently. In this context, I=B9m not sure what a =B3modify=B2 command code wil= l really add? Cheers, Einar On 16/04/2008 15:41, "vishwanathan.sundaram@wipro.com" wrote: > Hi Woj, > Currently, the command codes for replication control message are > 1. add (0x01) > 2. delete (0x02) > 3. delete all (0x04). > =20 > Looking at the multicast Swap message format, which is used when the NAS = wants > to switch from one group to another,can we not handle this situation by h= aving > a message type Modify (0x08). > By using this message type we can mention the multicast group address whi= ch > needs to be swapped by new multicast group address. > Since the Command Code is 2 bytes, the second byte can be used to mention= the > number of multicast groups that needs to be swapped. > This will allow, for multiple multicast group swaps. This will also reduc= e the > size of the packet. Since these messages intended only between the NAS an= d AN, > the introduction of modify command type gives further ease to the Access = boxes > in implementing the swaps, which attributes to zap latency. > =20 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type (0x88-0C) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vers | Sub |MessageType=3D90 | Result| Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Partition ID | Transaction Identifier =3D 0001 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |I| SubMessage Number | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0x01 (Replication-Control) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0x01 (Access-Loop-Circuit-ID) | Client-ID Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ Port Client-ID ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type=3DCommandCode: Modify(0x08)| Length > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AddrFamily 01 | EncType 0x0 | Mcast group: 239.23.2.2 = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > | AddrFamily 01 | EncType 0x0 | Mcast Source: 10.1.1.1 > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > | AddrFamily 01 | EncType 0x0 | New Mcast group: 239.55.3.2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > | AddrFamily 01 | EncType 0x0 | New Mcast Source: 10.1.1.1 = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > =20 > Looking into the DSL TR 101, it also discusses about the multicast flow b= eing > associated with a VLAN (Multicast-Vlan). In this case, the Access Node, n= eeds > to be informed about the VLAN ID on which a particular Multicast group is > being associated by the NAS. Can this information also be added as part o= f the > TLV in message. > =20 > Thanks > Vish >=20 >=20 > From: ancp-bounces@ietf.org on behalf of Wojciech Dec (wdec) > Sent: Mon 4/14/2008 11:00 AM > To: ancp@ietf.org > Subject: [ANCP] ANCP Multicast Control Message >=20 >=20 >=20 > Hi All, >=20 > As discussed during our recent IETF 71 meeting, our protocol design team > has forged ahead with prioritized list of problems to address, the first > of which was defining the ANCP message extensions for multicast control, > aka unsolicited multicast control. The DT is working on the response > message and also the solicited multicast control mode. > Below, we present the outcome of the work, which represents both a > design team consensus as well as a proposal for adoption into the ANCP > protocol spec, draft-ietf-ancp-protocol (some editorial work will be > still required). Please review the proposal and share your comments. We > will assume acceptance of the proposal in principle otherwise. >=20 > Regards, > Woj & Matthew. >=20 >=20 > 2 Replication Control Message >=20 >=20 > This message is sent by the ANCP Server (NAS) to the ANCP Client (AN) > with a directive to either add (join) or delete (leave) a port to or > from a multicast flow. Its format is as follow: > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Type=3DReplication-Control (0x01)| Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0x01 (Access-Loop-Circuit-ID) | Client-ID Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ Port Client-ID ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Following the Port Client-ID information, one or more Command TLV > components can be included and the Access Node should process them in > the order in which they are listed. The Access Node (ANCP Client) should > threat all the commands as a single command block to be viewed as a > whole and bail out immediately when one of them fails. > The format of command TLV is as follow: >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D CommandCode | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Addr Family | Encoding Type | Multicast Group Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Addr Family | Encoding Type | Multicast Source Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Where CommandCode specifies the command and can be one of the following: >=20 > 0x01 Add Adds the specified multicast flow to the specified port > (join) > 0x02 Delete Deletes the specified multicast flow (leave) on the > specified port. > 0x04 DeleteAll Deletes All multicast flow on the specified port (leave > all). No addresses are supplied. >=20 > When we have more than one command, Deletes should always be listed > first. The unicast source address/mask follows the format defined in RFC > 2362 Section 4.1 case 1 which is duplicated here for quick review: >=20 > Encoded-Unicast-address: Takes the following format: >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Addr Family | Encoding Type | Unicast Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Addr Family > The address family of the `Unicast Address' field of > this address. >=20 > Here is the address family numbers assigned by IANA: >=20 > Number Description > -------- --------------------------------------------------------- > 0 Reserved > 1 IP (IP version 4) > 2 IP6 (IP version 6) > 3 NSAP > 4 HDLC (8-bit multidrop) > 5 BBN 1822 > 6 802 (includes all 802 media plus Ethernet "canonical format") > 7 E.163 > 8 E.164 (SMDS, Frame Relay, ATM) > 9 F.69 (Telex) > 10 X.121 (X.25, Frame Relay) > 11 IPX > 12 Appletalk > 13 Decnet IV > 14 Banyan Vines > 15 E.164 with NSAP format subaddress >=20 > Encoding Type > The type of encoding used within a specific Address > Family. The value `0' is reserved for this field, > and represents the native encoding of the Address > Family. >=20 > Unicast Address > The unicast address as represented by the given > Address Family and Encoding Type. >=20 > Finally, although the length could be derived from the Addr Family and > the Encoding type, it is kept for future possible extension to this > command where other entry would be added to this command segment. > The equivalent of a swap command where the NAS would want to switch from > multicast group 239.23.2.2 to 239.55.3.2 will have the following format: >=20 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type (0x88-0C) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vers | Sub |MessageType=3D90 | Result| Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Partition ID | Transaction Identifier =3D 0001 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |I| SubMessage Number | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0x01 (Replication-Control) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0x01 (Access-Loop-Circuit-ID) | Client-ID Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ Port Client-ID ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type=3DCommandCode: Delete(0x02)| Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AddrFamily 01 | EncType 0x0 | Mcast group: 239.23.2.2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > | AddrFamily 01 | EncType 0x0 | Mcast Source: 10.1.1.1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > | Type=3DCommandCode: Add (0x01) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AddrFamily 01 | EncType 0x0 | Mcast group: 239.55.3.2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > | AddrFamily 01 | EncType 0x0 | Mcast Source: 10.1.1.1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| >=20 > Each command in the list is attributed an identification number based on > its occurrence in the message. In this case, the Delete command will be > attributed command number 1 while the Add will be attributed command > number 2. During the processing of these commands, upon the first > failure of a command, the sequence is interrupted and an error message > (via Multicast Status Message) will be returned with the command number > identifying the command that failed. >=20 > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp >=20 >=20 > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp --B_3291552725_776548 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [ANCP] ANCP Multicast Control Message Vish,

Overloading the second byte of the command code to contain the number of &#= 8220;modifications” doesn’t seem a good approach and the space s= aving per packet, which will probably be only 4 bytes most of the time, seem= s almost irrelevant. I think it would be better to keep the fields in the me= ssage for a single task.

Treating a sequence of commands as an atomic operation, as detailed in the = text, and implementing a swap via a delete follow by an add, should give ANs= the freedom to implement what are, in effect, swap operations quite efficie= ntly. In this context, I’m not sure what a “modify” comman= d code will really add?

Cheers,

Einar

On 16/04/2008 15:41, "vishwanathan.sundaram@wipro.com" <vishwa= nathan.sundaram@wipro.com> wrote:


Looking at the multicast Swap message format, which is us= ed when the NAS wants to switch from one group to another,can we not handle = this situation by having a message type Modify (0x08).
By using this message type we can mention the multicast group address which= needs to be swapped by new multicast group address.
Since the Command Code is 2 bytes, the second byte can be used to mention t= he number of multicast groups that needs to be swapped.
This will allow, for multiple multicast group swaps. This will also reduce = the size of the packet. Since these messages intended only between the NAS a= nd AN, the introduction of modify command type gives further ease to the Acc= ess boxes in implementing the swaps, which attributes to zap latency.
&n= bsp;    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     |        T= ype (0x88-0C)         |   =         Length    &nb= sp;         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | Vers  |  Sub  |MessageType=3D9= 0 | Result|        Code    = ;       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | Partition ID  |    &nbs= p;       Transaction Identifier =3D 0001 &n= bsp;    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     |I|      SubMessage = Number      |       &= nbsp;   Length        &nbs= p;     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | 0x01 (Replication-Control)   &nbs= p;|             = Length            |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | 0x01 (Access-Loop-Circuit-ID) |   = ;     Client-ID Length     &nbs= p; |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     |        &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;    |
     ~        &= nbsp;            = ; Port Client-ID          =             &nbs= p;    ~
     |        &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Type=3DCommandCode: Modify(0x08)| &nbs= p;         Length   &= nbsp;            = ;           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | AddrFamily 01 | EncType 0x0   &nb= sp;|  Mcast group: 239.23.2.2        = ;    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-|
     | AddrFamily 01 | EncType 0x0   &nb= sp;|  Mcast Source: 10.1.1.1        =        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-|
      | AddrFamily 01 | EncType 0x0  =  |  New Mcast group: 239.55.3.2   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-|
     | AddrFamily 01 | EncType 0x0   &nb= sp;|  New Mcast Source: 10.1.1.1      |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-|
Looking into the DSL TR 101, it also discusses about the = multicast flow being associated with a VLAN (Multicast-Vlan). In this case, = the Access Node, needs to be informed about the VLAN ID on which a particula= r Multicast group is being associated by the NAS. Can this information also = be added as part of the TLV in message.
Thanks
Vish

From: ancp-boun= ces@ietf.org on behalf of Wojciech Dec (wdec)
Sent: Mon 4/14/2008 11:00 AM
To: ancp@ietf.org
Subject: [ANCP] ANCP Multicast Control Message



Hi All,

As discussed during our recent IETF 71 meeting, our protocol design team has forged ahead with prioritized list of problems to address, the first of which was defining the ANCP message extensions for multicast control, aka unsolicited multicast control. The DT is working on the response
message and also the solicited multicast control mode.
Below, we present the outcome of the work, which represents both a
design team consensus as well as a proposal for adoption into the ANCP
protocol spec, draft-ietf-ancp-protocol (some editorial work will be
still required). Please review the proposal and share your comments. We
will assume acceptance of the proposal in principle otherwise.

Regards,
Woj & Matthew.


2       Replication Control Message


This message is sent by the ANCP Server (NAS) to the ANCP Client (AN)
with a directive to either add (join) or delete (leave) a port to or
from a multicast flow. Its format is as follow:
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9= 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     |Type=3DReplication-Control (0x01)|   = ;          Length  &n= bsp;         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | 0x01 (Access-Loop-Circuit-ID) |   = ;     Client-ID Length     &nbs= p; |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     |        &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;    |
     ~        &= nbsp;            = ; Port Client-ID          =             &nbs= p;    ~
     |        &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+

Following the Port Client-ID information, one or more Command TLV
components can be included and the Access Node should process them in
the order in which they are listed. The Access Node (ANCP Client) should threat all the commands as a single command block to be viewed as a
whole and bail out immediately when one of them fails.
The format of command TLV is as follow:

      0       &= nbsp;           1 &nb= sp;            &= nbsp;    2        &nb= sp;          3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9= 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     |  Type =3D CommandCode    =        |      &n= bsp;   Length         = ;      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | Addr Family   | Encoding Type | &= nbsp;Multicast Group Address      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | Addr Family   | Encoding Type | &= nbsp;Multicast Source Address     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+

Where CommandCode specifies the command and can be one of the following:
0x01  Add       Adds the specified multi= cast flow to the specified port
(join)
0x02  Delete    Deletes the specified multicast flow (l= eave) on the
specified port.
0x04  DeleteAll Deletes All multicast flow on the specified port (leav= e
all). No addresses are supplied.

When we have more than one command, Deletes should always be listed
first. The unicast source address/mask follows the format defined in RFC 2362 Section 4.1 case 1 which is duplicated here for quick review:

Encoded-Unicast-address: Takes the following format:

  0           &= nbsp;       1     &nb= sp;            &= nbsp;2            &nb= sp;      3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Addr Family   | Encoding Type |     U= nicast Address           |=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Addr Family
           The addre= ss family of the `Unicast Address' field  of
           this addr= ess.

          Here is the add= ress family numbers assigned by IANA:

 Number    Description
 --------  ------------------------------------------------------= ---
      0    Reserved
      1    IP (IP version 4)       2    IP6 (IP version 6)<= BR>       3    NSAP
      4    HDLC (8-bit multidr= op)
      5    BBN 1822
      6    802 (includes all 8= 02 media plus Ethernet "canonical format")
      7    E.163
      8    E.164 (SMDS, Frame = Relay, ATM)
      9    F.69 (Telex)
     10    X.121 (X.25, Frame Relay= )
     11    IPX
     12    Appletalk
     13    Decnet IV
     14    Banyan Vines
     15    E.164 with NSAP format s= ubaddress

     Encoding Type
          The type of enc= oding used within a specific Address
          Family.  T= he value `0' is reserved for this field,
          and represents = the native encoding of the Address
          Family.

     Unicast Address
          The unicast add= ress as represented by the given
          Address Family = and Encoding Type.

Finally, although the length could be derived from the Addr Family and
the Encoding type, it is kept for future possible extension to this
command where other entry would be added to this command segment.
The equivalent of a swap command where the NAS would want to switch from multicast group 239.23.2.2 to 239.55.3.2 will have the following format:
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9= 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     |        T= ype (0x88-0C)         |   =         Length    &nb= sp;         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | Vers  |  Sub  |MessageType=3D9= 0 | Result|        Code    = ;       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | Partition ID  |    &nbs= p;       Transaction Identifier =3D 0001 &n= bsp;    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     |I|      SubMessage = Number      |       &= nbsp;   Length        &nbs= p;     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | 0x01 (Replication-Control)   &nbs= p;|             = Length            |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | 0x01 (Access-Loop-Circuit-ID) |   = ;     Client-ID Length     &nbs= p; |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     |        &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;    |
     ~        &= nbsp;            = ; Port Client-ID          =             &nbs= p;    ~
     |        &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | Type=3DCommandCode: Delete(0x02)|   = ;        Length    &n= bsp;         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | AddrFamily 01 | EncType 0x0   | &= nbsp;Mcast group: 239.23.2.2      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-|
     | AddrFamily 01 | EncType 0x0   | &= nbsp;Mcast Source: 10.1.1.1       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-|
     | Type=3DCommandCode: Add (0x01)  |  =          Length   &nb= sp;          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | AddrFamily 01 | EncType 0x0   | &= nbsp;Mcast group: 239.55.3.2      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-|
     | AddrFamily 01 | EncType 0x0   | &= nbsp;Mcast Source: 10.1.1.1       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-|

Each command in the list is attributed an identification number based on its occurrence in the message. In this case, the Delete command will be
attributed command number 1 while the Add will be attributed command
number 2. During the processing of these  commands, upon the first
failure of a command, the sequence is interrupted and an error message
(via Multicast Status Message) will be returned with the command number
identifying the command that failed.

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www.ietf.org/mailman/listinfo/ancp

_____________________________________________= __
ANCP mailing list
ANCP@ietf.org
https://www.ietf.org/mailman/listinfo/ancp
--B_3291552725_776548-- --===============0783702527== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============0783702527==-- From ancp-bounces@ietf.org Mon Apr 21 12:12:18 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFC523A6DC4; Mon, 21 Apr 2008 12:12:18 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 123063A6AF1 for ; Mon, 21 Apr 2008 12:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.477 X-Spam-Level: X-Spam-Status: No, score=-0.477 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994, SARE_UNSUB18=0.131] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCtgCqEwDleQ for ; Mon, 21 Apr 2008 12:12:03 -0700 (PDT) Received: from wipro-blr-out02.wipro.com (wipro-blr-out02.wipro.com [203.91.198.75]) by core3.amsl.com (Postfix) with ESMTP id B8EA73A6F64 for ; Mon, 21 Apr 2008 12:12:01 -0700 (PDT) X-AuditID: cb5bdd58-ae38ebb000004602-a6-480ce70691ee Received: from blr-ec-bh02.wipro.com (unknown [10.201.50.92]) by wipro-blr-out02.wipro.com (Symantec Mail Security) with ESMTP id 38C1C558002 for ; Tue, 22 Apr 2008 00:42:06 +0530 (IST) Received: from BLR-EC-MBX07.wipro.com ([10.201.52.181]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Apr 2008 00:42:06 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Apr 2008 00:42:05 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP Multicast Control Message Thread-Index: AcieEVmGGiNqxJsfTu6YY/jux+SZrwALfVfQAGQoukUAyjyKeQA4wnvx References: From: To: , , X-OriginalArrivalTime: 21 Apr 2008 19:12:06.0160 (UTC) FILETIME=[96B7F100:01C8A3E3] X-Brightmail-Tracker: AAAAAA== Subject: Re: [ANCP] ANCP Multicast Control Message X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2102677036==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============2102677036== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A3E3.9674EE21" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A3E3.9674EE21 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Einar, Modify command would be usefull from Access box perspective, as the = underlying implementation in AN's would have the freedom to design their = swap operation, instead of always first deleting the existing group = entry and adding another entry. =20 Thanks Vish =20 ________________________________ From: einarnn [mailto:einarnn@cisco.com] Sent: Sun 4/20/2008 11:12 AM To: Vishwanathan Somasundaram (WT01 - TES-Access Networks); = wdec@cisco.com; ancp@ietf.org Subject: Re: [ANCP] ANCP Multicast Control Message Vish, Overloading the second byte of the command code to contain the number of = "modifications" doesn't seem a good approach and the space saving per = packet, which will probably be only 4 bytes most of the time, seems = almost irrelevant. I think it would be better to keep the fields in the = message for a single task. Treating a sequence of commands as an atomic operation, as detailed in = the text, and implementing a swap via a delete follow by an add, should = give ANs the freedom to implement what are, in effect, swap operations = quite efficiently. In this context, I'm not sure what a "modify" command = code will really add? Cheers, Einar On 16/04/2008 15:41, "vishwanathan.sundaram@wipro.com" = wrote: Hi Woj, Currently, the command codes for replication control message are 1. add (0x01) 2. delete (0x02) 3. delete all (0x04). =09 Looking at the multicast Swap message format, which is used when the = NAS wants to switch from one group to another,can we not handle this = situation by having a message type Modify (0x08). By using this message type we can mention the multicast group address = which needs to be swapped by new multicast group address. Since the Command Code is 2 bytes, the second byte can be used to = mention the number of multicast groups that needs to be swapped. This will allow, for multiple multicast group swaps. This will also = reduce the size of the packet. Since these messages intended only = between the NAS and AN, the introduction of modify command type gives = further ease to the Access boxes in implementing the swaps, which = attributes to zap latency. =09 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x88-0C) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub |MessageType=3D90 | Result| Code = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier =3D 0001 = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 (Replication-Control) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 (Access-Loop-Circuit-ID) | Client-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Port Client-ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=3DCommandCode: Modify(0x08)| Length = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast group: 239.23.2.2 = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | AddrFamily 01 | EncType 0x0 | Mcast Source: 10.1.1.1 = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | AddrFamily 01 | EncType 0x0 | New Mcast group: 239.55.3.2 = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | AddrFamily 01 | EncType 0x0 | New Mcast Source: 10.1.1.1 = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| =09 Looking into the DSL TR 101, it also discusses about the multicast flow = being associated with a VLAN (Multicast-Vlan). In this case, the Access = Node, needs to be informed about the VLAN ID on which a particular = Multicast group is being associated by the NAS. Can this information = also be added as part of the TLV in message. =09 Thanks Vish =09 =09 ________________________________ From: ancp-bounces@ietf.org on behalf of Wojciech Dec (wdec) Sent: Mon 4/14/2008 11:00 AM To: ancp@ietf.org Subject: [ANCP] ANCP Multicast Control Message =09 =09 =09 Hi All, =09 As discussed during our recent IETF 71 meeting, our protocol design = team has forged ahead with prioritized list of problems to address, the = first of which was defining the ANCP message extensions for multicast = control, aka unsolicited multicast control. The DT is working on the response message and also the solicited multicast control mode. Below, we present the outcome of the work, which represents both a design team consensus as well as a proposal for adoption into the ANCP protocol spec, draft-ietf-ancp-protocol (some editorial work will be still required). Please review the proposal and share your comments. We will assume acceptance of the proposal in principle otherwise. =09 Regards, Woj & Matthew. =09 =09 2 Replication Control Message =09 =09 This message is sent by the ANCP Server (NAS) to the ANCP Client (AN) with a directive to either add (join) or delete (leave) a port to or from a multicast flow. Its format is as follow: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=3DReplication-Control (0x01)| Length = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 (Access-Loop-Circuit-ID) | Client-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Port Client-ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 Following the Port Client-ID information, one or more Command TLV components can be included and the Access Node should process them in the order in which they are listed. The Access Node (ANCP Client) = should threat all the commands as a single command block to be viewed as a whole and bail out immediately when one of them fails. The format of command TLV is as follow: =09 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D CommandCode | Length = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Multicast Group Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Multicast Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 Where CommandCode specifies the command and can be one of the = following: =09 0x01 Add Adds the specified multicast flow to the specified port (join) 0x02 Delete Deletes the specified multicast flow (leave) on the specified port. 0x04 DeleteAll Deletes All multicast flow on the specified port (leave all). No addresses are supplied. =09 When we have more than one command, Deletes should always be listed first. The unicast source address/mask follows the format defined in = RFC 2362 Section 4.1 case 1 which is duplicated here for quick review: =09 Encoded-Unicast-address: Takes the following format: =09 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Unicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 Addr Family The address family of the `Unicast Address' field of this address. =09 Here is the address family numbers assigned by IANA: =09 Number Description -------- --------------------------------------------------------- 0 Reserved 1 IP (IP version 4) 2 IP6 (IP version 6) 3 NSAP 4 HDLC (8-bit multidrop) 5 BBN 1822 6 802 (includes all 802 media plus Ethernet "canonical = format") 7 E.163 8 E.164 (SMDS, Frame Relay, ATM) 9 F.69 (Telex) 10 X.121 (X.25, Frame Relay) 11 IPX 12 Appletalk 13 Decnet IV 14 Banyan Vines 15 E.164 with NSAP format subaddress =09 Encoding Type The type of encoding used within a specific Address Family. The value `0' is reserved for this field, and represents the native encoding of the Address Family. =09 Unicast Address The unicast address as represented by the given Address Family and Encoding Type. =09 Finally, although the length could be derived from the Addr Family and the Encoding type, it is kept for future possible extension to this command where other entry would be added to this command segment. The equivalent of a swap command where the NAS would want to switch = from multicast group 239.23.2.2 to 239.55.3.2 will have the following = format: =09 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x88-0C) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub |MessageType=3D90 | Result| Code = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier =3D 0001 = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 (Replication-Control) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 (Access-Loop-Circuit-ID) | Client-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Port Client-ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=3DCommandCode: Delete(0x02)| Length = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast group: 239.23.2.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | AddrFamily 01 | EncType 0x0 | Mcast Source: 10.1.1.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | Type=3DCommandCode: Add (0x01) | Length = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast group: 239.55.3.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | AddrFamily 01 | EncType 0x0 | Mcast Source: 10.1.1.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| =09 Each command in the list is attributed an identification number based = on its occurrence in the message. In this case, the Delete command will be attributed command number 1 while the Add will be attributed command number 2. During the processing of these commands, upon the first failure of a command, the sequence is interrupted and an error message (via Multicast Status Message) will be returned with the command number identifying the command that failed. =09 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp =09 =09 ________________________________ _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp =09 ------_=_NextPart_001_01C8A3E3.9674EE21 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [ANCP] ANCP Multicast Control = Message=0A= =0A= =0A= =0A=
=0A=
Einar,
=0A=
Modify command would be = usefull from Access box perspective, as the underlying implementation in = AN's would have the freedom to design their swap operation, instead of = always first deleting the existing group entry and adding another = entry.
=0A=
 
=0A=
Thanks
=0A=
Vish
=0A=
 
=0A=

=0A=
=0A= From: einarnn = [mailto:einarnn@cisco.com]
Sent: Sun 4/20/2008 11:12 = AM
To: Vishwanathan Somasundaram (WT01 - TES-Access Networks); = wdec@cisco.com; ancp@ietf.org
Subject: Re: [ANCP] ANCP = Multicast Control Message

=0A=
Vish,

Overloading the = second byte of the command code to contain the number of = “modifications” doesn’t seem a good approach and the = space saving per packet, which will probably be only 4 bytes most of the = time, seems almost irrelevant. I think it would be better to keep the = fields in the message for a single task.

Treating a sequence of = commands as an atomic operation, as detailed in the text, and = implementing a swap via a delete follow by an add, should give ANs the = freedom to implement what are, in effect, swap operations quite = efficiently. In this context, I’m not sure what a = “modify” command code will really = add?

Cheers,

Einar

On 16/04/2008 15:41, = "vishwanathan.sundaram@wipro.com" = <vishwanathan.sundaram@wipro.com> = wrote:

=0A=
Hi Woj,
Currently, the command codes for = replication control message are
1. add (0x01)
2. delete = (0x02)
3. delete all (0x04).

Looking at the multicast Swap = message format, which is used when the NAS wants to switch from one = group to another,can we not handle this situation by having a message = type Modify (0x08).
By using this message type we can mention the = multicast group address which needs to be swapped by new multicast group = address.
Since the Command Code is 2 bytes, the second byte can be = used to mention the number of multicast groups that needs to be = swapped.
This will allow, for multiple multicast group swaps. This = will also reduce the size of the packet. Since these messages intended = only between the NAS and AN, the introduction of modify command type = gives further ease to the Access boxes in implementing the swaps, which = attributes to zap latency.

     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 = 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+
     | =        Type (0x88-0C) =         | =           Length =             &= nbsp;|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Vers =  |  Sub  |MessageType=3D90 | Result| =        Code =           |
 &n= bsp;   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+
     | Partition ID  | =            Transac= tion Identifier =3D 0001 =      |
     +-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  =    |I|      SubMessage Number =      | =           Length =             &= nbsp;|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | 0x01 = (Replication-Control)    | =             L= ength =            |
&n= bsp;    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | 0x01 = (Access-Loop-Circuit-ID) | =        Client-ID Length =       |
     +-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 =     | =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ; |
     ~ =             &= nbsp;        Port Client-ID =             &= nbsp;           &n= bsp; ~
     | =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ; |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | = Type=3DCommandCode: Modify(0x08)| =           Length =             &= nbsp;           &n= bsp; |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | = AddrFamily 01 | EncType 0x0    |  Mcast group: = 239.23.2.2 =            |
&n= bsp;    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-|
     | AddrFamily 01 | = EncType 0x0    |  Mcast Source: 10.1.1.1 =             &= nbsp; |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     &= nbsp;| AddrFamily 01 | EncType 0x0   |  New Mcast = group: 239.55.3.2 =   |
     +-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
    &nb= sp;| AddrFamily 01 | EncType 0x0    |  New Mcast = Source: 10.1.1.1 =      |
     +-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|

Looking into the DSL TR 101, it = also discusses about the multicast flow being associated with a VLAN = (Multicast-Vlan). In this case, the Access Node, needs to be informed = about the VLAN ID on which a particular Multicast group is being = associated by the NAS. Can this information also be added as part of the = TLV in message.

Thanks
Vish

=0A=
=0A= From: ancp-bounces@ietf.org on behalf = of Wojciech Dec (wdec)
Sent: Mon 4/14/2008 11:00 = AM
To: ancp@ietf.org
Subject: [ANCP] ANCP Multicast = Control Message



Hi All,

As discussed during our recent IETF 71 = meeting, our protocol design team
has forged ahead with prioritized = list of problems to address, the first
of which was defining the ANCP = message extensions for multicast control,
aka unsolicited multicast = control. The DT is working on the response
message and also the = solicited multicast control mode.
Below, we present the outcome of = the work, which represents both a
design team consensus as well as a = proposal for adoption into the ANCP
protocol spec, = draft-ietf-ancp-protocol (some editorial work will be
still = required). Please review the proposal and share your comments. = We
will assume acceptance of the proposal in principle = otherwise.

Regards,
Woj & Matthew.


2 =       Replication Control = Message


This message is sent by the ANCP Server (NAS) to the = ANCP Client (AN)
with a directive to either add (join) or delete = (leave) a port to or
from a multicast flow. Its format is as = follow:
      0 1 2 3 4 5 6 7 8 9 0 1 2 = 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Type=3DRepl= ication-Control (0x01)| =             L= ength =            |
&n= bsp;    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | 0x01 = (Access-Loop-Circuit-ID) | =        Client-ID Length =       |
     +-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 =     | =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ; |
     ~ =             &= nbsp;        Port Client-ID =             &= nbsp;           &n= bsp; ~
     | =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ; |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Following the Port Client-ID = information, one or more Command TLV
components can be included and = the Access Node should process them in
the order in which they are = listed. The Access Node (ANCP Client) should
threat all the commands = as a single command block to be viewed as a
whole and bail out = immediately when one of them fails.
The format of command TLV is as = follow:

      0 =             &= nbsp;     1 =             &= nbsp;     2 =             &= nbsp;     3
     &nb= sp;0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type = =3D CommandCode =           | =          Length =             &= nbsp; |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |= Addr Family   | Encoding Type |  Multicast Group Address =      |
     +-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  =    | Addr Family   | Encoding Type | =  Multicast Source Address =     |
     +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where = CommandCode specifies the command and can be one of the = following:

0x01  Add =       Adds the specified multicast flow to = the specified port
(join)
0x02  Delete =    Deletes the specified multicast flow (leave) on = the
specified port.
0x04  DeleteAll Deletes All multicast = flow on the specified port (leave
all). No addresses are = supplied.

When we have more than one command, Deletes should = always be listed
first. The unicast source address/mask follows the = format defined in RFC
2362 Section 4.1 case 1 which is duplicated = here for quick review:

Encoded-Unicast-address: Takes the = following format:

  0 =             &= nbsp;     1 =             &= nbsp;     2 =             &= nbsp;     3
  0 1 2 3 4 5 6 7 8 9 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
 | Addr Family   | Encoding Type | =     Unicast Address =           |
 +-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

&n= bsp;    Addr = Family
          &nb= sp;The address family of the `Unicast Address' field =  of
          &= nbsp;this = address.

         &nb= sp;Here is the address family numbers assigned by = IANA:

 Number =    Description
 -------- =  ---------------------------------------------------------
 =      0 =    Reserved
      1 =    IP (IP version = 4)
      2    IP6 (IP = version 6)
      3 =    NSAP
      4 =    HDLC (8-bit = multidrop)
      5 =    BBN 1822
      6 =    802 (includes all 802 media plus Ethernet "canonical = format")
      7 =    E.163
      8 =    E.164 (SMDS, Frame Relay, = ATM)
      9    F.69 = (Telex)
     10    X.121 = (X.25, Frame Relay)
     11 =    IPX
     12 =    Appletalk
     13 =    Decnet IV
     14 =    Banyan Vines
     15 =    E.164 with NSAP format = subaddress

     Encoding = Type
          The = type of encoding used within a specific = Address
          Fa= mily.  The value `0' is reserved for this = field,
          and= represents the native encoding of the = Address
          Fa= mily.

     Unicast = Address
          Th= e unicast address as represented by the = given
          Addr= ess Family and Encoding Type.

Finally, although the length could = be derived from the Addr Family and
the Encoding type, it is kept for = future possible extension to this
command where other entry would be = added to this command segment.
The equivalent of a swap command where = the NAS would want to switch from
multicast group 239.23.2.2 to = 239.55.3.2 will have the following = format:

      0 1 2 3 4 5 6 7 8 9 0 = 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+
     | =        Type (0x88-0C) =         | =           Length =             &= nbsp;|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Vers =  |  Sub  |MessageType=3D90 | Result| =        Code =           |
 &n= bsp;   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+
     | Partition ID  | =            Transac= tion Identifier =3D 0001 =      |
     +-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  =    |I|      SubMessage Number =      | =           Length =             &= nbsp;|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | 0x01 = (Replication-Control)    | =             L= ength =            |
&n= bsp;    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | 0x01 = (Access-Loop-Circuit-ID) | =        Client-ID Length =       |
     +-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 =     | =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ; |
     ~ =             &= nbsp;        Port Client-ID =             &= nbsp;           &n= bsp; ~
     | =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ; |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | = Type=3DCommandCode: Delete(0x02)| =           Length =             &= nbsp;|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | = AddrFamily 01 | EncType 0x0   |  Mcast group: 239.23.2.2 =      |
     +-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
  =    | AddrFamily 01 | EncType 0x0   | =  Mcast Source: 10.1.1.1 =       |
     +-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
 =     | Type=3DCommandCode: Add (0x01)  | =           Length =             &= nbsp;|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | = AddrFamily 01 | EncType 0x0   |  Mcast group: 239.55.3.2 =      |
     +-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
  =    | AddrFamily 01 | EncType 0x0   | =  Mcast Source: 10.1.1.1 =       |
     +-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|

Ea= ch command in the list is attributed an identification number based = on
its occurrence in the message. In this case, the Delete command = will be
attributed command number 1 while the Add will be attributed = command
number 2. During the processing of these  commands, upon = the first
failure of a command, the sequence is interrupted and an = error message
(via Multicast Status Message) will be returned with = the command number
identifying the command that = failed.

_______________________________________________
ANCP = mailing = list
ANCP@ietf.org
https://www.ietf.org/mailman/listinfo/ancp
=0A=
=0A= _______________________________________________
ANCP mailing = list
ANCP@ietf.org
https://www.ietf.org/mailman/listinfo/ancp
------_=_NextPart_001_01C8A3E3.9674EE21-- --===============2102677036== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============2102677036==-- From ancp-bounces@ietf.org Mon Apr 21 13:47:20 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42AE93A6F7A; Mon, 21 Apr 2008 13:47:20 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3F8F3A6F7A for ; Mon, 21 Apr 2008 13:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.171 X-Spam-Level: X-Spam-Status: No, score=-3.171 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_UNSUB18=0.131] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kme4MRRjiO9Y for ; Mon, 21 Apr 2008 13:47:06 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 47D393A6F89 for ; Mon, 21 Apr 2008 13:47:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,691,1199660400"; d="scan'208,217";a="6912094" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 21 Apr 2008 22:47:10 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3LKl9NB014876; Mon, 21 Apr 2008 22:47:09 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3LKlAnS007882; Mon, 21 Apr 2008 20:47:10 GMT Received: from xmb-ams-336.cisco.com ([144.254.231.81]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Apr 2008 22:47:09 +0200 Received: from 10.61.98.9 ([10.61.98.9]) by xmb-ams-336.emea.cisco.com ([144.254.231.81]) with Microsoft Exchange Server HTTP-DAV ; Mon, 21 Apr 2008 20:47:09 +0000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Mon, 21 Apr 2008 21:47:06 +0100 From: Einar Nilsen-Nygaard To: , , Message-ID: Thread-Topic: [ANCP] ANCP Multicast Control Message Thread-Index: AcieEVmGGiNqxJsfTu6YY/jux+SZrwALfVfQAGQoukUAyjyKeQA4wnvxAAU7juU= In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 21 Apr 2008 20:47:09.0904 (UTC) FILETIME=[DE6A3500:01C8A3F0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=43692; t=1208810830; x=1209674830; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=einarnn@cisco.com; z=From:=20Einar=20Nilsen-Nygaard=20 |Subject:=20Re=3A=20[ANCP]=20ANCP=20Multicast=20Control=20M essage |Sender:=20; bh=8NN+lzJU6VT7yMvCNdIcM5cK1So5XhvMsH9mdyf+ah4=; b=goHgcQ4692r171QLECl0G5FHFv7tNaW2to/9iA1aYs4ofC4RPycMP0Mt2u QagMfIME+vADNQPpTXUHzWKECpnqhMd/Tp6D2MpUVU9hAuJatrhVzvbUx2h7 iZKSN0JaBC; Authentication-Results: ams-dkim-2; header.From=einarnn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [ANCP] ANCP Multicast Control Message X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0693217224==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0693217224== Content-type: multipart/alternative; boundary="B_3291659227_17479407" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3291659227_17479407 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Vish, I actually think that freedom in how a =B3swap=B2 operation would be implemente= d in terms of the ordering of stopping the first multicast flow and starting the second is not desirable. By specifying that the delete must come before the add and that the operation should be terminated upon the first error, the current specification gives us what should be deterministic behavior between any and all conforming implementations. In contrast, the freedom to implement a swap operation via some form of modify leaves the door open to multiple ways in which a modify request coul= d fail, making error recovery more troublesome and vendor-specific which I do not see as at all desirable. Cheers, Einar On 21/04/2008 20:12, "vishwanathan.sundaram@wipro.com" scribbled: > Einar, > Modify command would be usefull from Access box perspective, as the under= lying > implementation in AN's would have the freedom to design their swap operat= ion, > instead of always first deleting the existing group entry and adding anot= her > entry. > =20 > Thanks > Vish > =20 >=20 >=20 > From: einarnn [mailto:einarnn@cisco.com] > Sent: Sun 4/20/2008 11:12 AM > To: Vishwanathan Somasundaram (WT01 - TES-Access Networks); wdec@cisco.co= m; > ancp@ietf.org > Subject: Re: [ANCP] ANCP Multicast Control Message >=20 > Vish, >=20 > Overloading the second byte of the command code to contain the number of > =B3modifications=B2 doesn=B9t seem a good approach and the space saving per pac= ket, > which will probably be only 4 bytes most of the time, seems almost irrele= vant. > I think it would be better to keep the fields in the message for a single > task. >=20 > Treating a sequence of commands as an atomic operation, as detailed in th= e > text, and implementing a swap via a delete follow by an add, should give = ANs > the freedom to implement what are, in effect, swap operations quite > efficiently. In this context, I=B9m not sure what a =B3modify=B2 command code w= ill > really add? >=20 > Cheers, >=20 > Einar >=20 > On 16/04/2008 15:41, "vishwanathan.sundaram@wipro.com" > wrote: >=20 >> Hi Woj, >> Currently, the command codes for replication control message are >> 1. add (0x01) >> 2. delete (0x02) >> 3. delete all (0x04). >>=20 >> Looking at the multicast Swap message format, which is used when the NAS >> wants to switch from one group to another,can we not handle this situati= on by >> having a message type Modify (0x08). >> By using this message type we can mention the multicast group address wh= ich >> needs to be swapped by new multicast group address. >> Since the Command Code is 2 bytes, the second byte can be used to mentio= n the >> number of multicast groups that needs to be swapped. >> This will allow, for multiple multicast group swaps. This will also redu= ce >> the size of the packet. Since these messages intended only between the N= AS >> and AN, the introduction of modify command type gives further ease to th= e >> Access boxes in implementing the swaps, which attributes to zap latency. >>=20 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type (0x88-0C) | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Vers | Sub |MessageType=3D90 | Result| Code | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Partition ID | Transaction Identifier =3D 0001 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |I| SubMessage Number | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 0x01 (Replication-Control) | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 0x01 (Access-Loop-Circuit-ID) | Client-ID Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> ~ Port Client-ID ~ >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type=3DCommandCode: Modify(0x08)| Length >> | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | AddrFamily 01 | EncType 0x0 | Mcast group: 239.23.2.2 = | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| >> | AddrFamily 01 | EncType 0x0 | Mcast Source: 10.1.1.1 >> | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| >> | AddrFamily 01 | EncType 0x0 | New Mcast group: 239.55.3.2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| >> | AddrFamily 01 | EncType 0x0 | New Mcast Source: 10.1.1.1 = | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| >>=20 >> Looking into the DSL TR 101, it also discusses about the multicast flow = being >> associated with a VLAN (Multicast-Vlan). In this case, the Access Node, = needs >> to be informed about the VLAN ID on which a particular Multicast group i= s >> being associated by the NAS. Can this information also be added as part = of >> the TLV in message. >>=20 >> Thanks >> Vish >>=20 >>=20 >> From: ancp-bounces@ietf.org on behalf of Wojciech Dec (wdec) >> Sent: Mon 4/14/2008 11:00 AM >> To: ancp@ietf.org >> Subject: [ANCP] ANCP Multicast Control Message >>=20 >>=20 >>=20 >> Hi All, >>=20 >> As discussed during our recent IETF 71 meeting, our protocol design team >> has forged ahead with prioritized list of problems to address, the first >> of which was defining the ANCP message extensions for multicast control, >> aka unsolicited multicast control. The DT is working on the response >> message and also the solicited multicast control mode. >> Below, we present the outcome of the work, which represents both a >> design team consensus as well as a proposal for adoption into the ANCP >> protocol spec, draft-ietf-ancp-protocol (some editorial work will be >> still required). Please review the proposal and share your comments. We >> will assume acceptance of the proposal in principle otherwise. >>=20 >> Regards, >> Woj & Matthew. >>=20 >>=20 >> 2 Replication Control Message >>=20 >>=20 >> This message is sent by the ANCP Server (NAS) to the ANCP Client (AN) >> with a directive to either add (join) or delete (leave) a port to or >> from a multicast flow. Its format is as follow: >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |Type=3DReplication-Control (0x01)| Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 0x01 (Access-Loop-Circuit-ID) | Client-ID Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> ~ Port Client-ID ~ >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> Following the Port Client-ID information, one or more Command TLV >> components can be included and the Access Node should process them in >> the order in which they are listed. The Access Node (ANCP Client) should >> threat all the commands as a single command block to be viewed as a >> whole and bail out immediately when one of them fails. >> The format of command TLV is as follow: >>=20 >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type =3D CommandCode | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Addr Family | Encoding Type | Multicast Group Address | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Addr Family | Encoding Type | Multicast Source Address | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> Where CommandCode specifies the command and can be one of the following: >>=20 >> 0x01 Add Adds the specified multicast flow to the specified port >> (join) >> 0x02 Delete Deletes the specified multicast flow (leave) on the >> specified port. >> 0x04 DeleteAll Deletes All multicast flow on the specified port (leave >> all). No addresses are supplied. >>=20 >> When we have more than one command, Deletes should always be listed >> first. The unicast source address/mask follows the format defined in RFC >> 2362 Section 4.1 case 1 which is duplicated here for quick review: >>=20 >> Encoded-Unicast-address: Takes the following format: >>=20 >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Addr Family | Encoding Type | Unicast Address | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> Addr Family >> The address family of the `Unicast Address' field of >> this address. >>=20 >> Here is the address family numbers assigned by IANA: >>=20 >> Number Description >> -------- --------------------------------------------------------- >> 0 Reserved >> 1 IP (IP version 4) >> 2 IP6 (IP version 6) >> 3 NSAP >> 4 HDLC (8-bit multidrop) >> 5 BBN 1822 >> 6 802 (includes all 802 media plus Ethernet "canonical format") >> 7 E.163 >> 8 E.164 (SMDS, Frame Relay, ATM) >> 9 F.69 (Telex) >> 10 X.121 (X.25, Frame Relay) >> 11 IPX >> 12 Appletalk >> 13 Decnet IV >> 14 Banyan Vines >> 15 E.164 with NSAP format subaddress >>=20 >> Encoding Type >> The type of encoding used within a specific Address >> Family. The value `0' is reserved for this field, >> and represents the native encoding of the Address >> Family. >>=20 >> Unicast Address >> The unicast address as represented by the given >> Address Family and Encoding Type. >>=20 >> Finally, although the length could be derived from the Addr Family and >> the Encoding type, it is kept for future possible extension to this >> command where other entry would be added to this command segment. >> The equivalent of a swap command where the NAS would want to switch from >> multicast group 239.23.2.2 to 239.55.3.2 will have the following format: >>=20 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type (0x88-0C) | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Vers | Sub |MessageType=3D90 | Result| Code | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Partition ID | Transaction Identifier =3D 0001 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |I| SubMessage Number | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 0x01 (Replication-Control) | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 0x01 (Access-Loop-Circuit-ID) | Client-ID Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> ~ Port Client-ID ~ >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type=3DCommandCode: Delete(0x02)| Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | AddrFamily 01 | EncType 0x0 | Mcast group: 239.23.2.2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| >> | AddrFamily 01 | EncType 0x0 | Mcast Source: 10.1.1.1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| >> | Type=3DCommandCode: Add (0x01) | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | AddrFamily 01 | EncType 0x0 | Mcast group: 239.55.3.2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| >> | AddrFamily 01 | EncType 0x0 | Mcast Source: 10.1.1.1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| >>=20 >> Each command in the list is attributed an identification number based on >> its occurrence in the message. In this case, the Delete command will be >> attributed command number 1 while the Add will be attributed command >> number 2. During the processing of these commands, upon the first >> failure of a command, the sequence is interrupted and an error message >> (via Multicast Status Message) will be returned with the command number >> identifying the command that failed. >>=20 >> _______________________________________________ >> ANCP mailing list >> ANCP@ietf.org >> https://www.ietf.org/mailman/listinfo/ancp >>=20 >>=20 >> _______________________________________________ >> ANCP mailing list >> ANCP@ietf.org >> https://www.ietf.org/mailman/listinfo/ancp >=20 > Please do not print this email unless it is absolutely necessary. >=20 > The information contained in this electronic message and any attachments= to > this message are intended for the exclusive use of the addressee(s) and m= ay > contain proprietary, confidential or privileged information. If you are n= ot > the intended recipient, you should not disseminate, distribute or copy th= is > e-mail. Please notify the sender immediately and destroy all copies of th= is > message and any attachments. >=20 > WARNING: Computer viruses can be transmitted via email. The recipient sho= uld > check this email and any attachments for the presence of viruses. The com= pany > accepts no liability for any damage caused by any virus transmitted by th= is > email.=20 >=20 > www.wipro.com=20 >=20 >=20 > --=20 > Einar Nilsen-Nygaard > Technical Leader, Cisco >=20 > Clothes make the man. Naked people have little or no influence on > society. --Mark Twain >=20 --B_3291659227_17479407 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [ANCP] ANCP Multicast Control Message Vish,

I actually think that freedom in how a “swap” operation would b= e implemented in terms of the ordering of stopping the first multicast flow = and starting the second is not desirable. By specifying that the dele= te must come before the add and that the operation should be terminated upon= the first error, the current specification gives us what should be determin= istic behavior between any and all conforming implementations.

In contrast, the freedom to implement a swap operation via some form of mod= ify leaves the door open to multiple ways in which a modify request could= fail, making error recovery more troublesome and vendor-specific which = I do not see as at all desirable.

Cheers,

Einar

On 21/04/2008 20:12, "vishwanathan.sundaram@wipro.com" <vishwa= nathan.sundaram@wipro.com> scribbled:

Einar,
Modify command would be usefull from Access box perspective, as the underly= ing implementation in AN's would have the freedom to design their swap opera= tion, instead of always first deleting the existing group entry and adding a= nother entry.
Thanks
Vish

From: einarnn [= mailto:einarnn@cisco.com]
Sent: Sun 4/20/2008 11:12 AM
To: Vishwanathan Somasundaram (WT01 - TES-Access Networks); wdec@cis= co.com; ancp@ietf.org
Subject: Re: [ANCP] ANCP Multicast Control Message

Vish,

Overloading the second byte of the command code to contain the number of &#= 8220;modifications” doesn’t seem a good approach and the space s= aving per packet, which will probably be only 4 bytes most of the time, seem= s almost irrelevant. I think it would be better to keep the fields in the me= ssage for a single task.

Treating a sequence of commands as an atomic operation, as detailed in the = text, and implementing a swap via a delete follow by an add, should give ANs= the freedom to implement what are, in effect, swap operations quite efficie= ntly. In this context, I’m not sure what a “modify” comman= d code will really add?

Cheers,

Einar

On 16/04/2008 15:41, "vishwanathan.sundaram@wipro.com" <vishwa= nathan.sundaram@wipro.com> wrote:


Looking at the multicast Swap message format, which is us= ed when the NAS wants to switch from one group to another,can we not handle = this situation by having a message type Modify (0x08).
By using this message type we can mention the multicast group address which= needs to be swapped by new multicast group address.
Since the Command Code is 2 bytes, the second byte can be used to mention t= he number of multicast groups that needs to be swapped.
This will allow, for multiple multicast group swaps. This will also reduce = the size of the packet. Since these messages intended only between the NAS a= nd AN, the introduction of modify command type gives further ease to the Acc= ess boxes in implementing the swaps, which attributes to zap latency.

 &n= bsp;   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 = 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     |        T= ype (0x88-0C)         |   =         Length    &nb= sp;         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | Vers  |  Sub  |MessageType=3D9= 0 | Result|        Code    = ;       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | Partition ID  |    &nbs= p;       Transaction Identifier =3D 0001 &n= bsp;    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     |I|      SubMessage = Number      |       &= nbsp;   Length        &nbs= p;     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | 0x01 (Replication-Control)   &nbs= p;|             = Length            |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | 0x01 (Access-Loop-Circuit-ID) |   = ;     Client-ID Length     &nbs= p; |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     |        &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;    |
     ~        &= nbsp;            = ; Port Client-ID          =             &nbs= p;    ~
     |        &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Type=3DCommandCode: Modify(0x08)| &nbs= p;         Length   &= nbsp;            = ;           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | AddrFamily 01 | EncType 0x0   &nb= sp;|  Mcast group: 239.23.2.2        = ;    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-|
     | AddrFamily 01 | EncType 0x0   &nb= sp;|  Mcast Source: 10.1.1.1        =        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-|
      | AddrFamily 01 | EncType 0x0  =  |  New Mcast group: 239.55.3.2   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-|
     | AddrFamily 01 | EncType 0x0   &nb= sp;|  New Mcast Source: 10.1.1.1      |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-|

Looking into the DSL TR 101, it also discusses about the = multicast flow being associated with a VLAN (Multicast-Vlan). In this case, = the Access Node, needs to be informed about the VLAN ID on which a particula= r Multicast group is being associated by the NAS. Can this information also = be added as part of the TLV in message.

Thanks
Vish

From: ancp-boun= ces@ietf.org on behalf of Wojciech Dec (wdec)
Sent: Mon 4/14/2008 11:00 AM
To: ancp@ietf.org
Subject: [ANCP] ANCP Multicast Control Message



Hi All,

As discussed during our recent IETF 71 meeting, our protocol design team has forged ahead with prioritized list of problems to address, the first of which was defining the ANCP message extensions for multicast control, aka unsolicited multicast control. The DT is working on the response
message and also the solicited multicast control mode.
Below, we present the outcome of the work, which represents both a
design team consensus as well as a proposal for adoption into the ANCP
protocol spec, draft-ietf-ancp-protocol (some editorial work will be
still required). Please review the proposal and share your comments. We
will assume acceptance of the proposal in principle otherwise.

Regards,
Woj & Matthew.


2       Replication Control Message


This message is sent by the ANCP Server (NAS) to the ANCP Client (AN)
with a directive to either add (join) or delete (leave) a port to or
from a multicast flow. Its format is as follow:
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9= 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     |Type=3DReplication-Control (0x01)|   = ;          Length  &n= bsp;         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | 0x01 (Access-Loop-Circuit-ID) |   = ;     Client-ID Length     &nbs= p; |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     |        &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;    |
     ~        &= nbsp;            = ; Port Client-ID          =             &nbs= p;    ~
     |        &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+

Following the Port Client-ID information, one or more Command TLV
components can be included and the Access Node should process them in
the order in which they are listed. The Access Node (ANCP Client) should threat all the commands as a single command block to be viewed as a
whole and bail out immediately when one of them fails.
The format of command TLV is as follow:

      0       &= nbsp;           1 &nb= sp;            &= nbsp;    2        &nb= sp;          3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9= 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     |  Type =3D CommandCode    =        |      &n= bsp;   Length         = ;      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | Addr Family   | Encoding Type | &= nbsp;Multicast Group Address      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | Addr Family   | Encoding Type | &= nbsp;Multicast Source Address     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+

Where CommandCode specifies the command and can be one of the following:
0x01  Add       Adds the specified multi= cast flow to the specified port
(join)
0x02  Delete    Deletes the specified multicast flow (l= eave) on the
specified port.
0x04  DeleteAll Deletes All multicast flow on the specified port (leav= e
all). No addresses are supplied.

When we have more than one command, Deletes should always be listed
first. The unicast source address/mask follows the format defined in RFC 2362 Section 4.1 case 1 which is duplicated here for quick review:

Encoded-Unicast-address: Takes the following format:

  0           &= nbsp;       1     &nb= sp;            &= nbsp;2            &nb= sp;      3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Addr Family   | Encoding Type |     U= nicast Address           |=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Addr Family
           The addre= ss family of the `Unicast Address' field  of
           this addr= ess.

          Here is the add= ress family numbers assigned by IANA:

 Number    Description
 --------  ------------------------------------------------------= ---
      0    Reserved
      1    IP (IP version 4)       2    IP6 (IP version 6)<= BR>       3    NSAP
      4    HDLC (8-bit multidr= op)
      5    BBN 1822
      6    802 (includes all 8= 02 media plus Ethernet "canonical format")
      7    E.163
      8    E.164 (SMDS, Frame = Relay, ATM)
      9    F.69 (Telex)
     10    X.121 (X.25, Frame Relay= )
     11    IPX
     12    Appletalk
     13    Decnet IV
     14    Banyan Vines
     15    E.164 with NSAP format s= ubaddress

     Encoding Type
          The type of enc= oding used within a specific Address
          Family.  T= he value `0' is reserved for this field,
          and represents = the native encoding of the Address
          Family.

     Unicast Address
          The unicast add= ress as represented by the given
          Address Family = and Encoding Type.

Finally, although the length could be derived from the Addr Family and
the Encoding type, it is kept for future possible extension to this
command where other entry would be added to this command segment.
The equivalent of a swap command where the NAS would want to switch from multicast group 239.23.2.2 to 239.55.3.2 will have the following format:
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9= 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     |        T= ype (0x88-0C)         |   =         Length    &nb= sp;         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | Vers  |  Sub  |MessageType=3D9= 0 | Result|        Code    = ;       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | Partition ID  |    &nbs= p;       Transaction Identifier =3D 0001 &n= bsp;    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     |I|      SubMessage = Number      |       &= nbsp;   Length        &nbs= p;     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | 0x01 (Replication-Control)   &nbs= p;|             = Length            |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | 0x01 (Access-Loop-Circuit-ID) |   = ;     Client-ID Length     &nbs= p; |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     |        &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;    |
     ~        &= nbsp;            = ; Port Client-ID          =             &nbs= p;    ~
     |        &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | Type=3DCommandCode: Delete(0x02)|   = ;        Length    &n= bsp;         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | AddrFamily 01 | EncType 0x0   | &= nbsp;Mcast group: 239.23.2.2      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-|
     | AddrFamily 01 | EncType 0x0   | &= nbsp;Mcast Source: 10.1.1.1       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-|
     | Type=3DCommandCode: Add (0x01)  |  =          Length   &nb= sp;          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | AddrFamily 01 | EncType 0x0   | &= nbsp;Mcast group: 239.55.3.2      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-|
     | AddrFamily 01 | EncType 0x0   | &= nbsp;Mcast Source: 10.1.1.1       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-|

Each command in the list is attributed an identification number based on its occurrence in the message. In this case, the Delete command will be
attributed command number 1 while the Add will be attributed command
number 2. During the processing of these  commands, upon the first
failure of a command, the sequence is interrupted and an error message
(via Multicast Status Message) will be returned with the command number
identifying the command that failed.

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www.ietf.org/mailman/listinfo/ancp

_____________________________________________= __
ANCP mailing list
ANCP@ietf.org
https://www.ietf.org/mailman/listinfo/ancp

Please do not print this email unless it is absol= utely necessary.

 The information contained in this electronic message and any attachme= nts to this message are intended for the exclusive use of the addressee(s) a= nd may contain proprietary, confidential or privileged information. If you a= re not the intended recipient, you should not disseminate, distribute or cop= y this e-mail. Please notify the sender immediately and destroy all copies o= f this message and any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient shoul= d check this email and any attachments for the presence of viruses. The comp= any accepts no liability for any damage caused by any virus transmitted by t= his email.

www.wipro.com


--
Einar Nilsen-Nygaard
Technical Leader, Cisco

Clothes make the man. Naked people have little or no influence on
society. --Mark Twain

 --B_3291659227_17479407-- --===============0693217224== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============0693217224==-- From ancp-bounces@ietf.org Mon Apr 21 15:03:28 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 309A93A6D60; Mon, 21 Apr 2008 15:03:28 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 983E13A6924 for ; Mon, 21 Apr 2008 15:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ut-83BjLf1OV for ; Mon, 21 Apr 2008 15:03:21 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 509723A69E5 for ; Mon, 21 Apr 2008 15:03:21 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 21 Apr 2008 15:03:27 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3LM3Rn4001697; Mon, 21 Apr 2008 15:03:27 -0700 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3LM3R6i023509; Mon, 21 Apr 2008 22:03:27 GMT Received: (from eckert@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA06818; Mon, 21 Apr 2008 15:00:43 -0700 (PDT) Date: Mon, 21 Apr 2008 15:00:43 -0700 From: Toerless Eckert To: Einar Nilsen-Nygaard Message-ID: <20080421220043.GI175@cisco.com> References: Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=23552; t=1208815407; x=1209679407; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=eckert@cisco.com; z=From:=20Toerless=20Eckert=20 |Subject:=20Re=3A=20[ANCP]=20ANCP=20Multicast=20Control=20M essage |Sender:=20; bh=cn0cEPuotEz0qq88YXFj0StuNTwqoT8sBRVuqwZpam0=; b=pCeW4/xsCmvmeWCsEGSvLjYK/AR7UdSpWgEBullwVtzb/xKHhvDlSMlDkp Bl25itg2eBIcEZtrh1ARgVV3Hst5vcPRTyieJZtOdZs+7Rup3j8s6WCcPFWA JvZi/j9H+D; Authentication-Results: sj-dkim-2; header.From=eckert@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: ancp@ietf.org Subject: Re: [ANCP] ANCP Multicast Control Message X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Some comments: a) Please change the name of the two 'Length' fields in the = control mesages sucht hat they can be differentiated easier from another and specify what is counted in them, eg: Type=3DReplication-Control (0x01)| Length | ^^^^^^ = suggest to change to RC-Length, explanation "total number of bytes of the following TLVs plus the replication control header". Type =3D CommandCode | Length | ^^^^^^ suggest to change to CC-Length, explanation "total number of = this CommandCode TLV, counting this header and the following multicast flow bytes". b) Please try to avoid using the term "group" when referring to an address which is either an ASM (Any Source Multicast) group address (aka: a single multicast group address, IPv4 or IPv6) or an SSM channel (aka: source and group address). I would stroingly suggest to only use the term "multicast flow" or multicast flow address, or just "flow", and define that term in the beginning of the document to be either an ASN group or SSM channel. Otherwise there will be lots of confusions about whether or not SSM is well supported by ANCP. c) Do not refer to rfc2362. That RFC is obsolete and replaced by rfc4601. I do not see a good reason to refer to any PIM spec anyhow, just resolve the references used within the PIM-SM spec, eg: http://www.iana.org/assignments/address-family-numbers or the like. d) To identify an actual SSM channel, it would be preferrable IMHO to have an address family identifier for an SSM channel, aka: an IP(v6/v6) source IP address followed by a group address. As above IANA URL has nothing like this defined, i think there are two choices: -> I) I'll check what effort it is to get that defined through IANA. -> II) we stick with the existing specification, which is to have a separate field addrfamily/encoding/group and one addrfamily/encoding/source, but then i would very much like to see very explicit description in the protocol spec what sequeneces of addfamily/encoding/addr (AEA) elements are valid, and how they have to be interpreted: for add/delete commands: -> MUST support a single AEA argument where the address is an IPv4/IPv6 address that is a multicast group. (ASM case). -> MUST support TWO AEA argument where the address of the first AEA is an IPv4/IPv6 address which is a unicast address, and the second AEA is an IPv4/IPv6 address which is a multicast address. Aka: SSM case. = In the example text i see two things i am questioning: I) The (S,G) channels are encoded first group and then source. That IMHO is not preferrable. I would rather suggest like written above to encode first source and then group. = II) The text is suggesting to have eg: multiple group AEA following an add/delete TLV. I have no strong opinion whether or not that should be supported, but if we conclude it should be supported, then that should explicitly be mentioned in the text (see also below). And that description would then of course have to detail a bit how a list of AEAs with ASM groups and SSM channels is to be encoded. Particularily this case makes it of course important to either be very clear how an SSM channel is encoded (source first or group first), or even better use a separate Address-Familty identifier as suggested above. e) I do not see any suggestion on the command reply. Is there supposed to be some failure and/or success return codes ? f) As far as return codes are concerned: I would like to see some clearer statement about the suggested atomicity (if that's a valid english word ;-) of the execution of multiple flows within a single add/delete/modify TLV as well as the flows across multiple TLVs within the same replication control message. -> What happens if any individual flow add/delete fails ? The document right now only seems to imply that the execution of the following add/deletes is simply not executed. That by itself would require the NAS to either query all state to figure out what actually was executed or to simply try everything again. If we would add a return code like the following, that would not be necessary: = "Sorry, error: all flows up to byte XX into the packet where performed well, and the following flow failed to be addeded/deleted, and the rest was not even tried" = I am not sure if this type of error return is the preferred solution, but if we do not mandate something better, then it probably should be done. = -> A better solution would be to imply some form of atomicity, eg: either at TLV or at replication control level. Meaning: the AN tries to execute add/delete/modifies, but if anything fails, then everything is undone. Or better: Nothing is applied by the AN unless it can make sure everything will succeed. g) Atomicity is a hard bargain for the control/forwarding plane of a router/switch/DSLAM i think. If there is a bunch of add/delete/modi= fy and all of those should only be applied if all of them will succeed... good luck getting that actually implemented correctly in the forwarding plane of any AN. The thing i could see us asking to be done atomically is really JUST a single flow-swap, aka: replace exactly one flow with another flow. = So ultimately, i think: -> For add/delete commands we ask for no atomicity and the error code returned should somehow point to the first flow within a packet that failed. And provide some additional error code why (which we could define the values for later). And this should allow us to have multiple flows as arguments to a single add/delete to be more efficient. = -> a modify should be called "swap", and should support only = exactly two flows as the argument. This swap should work atomically, aka: the join would not be executed if the leave could not be done, and the leave should of course not be executed if the join would not work. = -> So maybe overall the error return code would be = command#, flow#, why where command# would be pointing to the command (numbered 1 t N) within the recplication control command that failed, flow# would be the flow (1..M) within that command (always 1 for a swap, as we only allow a single flow there), and why would be some eg: 8-bit error code where we could define values for that would help diagnosis. h) The degree to which a platform is able to implement even this most simple atomic swap is of course subject to implementation. Cheers Toerless = On Mon, Apr 21, 2008 at 09:47:06PM +0100, Einar Nilsen-Nygaard wrote: > Vish, > = > I actually think that freedom in how a =B3swap=B2 operation would be impl= emented > in terms of the ordering of stopping the first multicast flow and starting > the second is not desirable. By specifying that the delete must come befo= re > the add and that the operation should be terminated upon the first error, > the current specification gives us what should be deterministic behavior > between any and all conforming implementations. > = > In contrast, the freedom to implement a swap operation via some form of > modify leaves the door open to multiple ways in which a modify request co= uld > fail, making error recovery more troublesome and vendor-specific which I = do > not see as at all desirable. > = > Cheers, > = > Einar > = > On 21/04/2008 20:12, "vishwanathan.sundaram@wipro.com" > scribbled: > = > > Einar, > > Modify command would be usefull from Access box perspective, as the und= erlying > > implementation in AN's would have the freedom to design their swap oper= ation, > > instead of always first deleting the existing group entry and adding an= other > > entry. > > = > > Thanks > > Vish > > = > > = > > = > > From: einarnn [mailto:einarnn@cisco.com] > > Sent: Sun 4/20/2008 11:12 AM > > To: Vishwanathan Somasundaram (WT01 - TES-Access Networks); wdec@cisco.= com; > > ancp@ietf.org > > Subject: Re: [ANCP] ANCP Multicast Control Message > > = > > Vish, > > = > > Overloading the second byte of the command code to contain the number of > > =B3modifications=B2 doesn=B9t seem a good approach and the space saving= per packet, > > which will probably be only 4 bytes most of the time, seems almost irre= levant. > > I think it would be better to keep the fields in the message for a sing= le > > task. > > = > > Treating a sequence of commands as an atomic operation, as detailed in = the > > text, and implementing a swap via a delete follow by an add, should giv= e ANs > > the freedom to implement what are, in effect, swap operations quite > > efficiently. In this context, I=B9m not sure what a =B3modify=B2 comman= d code will > > really add? > > = > > Cheers, > > = > > Einar > > = > > On 16/04/2008 15:41, "vishwanathan.sundaram@wipro.com" > > wrote: > > = > >> Hi Woj, > >> Currently, the command codes for replication control message are > >> 1. add (0x01) > >> 2. delete (0x02) > >> 3. delete all (0x04). > >> = > >> Looking at the multicast Swap message format, which is used when the N= AS > >> wants to switch from one group to another,can we not handle this situa= tion by > >> having a message type Modify (0x08). > >> By using this message type we can mention the multicast group address = which > >> needs to be swapped by new multicast group address. > >> Since the Command Code is 2 bytes, the second byte can be used to ment= ion the > >> number of multicast groups that needs to be swapped. > >> This will allow, for multiple multicast group swaps. This will also re= duce > >> the size of the packet. Since these messages intended only between the= NAS > >> and AN, the introduction of modify command type gives further ease to = the > >> Access boxes in implementing the swaps, which attributes to zap latenc= y. > >> = > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Type (0x88-0C) | Length | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Vers | Sub |MessageType=3D90 | Result| Code = | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Partition ID | Transaction Identifier =3D 0001 = | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> |I| SubMessage Number | Length | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | 0x01 (Replication-Control) | Length | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | 0x01 (Access-Loop-Circuit-ID) | Client-ID Length | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | | > >> ~ Port Client-ID ~ > >> | | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Type=3DCommandCode: Modify(0x08)| Length > >> | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | AddrFamily 01 | EncType 0x0 | Mcast group: 239.23.2.2 = | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > >> | AddrFamily 01 | EncType 0x0 | Mcast Source: 10.1.1.1 > >> | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > >> | AddrFamily 01 | EncType 0x0 | New Mcast group: 239.55.3.2 = | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > >> | AddrFamily 01 | EncType 0x0 | New Mcast Source: 10.1.1.1 = | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > >> = > >> Looking into the DSL TR 101, it also discusses about the multicast flo= w being > >> associated with a VLAN (Multicast-Vlan). In this case, the Access Node= , needs > >> to be informed about the VLAN ID on which a particular Multicast group= is > >> being associated by the NAS. Can this information also be added as par= t of > >> the TLV in message. > >> = > >> Thanks > >> Vish > >> = > >> = > >> From: ancp-bounces@ietf.org on behalf of Wojciech Dec (wdec) > >> Sent: Mon 4/14/2008 11:00 AM > >> To: ancp@ietf.org > >> Subject: [ANCP] ANCP Multicast Control Message > >> = > >> = > >> = > >> Hi All, > >> = > >> As discussed during our recent IETF 71 meeting, our protocol design te= am > >> has forged ahead with prioritized list of problems to address, the fir= st > >> of which was defining the ANCP message extensions for multicast contro= l, > >> aka unsolicited multicast control. The DT is working on the response > >> message and also the solicited multicast control mode. > >> Below, we present the outcome of the work, which represents both a > >> design team consensus as well as a proposal for adoption into the ANCP > >> protocol spec, draft-ietf-ancp-protocol (some editorial work will be > >> still required). Please review the proposal and share your comments. We > >> will assume acceptance of the proposal in principle otherwise. > >> = > >> Regards, > >> Woj & Matthew. > >> = > >> = > >> 2 Replication Control Message > >> = > >> = > >> This message is sent by the ANCP Server (NAS) to the ANCP Client (AN) > >> with a directive to either add (join) or delete (leave) a port to or > >> from a multicast flow. Its format is as follow: > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> |Type=3DReplication-Control (0x01)| Length = | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | 0x01 (Access-Loop-Circuit-ID) | Client-ID Length | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | | > >> ~ Port Client-ID ~ > >> | | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> = > >> Following the Port Client-ID information, one or more Command TLV > >> components can be included and the Access Node should process them in > >> the order in which they are listed. The Access Node (ANCP Client) shou= ld > >> threat all the commands as a single command block to be viewed as a > >> whole and bail out immediately when one of them fails. > >> The format of command TLV is as follow: > >> = > >> 0 1 2 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Type =3D CommandCode | Length = | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Addr Family | Encoding Type | Multicast Group Address | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Addr Family | Encoding Type | Multicast Source Address | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> = > >> Where CommandCode specifies the command and can be one of the followin= g: > >> = > >> 0x01 Add Adds the specified multicast flow to the specified port > >> (join) > >> 0x02 Delete Deletes the specified multicast flow (leave) on the > >> specified port. > >> 0x04 DeleteAll Deletes All multicast flow on the specified port (leave > >> all). No addresses are supplied. > >> = > >> When we have more than one command, Deletes should always be listed > >> first. The unicast source address/mask follows the format defined in R= FC > >> 2362 Section 4.1 case 1 which is duplicated here for quick review: > >> = > >> Encoded-Unicast-address: Takes the following format: > >> = > >> 0 1 2 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Addr Family | Encoding Type | Unicast Address | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> = > >> Addr Family > >> The address family of the `Unicast Address' field of > >> this address. > >> = > >> Here is the address family numbers assigned by IANA: > >> = > >> Number Description > >> -------- --------------------------------------------------------- > >> 0 Reserved > >> 1 IP (IP version 4) > >> 2 IP6 (IP version 6) > >> 3 NSAP > >> 4 HDLC (8-bit multidrop) > >> 5 BBN 1822 > >> 6 802 (includes all 802 media plus Ethernet "canonical format= ") > >> 7 E.163 > >> 8 E.164 (SMDS, Frame Relay, ATM) > >> 9 F.69 (Telex) > >> 10 X.121 (X.25, Frame Relay) > >> 11 IPX > >> 12 Appletalk > >> 13 Decnet IV > >> 14 Banyan Vines > >> 15 E.164 with NSAP format subaddress > >> = > >> Encoding Type > >> The type of encoding used within a specific Address > >> Family. The value `0' is reserved for this field, > >> and represents the native encoding of the Address > >> Family. > >> = > >> Unicast Address > >> The unicast address as represented by the given > >> Address Family and Encoding Type. > >> = > >> Finally, although the length could be derived from the Addr Family and > >> the Encoding type, it is kept for future possible extension to this > >> command where other entry would be added to this command segment. > >> The equivalent of a swap command where the NAS would want to switch fr= om > >> multicast group 239.23.2.2 to 239.55.3.2 will have the following forma= t: > >> = > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Type (0x88-0C) | Length | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Vers | Sub |MessageType=3D90 | Result| Code = | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Partition ID | Transaction Identifier =3D 0001 = | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> |I| SubMessage Number | Length | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | 0x01 (Replication-Control) | Length | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | 0x01 (Access-Loop-Circuit-ID) | Client-ID Length | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | | > >> ~ Port Client-ID ~ > >> | | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Type=3DCommandCode: Delete(0x02)| Length = | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | AddrFamily 01 | EncType 0x0 | Mcast group: 239.23.2.2 | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > >> | AddrFamily 01 | EncType 0x0 | Mcast Source: 10.1.1.1 | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > >> | Type=3DCommandCode: Add (0x01) | Length = | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | AddrFamily 01 | EncType 0x0 | Mcast group: 239.55.3.2 | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > >> | AddrFamily 01 | EncType 0x0 | Mcast Source: 10.1.1.1 | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > >> = > >> Each command in the list is attributed an identification number based = on > >> its occurrence in the message. In this case, the Delete command will be > >> attributed command number 1 while the Add will be attributed command > >> number 2. During the processing of these commands, upon the first > >> failure of a command, the sequence is interrupted and an error message > >> (via Multicast Status Message) will be returned with the command number > >> identifying the command that failed. > >> = > >> _______________________________________________ > >> ANCP mailing list > >> ANCP@ietf.org > >> https://www.ietf.org/mailman/listinfo/ancp > >> = > >> = > >> _______________________________________________ > >> ANCP mailing list > >> ANCP@ietf.org > >> https://www.ietf.org/mailman/listinfo/ancp > > = > > Please do not print this email unless it is absolutely necessary. > > = > > The information contained in this electronic message and any attachmen= ts to > > this message are intended for the exclusive use of the addressee(s) and= may > > contain proprietary, confidential or privileged information. If you are= not > > the intended recipient, you should not disseminate, distribute or copy = this > > e-mail. Please notify the sender immediately and destroy all copies of = this > > message and any attachments. > > = > > WARNING: Computer viruses can be transmitted via email. The recipient s= hould > > check this email and any attachments for the presence of viruses. The c= ompany > > accepts no liability for any damage caused by any virus transmitted by = this > > email. = > > = > > www.wipro.com = > > = > > = > > -- = > > Einar Nilsen-Nygaard > > Technical Leader, Cisco > > = > > Clothes make the man. Naked people have little or no influence on > > society. --Mark Twain > > = > = > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp -- = --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture "The strategy is what you do, not what you write" - Wesley Clark _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Apr 22 06:36:14 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8942428C101; Tue, 22 Apr 2008 06:36:14 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79E1E28C1C4 for ; Tue, 22 Apr 2008 06:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bo+fe3srs9JN for ; Tue, 22 Apr 2008 06:36:07 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 100413A68F5 for ; Tue, 22 Apr 2008 06:36:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,693,1199660400"; d="scan'208,217";a="6987278" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 22 Apr 2008 15:36:10 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3MDaAKL017121 for ; Tue, 22 Apr 2008 15:36:10 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3MDa9B1028972 for ; Tue, 22 Apr 2008 13:36:10 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Apr 2008 15:36:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Apr 2008 15:35:51 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANCP message length field thread-index: AcikfcgluibF+DjWTfupYAEgs2PQXQ== From: "Wojciech Dec (wdec)" To: X-OriginalArrivalTime: 22 Apr 2008 13:36:09.0713 (UTC) FILETIME=[D2F3F610:01C8A47D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10741; t=1208871370; x=1209735370; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20ANCP=20message=20length=20field |Sender:=20; bh=PRHhEsyI4NLff5V8GZG+QCEQL/A4espcxjxYvIh4Qd4=; b=vPprWf+Uq7xHzV5lHTHfGhbPYCshoA7F6csJiUrr+xOfsjBIlH24GfoHTS ckq13i3tRsIwehj5C36H0QH52TDhzdW74jy6YxZ+OlLBb1mv02xFi4XpZYo6 YP0n4hXaZB; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [ANCP] ANCP message length field X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1354216084==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1354216084== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A47D.D2D10902" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A47D.D2D10902 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, As part of our GSMP legacy we've inherited some base protocol header fields that, for lack of a better word, are largely useless for ANCP. An example of such a field are the dual message Length field deriving from rfc3292 and rfc3293, both of which in ANCP carry the same value (it's not at all clear why rfc3293 needed such a field, but that's a different story). This is shown in more detail below in the form of an ANCP header: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x88-0C) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Vers | Sub |MessageType | Result| Code |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Partition ID | Transaction Identifier |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |I| SubMessage Number | Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 RFC 3293 defines the first "Length" field to be: This 2-byte unsigned integer indicates the total length of the GSMP message only. It does not include the 4-byte TLV header. RFC 3292 defines the second "Length" field to be: Length of the GSMP message including its header fields and defined GSMP message body. The length of additional data appended to the end of the standard message SHOULD be included in the Length field. It's thus quite clear that the two fields, in ANCP's case, carry the same value and it appears reasonable to think of possible changes:. Proposal 1.=20 The "additional data" possibility is to be dropped. There appears to be no reason to transmit non ANCP data in ANCP. Proposal 2 - Option a. Re-define the Sub-message Number and Length fields to convey really a Sub-message Number and Sub-Message Length, and allow multiple commands to be bundled under the same transaction header, which appears interesting in the perspective of multicast control, and line configuration use-cases. Backwards compatibility with existing implementations could be maintained since currently all ANCP's applications set the I flag to "0". Implementations supporting this change, would most likely be required to send the so-far commonly implemented Port-up/down and OAM "legacy" messages with the I flag set to "1". Proposal 2 Option b. Instead of using the Sub-message number and 2nd Length fields, we define these to be reserved fields of no use in ANCP. Proposal 2 Option c. Define the 1st Length field to be reserved fields of no use in ANCP, using instead only the Sub Message and Length fields to stitch together ANCP messages that go over 64kb boundary. Proposal 2 Option d Continue using both fields as today, but refine the Sub-message and Length field to allow for messages over 64kb. I solicit the WG's feedback regarding these proposed changes. Regards, Woj. ------_=_NextPart_001_01C8A47D.D2D10902 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ANCP message length field

Hi = Folks,

As part of our = GSMP legacy we've inherited some base protocol header fields that, for = lack of a better word, are largely useless for ANCP. An example of such = a field are the dual message Length field deriving from rfc3292 and = rfc3293, both of which in ANCP carry the same value (it's not at all = clear why rfc3293 needed such a field, but that's a different story). = This is shown in more detail below in the form of an ANCP = header:


      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 = 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /SPAN>
     = |        Type = (0x88-0C)         = |           = Length           &= nbsp;  |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
     | Vers  |  Sub  = |MessageType    | = Result|        = Code           | =
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
     | Partition ID  = |            = Transaction = Identifier          &nb= sp;  |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
     |I|      = SubMessage Number      = |           = Length           &= nbsp;  |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

RFC 3293 defines = the first "Length" field to be:       This 2-byte unsigned integer = indicates the total length of the
      GSMP message = only.  It does not include the 4-byte TLV header.


RFC 3292 defines = the second "Length" field to be: Length of the GSMP message = including its header fields and
         defined = GSMP message body.  The length of additional data
         appended = to the end of the standard message SHOULD be included
         in the = Length field.

It's thus quite = clear that the two fields, in ANCP's case, carry the same value and it = appears reasonable to think of possible changes:.

Proposal 1. =
The = "additional data" possibility is to be dropped. There appears = to be no reason to transmit non ANCP data in ANCP.

Proposal 2 - = Option a.
Re-define the = Sub-message Number and Length fields to convey really a Sub-message = Number and Sub-Message Length, and allow multiple commands to be bundled = under the same transaction header, which appears interesting in the = perspective of multicast control, and line configuration use-cases. = Backwards compatibility with existing implementations could be = maintained since currently all ANCP's applications set the I flag to = "0". Implementations supporting this change, would most likely = be required to send the so-far commonly implemented Port-up/down and OAM = "legacy" messages with the I flag set to = "1".

Proposal 2 Option = b.
Instead of using = the Sub-message number and 2nd Length fields, we define these to be = reserved fields of no use in ANCP.

Proposal 2 Option = c.
Define the 1st = Length field to be reserved fields of no use in ANCP, using instead only = the Sub Message and Length fields to stitch together ANCP messages that = go over 64kb boundary.

Proposal 2 Option = d
Continue using = both fields as today, but refine the Sub-message and Length field to = allow for messages over 64kb.

I solicit the WG's = feedback regarding these proposed changes.

Regards,
Woj.

------_=_NextPart_001_01C8A47D.D2D10902-- --===============1354216084== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============1354216084==-- From ancp-bounces@ietf.org Tue Apr 22 08:29:34 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F1DC28C2B9; Tue, 22 Apr 2008 08:29:34 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0106428C260 for ; Tue, 22 Apr 2008 08:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.477 X-Spam-Level: X-Spam-Status: No, score=-0.477 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994, SARE_UNSUB18=0.131] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXL2jnaFvdUT for ; Tue, 22 Apr 2008 08:29:15 -0700 (PDT) Received: from wipro-blr-out01.wipro.com (wipro-blr-out01.wipro.com [203.91.198.74]) by core3.amsl.com (Postfix) with ESMTP id 7438D28C2C6 for ; Tue, 22 Apr 2008 08:29:14 -0700 (PDT) X-AuditID: cb5bdd57-a9e3bbb000002680-6b-480e044d1cad Received: from blr-ec-bh02.wipro.com (unknown [10.201.50.92]) by wipro-blr-out01.wipro.com (Symantec Mail Security) with ESMTP id C8E024E4006 for ; Tue, 22 Apr 2008 20:59:17 +0530 (IST) Received: from BLR-EC-MBX07.wipro.com ([10.201.52.181]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Apr 2008 20:58:57 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Apr 2008 20:58:56 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP Multicast Control Message Thread-Index: AcieEVmGGiNqxJsfTu6YY/jux+SZrwALfVfQAGQoukUAyjyKeQA4wnvxAAU7juUAImX8jw== References: From: To: , , X-OriginalArrivalTime: 22 Apr 2008 15:28:57.0087 (UTC) FILETIME=[949F48F0:01C8A48D] X-Brightmail-Tracker: AAAAAA== Subject: Re: [ANCP] ANCP Multicast Control Message X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1778972288==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1778972288== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A48D.944ABEC9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A48D.944ABEC9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Einar, =20 In case of swap operation implemented by delete/add, if any one of them = fails, some kind of error message has to be sent towards the NAS and the = AN should not apply the changes partially also. Since the AN processes = each message independtly, it might first delete a multicast flow and = later while adding a flow if it encounters problems, it would try to = revert back the delete operation which means the AN has to maintain some = state of the command executed. Otherwise it might be required for the AN = to scan the packet to see if there is sequence of delete/add operation = to determine its a swap. =20 In case of modify command code, the AN need not maintain the state of = previous command executed as it knows if changing multicast flow fails = it can easily revert back to original without any state information. As = for the error message it can still be the same as in previous case of = delete/add, similar kind of error message can be sent in response to the = NAS indicating swap operation failed. By having the modify option it is = going to make the swap operation independent and sequencing the command = codes need not be considered for swap operations. =20 =20 Cheers Vish ________________________________ From: Einar Nilsen-Nygaard [mailto:einarnn@cisco.com] Sent: Mon 4/21/2008 4:47 PM To: Vishwanathan Somasundaram (WT01 - TES-Access Networks); = wdec@cisco.com; ancp@ietf.org Subject: Re: [ANCP] ANCP Multicast Control Message Vish, I actually think that freedom in how a "swap" operation would be = implemented in terms of the ordering of stopping the first multicast = flow and starting the second is not desirable. By specifying that the = delete must come before the add and that the operation should be = terminated upon the first error, the current specification gives us what = should be deterministic behavior between any and all conforming = implementations. In contrast, the freedom to implement a swap operation via some form of = modify leaves the door open to multiple ways in which a modify request = could fail, making error recovery more troublesome and vendor-specific = which I do not see as at all desirable. Cheers, Einar On 21/04/2008 20:12, "vishwanathan.sundaram@wipro.com" = scribbled: Einar, Modify command would be usefull from Access box perspective, as the = underlying implementation in AN's would have the freedom to design their = swap operation, instead of always first deleting the existing group = entry and adding another entry. =09 Thanks Vish =09 =09 =09 ________________________________ From: einarnn [mailto:einarnn@cisco.com] Sent: Sun 4/20/2008 11:12 AM To: Vishwanathan Somasundaram (WT01 - TES-Access Networks); = wdec@cisco.com; ancp@ietf.org Subject: Re: [ANCP] ANCP Multicast Control Message =09 Vish, =09 Overloading the second byte of the command code to contain the number = of "modifications" doesn't seem a good approach and the space saving per = packet, which will probably be only 4 bytes most of the time, seems = almost irrelevant. I think it would be better to keep the fields in the = message for a single task. =09 Treating a sequence of commands as an atomic operation, as detailed in = the text, and implementing a swap via a delete follow by an add, should = give ANs the freedom to implement what are, in effect, swap operations = quite efficiently. In this context, I'm not sure what a "modify" command = code will really add? =09 Cheers, =09 Einar =09 On 16/04/2008 15:41, "vishwanathan.sundaram@wipro.com" = wrote: =09 =09 Hi Woj, Currently, the command codes for replication control message are 1. add (0x01) 2. delete (0x02) 3. delete all (0x04). =09 Looking at the multicast Swap message format, which is used when the = NAS wants to switch from one group to another,can we not handle this = situation by having a message type Modify (0x08). By using this message type we can mention the multicast group address = which needs to be swapped by new multicast group address. Since the Command Code is 2 bytes, the second byte can be used to = mention the number of multicast groups that needs to be swapped. This will allow, for multiple multicast group swaps. This will also = reduce the size of the packet. Since these messages intended only = between the NAS and AN, the introduction of modify command type gives = further ease to the Access boxes in implementing the swaps, which = attributes to zap latency. =09 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x88-0C) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub |MessageType=3D90 | Result| Code = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier =3D 0001 = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 (Replication-Control) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 (Access-Loop-Circuit-ID) | Client-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Port Client-ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=3DCommandCode: Modify(0x08)| Length = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast group: 239.23.2.2 = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | AddrFamily 01 | EncType 0x0 | Mcast Source: 10.1.1.1 = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | AddrFamily 01 | EncType 0x0 | New Mcast group: 239.55.3.2 = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | AddrFamily 01 | EncType 0x0 | New Mcast Source: 10.1.1.1 = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| =09 Looking into the DSL TR 101, it also discusses about the multicast = flow being associated with a VLAN (Multicast-Vlan). In this case, the = Access Node, needs to be informed about the VLAN ID on which a = particular Multicast group is being associated by the NAS. Can this = information also be added as part of the TLV in message. =09 Thanks Vish =09 =09 ________________________________ From: ancp-bounces@ietf.org on behalf of Wojciech Dec (wdec) Sent: Mon 4/14/2008 11:00 AM To: ancp@ietf.org Subject: [ANCP] ANCP Multicast Control Message =09 =09 =09 Hi All, =09 As discussed during our recent IETF 71 meeting, our protocol design = team has forged ahead with prioritized list of problems to address, the = first of which was defining the ANCP message extensions for multicast = control, aka unsolicited multicast control. The DT is working on the response message and also the solicited multicast control mode. Below, we present the outcome of the work, which represents both a design team consensus as well as a proposal for adoption into the ANCP protocol spec, draft-ietf-ancp-protocol (some editorial work will be still required). Please review the proposal and share your comments. = We will assume acceptance of the proposal in principle otherwise. =09 Regards, Woj & Matthew. =09 =09 2 Replication Control Message =09 =09 This message is sent by the ANCP Server (NAS) to the ANCP Client (AN) with a directive to either add (join) or delete (leave) a port to or from a multicast flow. Its format is as follow: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=3DReplication-Control (0x01)| Length = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 (Access-Loop-Circuit-ID) | Client-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Port Client-ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 Following the Port Client-ID information, one or more Command TLV components can be included and the Access Node should process them in the order in which they are listed. The Access Node (ANCP Client) = should threat all the commands as a single command block to be viewed as a whole and bail out immediately when one of them fails. The format of command TLV is as follow: =09 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D CommandCode | Length = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Multicast Group Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Multicast Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 Where CommandCode specifies the command and can be one of the = following: =09 0x01 Add Adds the specified multicast flow to the specified = port (join) 0x02 Delete Deletes the specified multicast flow (leave) on the specified port. 0x04 DeleteAll Deletes All multicast flow on the specified port = (leave all). No addresses are supplied. =09 When we have more than one command, Deletes should always be listed first. The unicast source address/mask follows the format defined in = RFC 2362 Section 4.1 case 1 which is duplicated here for quick review: =09 Encoded-Unicast-address: Takes the following format: =09 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Unicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 Addr Family The address family of the `Unicast Address' field of this address. =09 Here is the address family numbers assigned by IANA: =09 Number Description -------- --------------------------------------------------------- 0 Reserved 1 IP (IP version 4) 2 IP6 (IP version 6) 3 NSAP 4 HDLC (8-bit multidrop) 5 BBN 1822 6 802 (includes all 802 media plus Ethernet "canonical = format") 7 E.163 8 E.164 (SMDS, Frame Relay, ATM) 9 F.69 (Telex) 10 X.121 (X.25, Frame Relay) 11 IPX 12 Appletalk 13 Decnet IV 14 Banyan Vines 15 E.164 with NSAP format subaddress =09 Encoding Type The type of encoding used within a specific Address Family. The value `0' is reserved for this field, and represents the native encoding of the Address Family. =09 Unicast Address The unicast address as represented by the given Address Family and Encoding Type. =09 Finally, although the length could be derived from the Addr Family and the Encoding type, it is kept for future possible extension to this command where other entry would be added to this command segment. The equivalent of a swap command where the NAS would want to switch = from multicast group 239.23.2.2 to 239.55.3.2 will have the following = format: =09 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x88-0C) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub |MessageType=3D90 | Result| Code = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier =3D 0001 = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 (Replication-Control) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 (Access-Loop-Circuit-ID) | Client-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Port Client-ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=3DCommandCode: Delete(0x02)| Length = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast group: 239.23.2.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | AddrFamily 01 | EncType 0x0 | Mcast Source: 10.1.1.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | Type=3DCommandCode: Add (0x01) | Length = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast group: 239.55.3.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | AddrFamily 01 | EncType 0x0 | Mcast Source: 10.1.1.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| =09 Each command in the list is attributed an identification number based = on its occurrence in the message. In this case, the Delete command will = be attributed command number 1 while the Add will be attributed command number 2. During the processing of these commands, upon the first failure of a command, the sequence is interrupted and an error message (via Multicast Status Message) will be returned with the command = number identifying the command that failed. =09 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp =09 =09 ________________________________ _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp =09 =09 Please do not print this email unless it is absolutely necessary.=20 =09 The information contained in this electronic message and any = attachments to this message are intended for the exclusive use of the = addressee(s) and may contain proprietary, confidential or privileged = information. If you are not the intended recipient, you should not = disseminate, distribute or copy this e-mail. Please notify the sender = immediately and destroy all copies of this message and any attachments.=20 =09 WARNING: Computer viruses can be transmitted via email. The recipient = should check this email and any attachments for the presence of viruses. = The company accepts no liability for any damage caused by any virus = transmitted by this email.=20 =09 www.wipro.com=20 =09 =09 --=20 Einar Nilsen-Nygaard Technical Leader, Cisco Clothes make the man. Naked people have little or no influence on society. --Mark Twain ------_=_NextPart_001_01C8A48D.944ABEC9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [ANCP] ANCP Multicast Control = Message=0A= =0A= =0A= =0A=
=0A=
 
=0A=
Einar,
=0A=
 
=0A=
In case of swap operation = implemented by delete/add, if any one of them fails, some kind of = error message has to be sent towards the NAS and the AN should not apply = the changes partially also. Since the AN processes each message = independtly, it might first delete a multicast flow and later while = adding a flow if it encounters problems, it would try to revert back the = delete operation which means the AN has to maintain some state of the = command executed. Otherwise it might be required for the AN to scan the = packet to see if there is sequence of delete/add operation to determine = its a swap.
=0A=
 
=0A=
In case of modify command = code, the AN need not maintain the state of previous command executed as = it knows if changing multicast flow fails it can easily revert back to = original without any state information. As for the error message it can = still be the same as in previous case of delete/add, similar kind of = error message can be sent in response to the NAS indicating swap = operation failed. By having the modify option it is going to make the = swap operation independent and sequencing the command codes need not be = considered for swap operations.
=0A=
 
=0A=
 
=0A=
Cheers
=0A=
Vish
=0A=

=0A=
=0A= From: Einar Nilsen-Nygaard = [mailto:einarnn@cisco.com]
Sent: Mon 4/21/2008 4:47 = PM
To: Vishwanathan Somasundaram (WT01 - TES-Access Networks); = wdec@cisco.com; ancp@ietf.org
Subject: Re: [ANCP] ANCP = Multicast Control Message

=0A=
Vish,

I actually think that freedom in how a = “swap” operation would be implemented in terms of the = ordering of stopping the first multicast flow and starting the second is = not desirable. By specifying that the delete must come before the = add and that the operation should be terminated upon the first error, = the current specification gives us what should be deterministic behavior = between any and all conforming implementations.

In contrast, the = freedom to implement a swap operation via some form of modify leaves the = door open to multiple ways in which a modify request could fail, = making error recovery more troublesome and vendor-specific which I do = not see as at all desirable.

Cheers,

Einar

On = 21/04/2008 20:12, "vishwanathan.sundaram@wipro.com" = <vishwanathan.sundaram@wipro.com> = scribbled:

=0A=
Einar,
Modify command would be usefull from Access box = perspective, as the underlying implementation in AN's would have the = freedom to design their swap operation, instead of always first deleting = the existing group entry and adding another entry.

Thanks
Vish


=0A=
=0A= From: = einarnn [mailto:einarnn@cisco.com]
Se= nt: Sun 4/20/2008 11:12 AM
To: Vishwanathan Somasundaram = (WT01 - TES-Access Networks); wdec@cisco.com; = ancp@ietf.org
Subject: Re: [ANCP] ANCP Multicast Control = Message

Vish,

Overloading the second byte of the command code to = contain the number of “modifications” doesn’t seem a = good approach and the space saving per packet, which will probably be = only 4 bytes most of the time, seems almost irrelevant. I think it would = be better to keep the fields in the message for a single = task.

Treating a sequence of commands as an atomic operation, as = detailed in the text, and implementing a swap via a delete follow by an = add, should give ANs the freedom to implement what are, in effect, swap = operations quite efficiently. In this context, I’m not sure what a = “modify” command code will really = add?

Cheers,

Einar

On 16/04/2008 15:41, = "vishwanathan.sundaram@wipro.com" = <vishwanathan.sundaram@wipro.com> = wrote:

=0A=
Hi Woj,
Currently, the command codes for = replication control message are
1. add (0x01)
2. delete = (0x02)
3. delete all (0x04).

Looking at the multicast Swap = message format, which is used when the NAS wants to switch from one = group to another,can we not handle this situation by having a message = type Modify (0x08).
By using this message type we can mention the = multicast group address which needs to be swapped by new multicast group = address.
Since the Command Code is 2 bytes, the second byte can be = used to mention the number of multicast groups that needs to be = swapped.
This will allow, for multiple multicast group swaps. This = will also reduce the size of the packet. Since these messages intended = only between the NAS and AN, the introduction of modify command type = gives further ease to the Access boxes in implementing the swaps, which = attributes to zap latency.

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 2 3 4 5 6 7 8 9 0 = 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+
     | =        Type (0x88-0C) =         | =           Length =             &= nbsp;|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Vers =  |  Sub  |MessageType=3D90 | Result| =        Code =           |
 &n= bsp;   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+
     | Partition ID  | =            Transac= tion Identifier =3D 0001 =      |
     +-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  =    |I|      SubMessage Number =      | =           Length =             &= nbsp;|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | 0x01 = (Replication-Control)    | =             L= ength =            |
&n= bsp;    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | 0x01 = (Access-Loop-Circuit-ID) | =        Client-ID Length =       |
     +-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 =     | =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ; |
     ~ =             &= nbsp;        Port Client-ID =             &= nbsp;           &n= bsp; ~
     | =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ; |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
     | = Type=3DCommandCode: Modify(0x08)| =           Length =             &= nbsp;           &n= bsp; |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | = AddrFamily 01 | EncType 0x0    |  Mcast group: = 239.23.2.2 =            |
&n= bsp;    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-|
     | AddrFamily 01 | = EncType 0x0    |  Mcast Source: 10.1.1.1 =             &= nbsp; |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     &= nbsp;| AddrFamily 01 | EncType 0x0   |  New Mcast = group: 239.55.3.2 =   |
     +-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
    &nb= sp;| AddrFamily 01 | EncType 0x0    |  New Mcast = Source: 10.1.1.1 =      |
     +-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|

Looking into the DSL TR 101, it = also discusses about the multicast flow being associated with a VLAN = (Multicast-Vlan). In this case, the Access Node, needs to be informed = about the VLAN ID on which a particular Multicast group is being = associated by the NAS. Can this information also be added as part of the = TLV in message.

Thanks
Vish

=0A=
=0A= From: ancp-bounces@ietf.org on behalf = of Wojciech Dec (wdec)
Sent: Mon 4/14/2008 11:00 = AM
To: ancp@ietf.org
Subject: [ANCP] ANCP Multicast = Control Message



Hi All,

As discussed during our recent IETF 71 = meeting, our protocol design team
has forged ahead with prioritized = list of problems to address, the first
of which was defining the ANCP = message extensions for multicast control,
aka unsolicited multicast = control. The DT is working on the response
message and also the = solicited multicast control mode.
Below, we present the outcome of = the work, which represents both a
design team consensus as well as a = proposal for adoption into the ANCP
protocol spec, = draft-ietf-ancp-protocol (some editorial work will be
still = required). Please review the proposal and share your comments. = We
will assume acceptance of the proposal in principle = otherwise.

Regards,
Woj & Matthew.


2 =       Replication Control = Message


This message is sent by the ANCP Server (NAS) to the = ANCP Client (AN)
with a directive to either add (join) or delete = (leave) a port to or
from a multicast flow. Its format is as = follow:
      0 1 2 3 4 5 6 7 8 9 0 1 2 = 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Type=3DRepl= ication-Control (0x01)| =             L= ength =            |
&n= bsp;    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | 0x01 = (Access-Loop-Circuit-ID) | =        Client-ID Length =       |
     +-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 =     | =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ; |
     ~ =             &= nbsp;        Port Client-ID =             &= nbsp;           &n= bsp; ~
     | =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ; |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Following the Port Client-ID = information, one or more Command TLV
components can be included and = the Access Node should process them in
the order in which they are = listed. The Access Node (ANCP Client) should
threat all the commands = as a single command block to be viewed as a
whole and bail out = immediately when one of them fails.
The format of command TLV is as = follow:

      0 =             &= nbsp;     1 =             &= nbsp;     2 =             &= nbsp;     3
     &nb= sp;0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type = =3D CommandCode =           | =          Length =             &= nbsp; |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |= Addr Family   | Encoding Type |  Multicast Group Address =      |
     +-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  =    | Addr Family   | Encoding Type | =  Multicast Source Address =     |
     +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where = CommandCode specifies the command and can be one of the = following:

0x01  Add =       Adds the specified multicast flow to = the specified port
(join)
0x02  Delete =    Deletes the specified multicast flow (leave) on = the
specified port.
0x04  DeleteAll Deletes All multicast = flow on the specified port (leave
all). No addresses are = supplied.

When we have more than one command, Deletes should = always be listed
first. The unicast source address/mask follows the = format defined in RFC
2362 Section 4.1 case 1 which is duplicated = here for quick review:

Encoded-Unicast-address: Takes the = following format:

  0 =             &= nbsp;     1 =             &= nbsp;     2 =             &= nbsp;     3
  0 1 2 3 4 5 6 7 8 9 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
 | Addr Family   | Encoding Type | =     Unicast Address =           |
 +-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

&n= bsp;    Addr = Family
          &nb= sp;The address family of the `Unicast Address' field =  of
          &= nbsp;this = address.

         &nb= sp;Here is the address family numbers assigned by = IANA:

 Number =    Description
 -------- =  ---------------------------------------------------------
 =      0 =    Reserved
      1 =    IP (IP version = 4)
      2    IP6 (IP = version 6)
      3 =    NSAP
      4 =    HDLC (8-bit = multidrop)
      5 =    BBN 1822
      6 =    802 (includes all 802 media plus Ethernet "canonical = format")
      7 =    E.163
      8 =    E.164 (SMDS, Frame Relay, = ATM)
      9    F.69 = (Telex)
     10    X.121 = (X.25, Frame Relay)
     11 =    IPX
     12 =    Appletalk
     13 =    Decnet IV
     14 =    Banyan Vines
     15 =    E.164 with NSAP format = subaddress

     Encoding = Type
          The = type of encoding used within a specific = Address
          Fa= mily.  The value `0' is reserved for this = field,
          and= represents the native encoding of the = Address
          Fa= mily.

     Unicast = Address
          Th= e unicast address as represented by the = given
          Addr= ess Family and Encoding Type.

Finally, although the length could = be derived from the Addr Family and
the Encoding type, it is kept for = future possible extension to this
command where other entry would be = added to this command segment.
The equivalent of a swap command where = the NAS would want to switch from
multicast group 239.23.2.2 to = 239.55.3.2 will have the following = format:

      0 1 2 3 4 5 6 7 8 9 0 = 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+
     | =        Type (0x88-0C) =         | =           Length =             &= nbsp;|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Vers =  |  Sub  |MessageType=3D90 | Result| =        Code =           |
 &n= bsp;   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+
     | Partition ID  | =            Transac= tion Identifier =3D 0001 =      |
     +-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  =    |I|      SubMessage Number =      | =           Length =             &= nbsp;|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | 0x01 = (Replication-Control)    | =             L= ength =            |
&n= bsp;    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
     | 0x01 = (Access-Loop-Circuit-ID) | =        Client-ID Length =       |
     +-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 =     | =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ; |
     ~ =             &= nbsp;        Port Client-ID =             &= nbsp;           &n= bsp; ~
     | =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ; |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | = Type=3DCommandCode: Delete(0x02)| =           Length =             &= nbsp;|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | = AddrFamily 01 | EncType 0x0   |  Mcast group: 239.23.2.2 =      |
     +-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
  =    | AddrFamily 01 | EncType 0x0   | =  Mcast Source: 10.1.1.1 =       |
     +-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
 =     | Type=3DCommandCode: Add (0x01)  | =           Length =             &= nbsp;|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | = AddrFamily 01 | EncType 0x0   |  Mcast group: 239.55.3.2 =      |
     +-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
  =    | AddrFamily 01 | EncType 0x0   | =  Mcast Source: 10.1.1.1 =       |
     +-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|

Ea= ch command in the list is attributed an identification number based = on
its occurrence in the message. In this case, the Delete command = will be
attributed command number 1 while the Add will be attributed = command
number 2. During the processing of these  commands, upon = the first
failure of a command, the sequence is interrupted and an = error message
(via Multicast Status Message) will be returned with = the command number
identifying the command that = failed.

_______________________________________________
ANCP = mailing = list
ANCP@ietf.org
https://www.ietf.org/mailman/listinfo/ancp
=0A=
=0A= _______________________________________________
ANCP mailing = list
ANCP@ietf.org
https://www.ietf.org/mailman/listinfo/ancp

Please do not = print this email unless it is absolutely necessary. =

 The information contained in this electronic = message and any attachments to this message are intended for the = exclusive use of the addressee(s) and may contain proprietary, = confidential or privileged information. If you are not the intended = recipient, you should not disseminate, distribute or copy this e-mail. = Please notify the sender immediately and destroy all copies of this = message and any attachments.

WARNING: Computer viruses can be = transmitted via email. The recipient should check this email and any = attachments for the presence of viruses. The company accepts no = liability for any damage caused by any virus transmitted by this email. =

www.wipro.com


-- =
Einar Nilsen-Nygaard
Technical Leader, Cisco

Clothes make = the man. Naked people have little or no influence on
society. --Mark = Twain

------_=_NextPart_001_01C8A48D.944ABEC9-- --===============1778972288== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============1778972288==-- From ancp-bounces@ietf.org Tue Apr 22 08:39:54 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 986F628C2BB; Tue, 22 Apr 2008 08:39:54 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E16C128C233 for ; Tue, 22 Apr 2008 08:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.477 X-Spam-Level: X-Spam-Status: No, score=-0.477 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994, SARE_UNSUB18=0.131] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5C2RNGrgnu3j for ; Tue, 22 Apr 2008 08:39:49 -0700 (PDT) Received: from wipro-blr-out02.wipro.com (wipro-blr-out02.wipro.com [203.91.198.75]) by core3.amsl.com (Postfix) with ESMTP id 3E90228C1FC for ; Tue, 22 Apr 2008 08:39:48 -0700 (PDT) X-AuditID: cb5bdd58-aa386bb000004602-52-480e06c83d15 Received: from blr-ec-bh01.wipro.com (unknown [10.201.50.91]) by wipro-blr-out02.wipro.com (Symantec Mail Security) with ESMTP id 5FB80558002 for ; Tue, 22 Apr 2008 21:09:52 +0530 (IST) Received: from BLR-EC-MBX07.wipro.com ([10.201.52.181]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Apr 2008 21:09:52 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Apr 2008 21:09:52 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP Multicast Control Message Thread-Index: Acij+5MzWijMyW8RTPSeLUilx/6xkAAkhiQj References: <20080421220043.GI175@cisco.com> From: To: , X-OriginalArrivalTime: 22 Apr 2008 15:39:52.0015 (UTC) FILETIME=[1AFD5DF0:01C8A48F] X-Brightmail-Tracker: AAAAAA== Cc: ancp@ietf.org Subject: Re: [ANCP] ANCP Multicast Control Message X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0822445335==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0822445335== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A48F.1B0D4F15" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A48F.1B0D4F15 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments a> It would be good to add Vlan tag as one of the parameters to the = add/delete command, as this will indicate which VLAN should be used for = multicasting. DSL TR 101, discusses about the multicast flow being = associated with a VLAN (Multicast-Vlan). In this case, the Access Node, = needs to be informed about the VLAN ID on which a particular Multicast = group is being associated by the NAS. =20 Cheers Vish =20 =20 ________________________________ From: Toerless Eckert [mailto:eckert@cisco.com] Sent: Mon 4/21/2008 6:00 PM To: Einar Nilsen-Nygaard Cc: Vishwanathan Somasundaram (WT01 - TES-Access Networks); = wdec@cisco.com; ancp@ietf.org Subject: Re: [ANCP] ANCP Multicast Control Message Some comments: a) Please change the name of the two 'Length' fields in the control mesages sucht hat they can be differentiated easier from another and specify what is counted in them, eg: Type=3DReplication-Control (0x01)| Length | ^^^^^^ =20 suggest to change to RC-Length, explanation "total number of bytes of the following TLVs plus the replication control header". Type =3D CommandCode | Length | ^^^^^^ suggest to change to CC-Length, explanation "total number of this CommandCode TLV, counting this header and the following multicast flow bytes". b) Please try to avoid using the term "group" when referring to an address which is either an ASM (Any Source Multicast) group address (aka: a single multicast group address, IPv4 or IPv6) or an SSM channel (aka: source and group address). I would stroingly suggest to only use the term "multicast flow" or multicast flow address, or just "flow", and define that term in the beginning of the document to be either an ASN group or SSM channel. Otherwise there will be lots of confusions about whether or not SSM is well supported by ANCP. c) Do not refer to rfc2362. That RFC is obsolete and replaced by = rfc4601. I do not see a good reason to refer to any PIM spec anyhow, just resolve the references used within the PIM-SM spec, eg: http://www.iana.org/assignments/address-family-numbers or the like. d) To identify an actual SSM channel, it would be preferrable IMHO to have an address family identifier for an SSM channel, aka: an IP(v6/v6) source IP address followed by a group address. As above IANA URL has nothing like this defined, i think there are two choices: -> I) I'll check what effort it is to get that defined through IANA. -> II) we stick with the existing specification, which is to have a separate field addrfamily/encoding/group and one addrfamily/encoding/source, but then i would very much like to see very explicit description in the protocol spec what sequeneces of addfamily/encoding/addr (AEA) elements are = valid, and how they have to be interpreted: for add/delete commands: -> MUST support a single AEA argument where the address is an IPv4/IPv6 address that is a multicast group. (ASM case). -> MUST support TWO AEA argument where the address of the first AEA is an IPv4/IPv6 address which is a unicast address, and the second AEA is an IPv4/IPv6 address which is a multicast address. Aka: SSM case. =20 In the example text i see two things i am questioning: I) The (S,G) channels are encoded first group and then source. That IMHO is not preferrable. I would rather suggest like written above to encode first source and then group. =20 II) The text is suggesting to have eg: multiple group AEA following an add/delete TLV. I have no strong opinion whether or not that should be supported, but if we conclude it should be supported, then that should explicitly be = mentioned in the text (see also below). And that description would then of course have to detail a bit how a list of AEAs with ASM groups and SSM channels is to be encoded. Particularily this case makes it of course important to either be very clear how an SSM channel is encoded (source first or group first), or even better use a separate Address-Familty identifier as suggested above. e) I do not see any suggestion on the command reply. Is there supposed to be some failure and/or success return codes ? f) As far as return codes are concerned: I would like to see some clearer statement about the suggested atomicity (if that's a valid english word ;-) of the execution of multiple flows within a single add/delete/modify TLV as well as the flows across multiple TLVs within the same replication control message. -> What happens if any individual flow add/delete fails ? The document right now only seems to imply that the execution of the following add/deletes is simply not executed. That by itself would require the NAS to either query all state to figure out what actually was executed or to simply try everything again. If we would add a return code like the following, that would not be necessary: =20 "Sorry, error: all flows up to byte XX into the packet where performed well, and the following flow failed to be addeded/deleted, and the rest was not even tried" =20 I am not sure if this type of error return is the preferred solution, but if we do not mandate something better, then it probably should be done. =20 -> A better solution would be to imply some form of atomicity, eg: either at TLV or at replication control level. Meaning: the AN tries to execute add/delete/modifies, but if anything = fails, then everything is undone. Or better: Nothing is applied by the AN unless it can make sure everything will succeed. g) Atomicity is a hard bargain for the control/forwarding plane of a router/switch/DSLAM i think. If there is a bunch of = add/delete/modify and all of those should only be applied if all of them will = succeed... good luck getting that actually implemented correctly in the forwarding plane of any AN. The thing i could see us asking to be done atomically is really JUST a single flow-swap, aka: replace exactly one flow with another flow. So ultimately, i think: -> For add/delete commands we ask for no atomicity and the error code returned should somehow point to the first flow within a packet that failed. And provide some additional error code why (which we could define the values for later). And this should allow us to have multiple flows as arguments to a single add/delete to be more efficient. =20 -> a modify should be called "swap", and should support only exactly two flows as the argument. This swap should work atomically, aka: the join would not be executed if the leave could not be done, and the leave should of course not be executed if the join would not work. =20 -> So maybe overall the error return code would be =20 command#, flow#, why where command# would be pointing to the command (numbered 1 t N) within the recplication control command that failed, flow# would be the flow (1..M) within that command (always 1 for a swap, as we only allow a single flow there), and why would be some eg: 8-bit error code where we could define values for that would help diagnosis. h) The degree to which a platform is able to implement even this most simple atomic swap is of course subject to implementation. Cheers Toerless =20 On Mon, Apr 21, 2008 at 09:47:06PM +0100, Einar Nilsen-Nygaard wrote: > Vish, > > I actually think that freedom in how a =B3swap=B2 operation would be = implemented > in terms of the ordering of stopping the first multicast flow and = starting > the second is not desirable. By specifying that the delete must come = before > the add and that the operation should be terminated upon the first = error, > the current specification gives us what should be deterministic = behavior > between any and all conforming implementations. > > In contrast, the freedom to implement a swap operation via some form = of > modify leaves the door open to multiple ways in which a modify request = could > fail, making error recovery more troublesome and vendor-specific which = I do > not see as at all desirable. > > Cheers, > > Einar > > On 21/04/2008 20:12, "vishwanathan.sundaram@wipro.com" > scribbled: > > > Einar, > > Modify command would be usefull from Access box perspective, as the = underlying > > implementation in AN's would have the freedom to design their swap = operation, > > instead of always first deleting the existing group entry and adding = another > > entry. > >=20 > > Thanks > > Vish > >=20 > > > > > > From: einarnn [mailto:einarnn@cisco.com] > > Sent: Sun 4/20/2008 11:12 AM > > To: Vishwanathan Somasundaram (WT01 - TES-Access Networks); = wdec@cisco.com; > > ancp@ietf.org > > Subject: Re: [ANCP] ANCP Multicast Control Message > > > > Vish, > > > > Overloading the second byte of the command code to contain the = number of > > =B3modifications=B2 doesn=B9t seem a good approach and the space = saving per packet, > > which will probably be only 4 bytes most of the time, seems almost = irrelevant. > > I think it would be better to keep the fields in the message for a = single > > task. > > > > Treating a sequence of commands as an atomic operation, as detailed = in the > > text, and implementing a swap via a delete follow by an add, should = give ANs > > the freedom to implement what are, in effect, swap operations quite > > efficiently. In this context, I=B9m not sure what a =B3modify=B2 = command code will > > really add? > > > > Cheers, > > > > Einar > > > > On 16/04/2008 15:41, "vishwanathan.sundaram@wipro.com" > > wrote: > > > >> Hi Woj, > >> Currently, the command codes for replication control message are > >> 1. add (0x01) > >> 2. delete (0x02) > >> 3. delete all (0x04). > >> > >> Looking at the multicast Swap message format, which is used when = the NAS > >> wants to switch from one group to another,can we not handle this = situation by > >> having a message type Modify (0x08). > >> By using this message type we can mention the multicast group = address which > >> needs to be swapped by new multicast group address. > >> Since the Command Code is 2 bytes, the second byte can be used to = mention the > >> number of multicast groups that needs to be swapped. > >> This will allow, for multiple multicast group swaps. This will also = reduce > >> the size of the packet. Since these messages intended only between = the NAS > >> and AN, the introduction of modify command type gives further ease = to the > >> Access boxes in implementing the swaps, which attributes to zap = latency. > >> > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Type (0x88-0C) | Length = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Vers | Sub |MessageType=3D90 | Result| Code = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Partition ID | Transaction Identifier =3D 0001 = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> |I| SubMessage Number | Length = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | 0x01 (Replication-Control) | Length = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | 0x01 (Access-Loop-Circuit-ID) | Client-ID Length = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | = | > >> ~ Port Client-ID = ~ > >> | = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Type=3DCommandCode: Modify(0x08)| Length > >> | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | AddrFamily 01 | EncType 0x0 | Mcast group: 239.23.2.2 = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > >> | AddrFamily 01 | EncType 0x0 | Mcast Source: 10.1.1.1 > >> | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > >> | AddrFamily 01 | EncType 0x0 | New Mcast group: = 239.55.3.2 | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > >> | AddrFamily 01 | EncType 0x0 | New Mcast Source: 10.1.1.1 = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > >> > >> Looking into the DSL TR 101, it also discusses about the multicast = flow being > >> associated with a VLAN (Multicast-Vlan). In this case, the Access = Node, needs > >> to be informed about the VLAN ID on which a particular Multicast = group is > >> being associated by the NAS. Can this information also be added as = part of > >> the TLV in message. > >> > >> Thanks > >> Vish > >> > >> > >> From: ancp-bounces@ietf.org on behalf of Wojciech Dec (wdec) > >> Sent: Mon 4/14/2008 11:00 AM > >> To: ancp@ietf.org > >> Subject: [ANCP] ANCP Multicast Control Message > >> > >> > >> > >> Hi All, > >> > >> As discussed during our recent IETF 71 meeting, our protocol design = team > >> has forged ahead with prioritized list of problems to address, the = first > >> of which was defining the ANCP message extensions for multicast = control, > >> aka unsolicited multicast control. The DT is working on the = response > >> message and also the solicited multicast control mode. > >> Below, we present the outcome of the work, which represents both a > >> design team consensus as well as a proposal for adoption into the = ANCP > >> protocol spec, draft-ietf-ancp-protocol (some editorial work will = be > >> still required). Please review the proposal and share your = comments. We > >> will assume acceptance of the proposal in principle otherwise. > >> > >> Regards, > >> Woj & Matthew. > >> > >> > >> 2 Replication Control Message > >> > >> > >> This message is sent by the ANCP Server (NAS) to the ANCP Client = (AN) > >> with a directive to either add (join) or delete (leave) a port to = or > >> from a multicast flow. Its format is as follow: > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> |Type=3DReplication-Control (0x01)| Length = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | 0x01 (Access-Loop-Circuit-ID) | Client-ID Length = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | = | > >> ~ Port Client-ID = ~ > >> | = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> Following the Port Client-ID information, one or more Command TLV > >> components can be included and the Access Node should process them = in > >> the order in which they are listed. The Access Node (ANCP Client) = should > >> threat all the commands as a single command block to be viewed as a > >> whole and bail out immediately when one of them fails. > >> The format of command TLV is as follow: > >> > >> 0 1 2 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Type =3D CommandCode | Length = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Addr Family | Encoding Type | Multicast Group Address = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Addr Family | Encoding Type | Multicast Source Address = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> Where CommandCode specifies the command and can be one of the = following: > >> > >> 0x01 Add Adds the specified multicast flow to the specified = port > >> (join) > >> 0x02 Delete Deletes the specified multicast flow (leave) on the > >> specified port. > >> 0x04 DeleteAll Deletes All multicast flow on the specified port = (leave > >> all). No addresses are supplied. > >> > >> When we have more than one command, Deletes should always be listed > >> first. The unicast source address/mask follows the format defined = in RFC > >> 2362 Section 4.1 case 1 which is duplicated here for quick review: > >> > >> Encoded-Unicast-address: Takes the following format: > >> > >> 0 1 2 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Addr Family | Encoding Type | Unicast Address | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> Addr Family > >> The address family of the `Unicast Address' field of > >> this address. > >> > >> Here is the address family numbers assigned by IANA: > >> > >> Number Description > >> -------- = --------------------------------------------------------- > >> 0 Reserved > >> 1 IP (IP version 4) > >> 2 IP6 (IP version 6) > >> 3 NSAP > >> 4 HDLC (8-bit multidrop) > >> 5 BBN 1822 > >> 6 802 (includes all 802 media plus Ethernet "canonical = format") > >> 7 E.163 > >> 8 E.164 (SMDS, Frame Relay, ATM) > >> 9 F.69 (Telex) > >> 10 X.121 (X.25, Frame Relay) > >> 11 IPX > >> 12 Appletalk > >> 13 Decnet IV > >> 14 Banyan Vines > >> 15 E.164 with NSAP format subaddress > >> > >> Encoding Type > >> The type of encoding used within a specific Address > >> Family. The value `0' is reserved for this field, > >> and represents the native encoding of the Address > >> Family. > >> > >> Unicast Address > >> The unicast address as represented by the given > >> Address Family and Encoding Type. > >> > >> Finally, although the length could be derived from the Addr Family = and > >> the Encoding type, it is kept for future possible extension to this > >> command where other entry would be added to this command segment. > >> The equivalent of a swap command where the NAS would want to switch = from > >> multicast group 239.23.2.2 to 239.55.3.2 will have the following = format: > >> > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Type (0x88-0C) | Length = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Vers | Sub |MessageType=3D90 | Result| Code = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Partition ID | Transaction Identifier =3D 0001 = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> |I| SubMessage Number | Length = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | 0x01 (Replication-Control) | Length = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | 0x01 (Access-Loop-Circuit-ID) | Client-ID Length = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | = | > >> ~ Port Client-ID = ~ > >> | = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Type=3DCommandCode: Delete(0x02)| Length = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | AddrFamily 01 | EncType 0x0 | Mcast group: 239.23.2.2 = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > >> | AddrFamily 01 | EncType 0x0 | Mcast Source: 10.1.1.1 = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > >> | Type=3DCommandCode: Add (0x01) | Length = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | AddrFamily 01 | EncType 0x0 | Mcast group: 239.55.3.2 = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > >> | AddrFamily 01 | EncType 0x0 | Mcast Source: 10.1.1.1 = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > >> > >> Each command in the list is attributed an identification number = based on > >> its occurrence in the message. In this case, the Delete command = will be > >> attributed command number 1 while the Add will be attributed = command > >> number 2. During the processing of these commands, upon the first > >> failure of a command, the sequence is interrupted and an error = message > >> (via Multicast Status Message) will be returned with the command = number > >> identifying the command that failed. > >> > >> _______________________________________________ > >> ANCP mailing list > >> ANCP@ietf.org > >> https://www.ietf.org/mailman/listinfo/ancp > >> > >> > >> _______________________________________________ > >> ANCP mailing list > >> ANCP@ietf.org > >> https://www.ietf.org/mailman/listinfo/ancp > > > > Please do not print this email unless it is absolutely necessary. > > > > The information contained in this electronic message and any = attachments to > > this message are intended for the exclusive use of the addressee(s) = and may > > contain proprietary, confidential or privileged information. If you = are not > > the intended recipient, you should not disseminate, distribute or = copy this > > e-mail. Please notify the sender immediately and destroy all copies = of this > > message and any attachments. > > > > WARNING: Computer viruses can be transmitted via email. The = recipient should > > check this email and any attachments for the presence of viruses. = The company > > accepts no liability for any damage caused by any virus transmitted = by this > > email. > > > > www.wipro.com > > > > > > -- > > Einar Nilsen-Nygaard > > Technical Leader, Cisco > > > > Clothes make the man. Naked people have little or no influence on > > society. --Mark Twain > > > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture "The strategy is what you do, not what you write" - Wesley Clark ------_=_NextPart_001_01C8A48F.1B0D4F15 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [ANCP] ANCP Multicast Control = Message=0A= =0A= =0A= =0A=
=0A=
Comments
=0A=
a> It would be good to add = Vlan tag as one of the parameters to the add/delete command, as this = will indicate which VLAN should be used for multicasting. DSL TR = 101,  discusses about the multicast flow being associated with = a VLAN (Multicast-Vlan). In this case, the Access Node, needs to be = informed about the VLAN ID on which a particular Multicast group is = being associated by the NAS.
=0A=
 
=0A=
Cheers
=0A=
Vish
=0A=
 
=0A=
 
=0A=
=0A=


=0A=
=0A=
=0A=
=0A=
From: Toerless Eckert = [mailto:eckert@cisco.com]
Sent: Mon 4/21/2008 6:00 = PM
To: Einar Nilsen-Nygaard
Cc: Vishwanathan = Somasundaram (WT01 - TES-Access Networks); wdec@cisco.com; = ancp@ietf.org
Subject: Re: [ANCP] ANCP Multicast Control = Message

=0A=
=0A=

Some comments:

a) Please change the name of the = two 'Length' fields in the
   control mesages sucht hat = they can be differentiated easier from
   another and = specify what is counted in them, eg:

    = Type=3DReplication-Control = (0x01)|           =   = Length            = |
           &n= bsp;           &nb= sp;           &nbs= p;            = ; ^^^^^^
   
   suggest to change to = RC-Length, explanation "total number of bytes
   of the = following TLVs plus the replication control = header".

    Type =3D = CommandCode           = |            =   = Length           &= nbsp;   = |
           &n= bsp;           &nb= sp;           &nbs= p;            = ^^^^^^

   suggest to change to CC-Length, explanation = "total number of
   this CommandCode TLV, counting this = header and the following
   multicast flow = bytes".

b) Please try to avoid using the term "group" when = referring to
   an address which is either an ASM (Any = Source Multicast) group
   address (aka: a single multicast = group address, IPv4 or IPv6)
   or an SSM channel (aka: = source and group address).

   I would stroingly suggest = to only use the term "multicast flow"
   or multicast flow = address, or just "flow", and define that term
   in the = beginning of the document to be either an ASN group or
   = SSM channel.

   Otherwise there will be lots of = confusions about whether or not
   SSM is well supported by = ANCP.

c) Do not refer to rfc2362. That RFC is obsolete and = replaced by rfc4601.
   I do not see a good reason to refer = to any PIM spec anyhow, just
   resolve the references used = within the PIM-SM spec, eg:

   http://ww= w.iana.org/assignments/address-family-numbers

   or = the like.

d) To identify an actual SSM channel, it would be = preferrable IMHO
   to have an address family identifier = for an SSM channel, aka:
   an IP(v6/v6) source IP address = followed by a group address. As
   above IANA URL has = nothing like this defined, i think there are
   two = choices:

   -> I) I'll check what effort it is to = get that defined through IANA.

   -> II) we stick = with the existing specification, which is = to
      have a separate field = addrfamily/encoding/group and one
      = addrfamily/encoding/source, but then i would very = much
      like to see very explicit = description in the protocol spec
      what = sequeneces of addfamily/encoding/addr (AEA) elements are = valid,
      and how they have to be = interpreted:

      for add/delete = commands:
        -> MUST = support a single AEA argument where the = address
           = is an IPv4/IPv6 address that is a multicast = group.
           = (ASM case).

        -> MUST = support TWO AEA argument where the address of = the
           = first AEA is an IPv4/IPv6 address which is a = unicast
           = address, and the second AEA is an IPv4/IPv6 address = which
           is = a multicast address. Aka: SSM = case.
     
     = In the example text i see two things i am = questioning:

        I) The = (S,G) channels are encoded first group and then = source.
           = That IMHO is not preferrable. I would rather suggest = like
           = written above to encode first source and then = group.
        
  = ;      II) The text is suggesting to have eg: = multiple group = AEA
           = following an add/delete TLV. I have no strong = opinion
          &n= bsp; whether or not that should be supported, but if we = conclude
          &= nbsp; it should be supported, then that should explicitly be = mentioned
          =   in the text (see also below). And that description = would
          &nbs= p; then of course have to detail a bit how a list of = AEAs
           = ; with ASM groups and SSM channels is to be = encoded.
          &= nbsp; Particularily this case makes it of course = important
          =   to either be very clear how an SSM channel is = encoded
          &n= bsp; (source first or group first), or even better use a = separate
          &= nbsp; Address-Familty identifier as suggested above.

e) I do not = see any suggestion on the command reply. Is there
   = supposed to be some failure and/or success return codes ?

f) As = far as return codes are concerned: I would like to see = some
   clearer statement about the suggested atomicity (if = that's a
   valid english word ;-) of the execution of = multiple flows
   within a single add/delete/modify TLV as = well as the flows across
   multiple TLVs within the same = replication control message.

   -> What happens if = any individual flow add/delete fails ? = The
      document right now only seems to = imply that the execution of
      the = following add/deletes is simply not executed.  That = by
      itself would require the NAS to = either query all state to figure
      out = what actually was executed or to simply try everything = again.

      If we would add a return = code like the following, that would
      = not be = necessary:
     
    &= nbsp;   "Sorry, error: all flows up to byte XX into the packet = where
         performed = well, and the following flow failed to = be
         addeded/deleted, = and the rest was not even = tried"
     
     = ; I am not sure if this type of error return is the = preferred
      solution, but if we do not = mandate something better, then
      it = probably should be done.
  
   -> A better = solution would be to imply some form of = atomicity,
      eg: either at TLV or at = replication control level. Meaning:
      = the AN tries to execute add/delete/modifies, but if anything = fails,
      then everything is undone. Or = better: Nothing is applied by
      the AN = unless it can make sure everything will succeed.

g) Atomicity is = a hard bargain for the control/forwarding plane
   of a = router/switch/DSLAM i think. If there is a bunch of = add/delete/modify
   and all of those should only be = applied if all of them will succeed...
   good luck getting = that actually implemented correctly in the
   forwarding = plane of any AN.

   The thing i could see us asking to = be done atomically is really
   JUST a single flow-swap, = aka: replace exactly one flow with
   another = flow.

   So ultimately, i think:

   = -> For add/delete commands we ask for no atomicity and the = error
      code returned should somehow = point to the first flow within
      a = packet that failed. And provide some additional error = code
      why (which we could define the = values for later). And this
      should = allow us to have multiple flows as arguments to = a
      single add/delete to be more = efficient.
  
   -> a modify should be = called "swap", and should support only
      = exactly two flows as the argument. This swap should = work
      atomically, aka: the join would = not be executed if the leave
      could not = be done, and the leave should of course not = be
      executed if the join would not = work.
  
   -> So maybe overall the error = return code would = be
     
      = command#, flow#, why

      where = command# would be pointing to the command (numbered 1 t = N)
      within the recplication control = command that failed,
      flow# would be = the flow (1..M) within that command (always 1 = for
      a swap, as we only allow a single = flow there), and why would be
      some eg: = 8-bit error code where we could define values for = that
      would help = diagnosis.


h) The degree to which a platform is able to = implement even this
   most simple atomic swap is of course = subject to implementation.

Cheers
    = Toerless
     
On Mon, Apr 21, 2008 at = 09:47:06PM +0100, Einar Nilsen-Nygaard wrote:
> = Vish,
>
> I actually think that freedom in how a =B3swap=B2 = operation would be implemented
> in terms of the ordering of = stopping the first multicast flow and starting
> the second is not = desirable. By specifying that the delete must come before
> the = add and that the operation should be terminated upon the first = error,
> the current specification gives us what should be = deterministic behavior
> between any and all conforming = implementations.
>
> In contrast, the freedom to implement a = swap operation via some form of
> modify leaves the door open to = multiple ways in which a modify request could
> fail, making error = recovery more troublesome and vendor-specific which I do
> not see = as at all desirable.
>
> Cheers,
>
> = Einar
>
> On 21/04/2008 20:12, = "vishwanathan.sundaram@wipro.com"
> = <vishwanathan.sundaram@wipro.com> scribbled:
>
> > = Einar,
> > Modify command would be usefull from Access box = perspective, as the underlying
> > implementation in AN's would = have the freedom to design their swap operation,
> > instead of = always first deleting the existing group entry and adding = another
> > entry.
> > 
> > = Thanks
> > Vish
> > 
> >
> = >
> > From: einarnn [mailto:einarnn@cisco.com]
> = > Sent: Sun 4/20/2008 11:12 AM
> > To: Vishwanathan = Somasundaram (WT01 - TES-Access Networks); wdec@cisco.com;
> > = ancp@ietf.org
> > Subject: Re: [ANCP] ANCP Multicast Control = Message
> >
> > Vish,
> >
> > = Overloading the second byte of the command code to contain the number = of
> > =B3modifications=B2 doesn=B9t seem a good approach and = the space saving per packet,
> > which will probably be only 4 = bytes most of the time, seems almost irrelevant.
> > I think it = would be better to keep the fields in the message for a single
> = > task.
> >
> > Treating a sequence of commands as = an atomic operation, as detailed in the
> > text, and = implementing a swap via a delete follow by an add, should give = ANs
> > the freedom to implement what are, in effect, swap = operations quite
> > efficiently. In this context, I=B9m not = sure what a =B3modify=B2 command code will
> > really = add?
> >
> > Cheers,
> >
> > = Einar
> >
> > On 16/04/2008 15:41, = "vishwanathan.sundaram@wipro.com"
> > = <vishwanathan.sundaram@wipro.com> wrote:
> >
> = >> Hi Woj,
> >> Currently, the command codes for = replication control message are
> >> 1. add (0x01)
> = >> 2. delete (0x02)
> >> 3. delete all (0x04).
> = >>
> >> Looking at the multicast Swap message format, = which is used when the NAS
> >> wants to switch from one = group to another,can we not handle this situation by
> >> = having a message type Modify (0x08).
> >> By using this = message type we can mention the multicast group address which
> = >> needs to be swapped by new multicast group address.
> = >> Since the Command Code is 2 bytes, the second byte can be used = to mention the
> >> number of multicast groups that needs to = be swapped.
> >> This will allow, for multiple multicast = group swaps. This will also reduce
> >> the size of the = packet. Since these messages intended only between the NAS
> = >> and AN, the introduction of modify command type gives further = ease to the
> >> Access boxes in implementing the swaps, = which attributes to zap latency.
> >>
> = >>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> = >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= >>      = |        Type = (0x88-0C)         = |           = Length           &= nbsp;  |
> >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= >>      | Vers  |  Sub  = |MessageType=3D90 | Result|        = Code           = |
> >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= >>      | Partition ID  = |            = Transaction Identifier =3D 0001      |
> = >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= >>      = |I|      SubMessage = Number      = |           = Length           &= nbsp;  |
> >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= >>      | 0x01 = (Replication-Control)    = |            = = Length            = |
> >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= >>      | 0x01 (Access-Loop-Circuit-ID) = |        Client-ID = Length       |
> = >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= >>      = |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;  |
> >>      = ~            =           Port = Client-ID          &nbs= p;            = ;    ~
> >>      = |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;  |
> >>     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= >>      | Type=3DCommandCode: = Modify(0x08)|          = Length
> >> |
> = >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= >>      | AddrFamily 01 | EncType = 0x0    |  Mcast group: = 239.23.2.2          &nb= sp; |
> >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
>= >>      | AddrFamily 01 | EncType = 0x0    |  Mcast Source: 10.1.1.1
> >> = |
> >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
>= >>       | AddrFamily 01 | EncType = 0x0   |  New Mcast group: 239.55.3.2   = |
> >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
>= >>      | AddrFamily 01 | EncType = 0x0    |  New Mcast Source: = 10.1.1.1      |
> = >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
>= >>
> >> Looking into the DSL TR 101, it also = discusses about the multicast flow being
> >> associated = with a VLAN (Multicast-Vlan). In this case, the Access Node, = needs
> >> to be informed about the VLAN ID on which a = particular Multicast group is
> >> being associated by the = NAS. Can this information also be added as part of
> >> the = TLV in message.
> >>
> >> Thanks
> = >> Vish
> >>
> >>
> >> From: = ancp-bounces@ietf.org on behalf of Wojciech Dec (wdec)
> >> = Sent: Mon 4/14/2008 11:00 AM
> >> To: ancp@ietf.org
> = >> Subject: [ANCP] ANCP Multicast Control Message
> = >>
> >>
> >>
> >> Hi = All,
> >>
> >> As discussed during our recent = IETF 71 meeting, our protocol design team
> >> has forged = ahead with prioritized list of problems to address, the first
> = >> of which was defining the ANCP message extensions for multicast = control,
> >> aka unsolicited multicast control. The DT is = working on the response
> >> message and also the solicited = multicast control mode.
> >> Below, we present the outcome = of the work, which represents both a
> >> design team = consensus as well as a proposal for adoption into the ANCP
> = >> protocol spec, draft-ietf-ancp-protocol (some editorial work = will be
> >> still required). Please review the proposal and = share your comments. We
> >> will assume acceptance of the = proposal in principle otherwise.
> >>
> >> = Regards,
> >> Woj & Matthew.
> >>
> = >>
> >> 2       = Replication Control Message
> >>
> >>
> = >> This message is sent by the ANCP Server (NAS) to the ANCP = Client (AN)
> >> with a directive to either add (join) or = delete (leave) a port to or
> >> from a multicast flow. Its = format is as follow:
> = >>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> = >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= >>      |Type=3DReplication-Control = (0x01)|           =   = Length            = |
> >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= >>      | 0x01 (Access-Loop-Circuit-ID) = |        Client-ID = Length       |
> = >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= >>      = |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;  |
> >>      = ~            =           Port = Client-ID          &nbs= p;            = ;    ~
> >>      = |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;  |
> >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= >>
> >> Following the Port Client-ID information, one = or more Command TLV
> >> components can be included and the = Access Node should process them in
> >> the order in which = they are listed. The Access Node (ANCP Client) should
> >> = threat all the commands as a single command block to be viewed as = a
> >> whole and bail out immediately when one of them = fails.
> >> The format of command TLV is as follow:
> = >>
> >>       = 0            =        = 1            =        = 2            =        3
> = >>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> = >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= >>      |  Type =3D = CommandCode           = |          = Length           &= nbsp;   |
> >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= >>      | Addr Family   | = Encoding Type |  Multicast Group = Address      |
> = >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= >>      | Addr Family   | = Encoding Type |  Multicast Source Address     = |
> >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= >>
> >> Where CommandCode specifies the command and = can be one of the following:
> >>
> >> = 0x01  Add       Adds the specified = multicast flow to the specified port
> >> (join)
> = >> 0x02  Delete    Deletes the specified = multicast flow (leave) on the
> >> specified port.
> = >> 0x04  DeleteAll Deletes All multicast flow on the = specified port (leave
> >> all). No addresses are = supplied.
> >>
> >> When we have more than one = command, Deletes should always be listed
> >> first. The = unicast source address/mask follows the format defined in RFC
> = >> 2362 Section 4.1 case 1 which is duplicated here for quick = review:
> >>
> >> Encoded-Unicast-address: Takes = the following format:
> >>
> >>   = 0            =        = 1            =        = 2            =        3
> >>   0 1 = 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> = >>  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= >>  | Addr Family   | Encoding Type = |     Unicast = Address           = |
> >>  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= >>
> >>      Addr = Family
> = >>           = ; The address family of the `Unicast Address' field  of
> = >>           = ; this address.
> >>
> = >>           = Here is the address family numbers assigned by IANA:
> = >>
> >>  Number    = Description
> >>  --------  = ---------------------------------------------------------
> = >>       0    = Reserved
> >>       = 1    IP (IP version 4)
> = >>       2    IP6 (IP = version 6)
> >>       = 3    NSAP
> = >>       4    HDLC = (8-bit multidrop)
> >>       = 5    BBN 1822
> = >>       6    802 = (includes all 802 media plus Ethernet "canonical format")
> = >>       7    = E.163
> >>       = 8    E.164 (SMDS, Frame Relay, ATM)
> = >>       9    F.69 = (Telex)
> >>      = 10    X.121 (X.25, Frame Relay)
> = >>      11    IPX
> = >>      12    = Appletalk
> >>      = 13    Decnet IV
> = >>      14    Banyan = Vines
> >>      = 15    E.164 with NSAP format subaddress
> = >>
> >>      Encoding = Type
> = >>           The = type of encoding used within a specific Address
> = >>           = Family.  The value `0' is reserved for this field,
> = >>           and = represents the native encoding of the Address
> = >>           = Family.
> >>
> >>      = Unicast Address
> = >>           The = unicast address as represented by the given
> = >>           = Address Family and Encoding Type.
> >>
> >> = Finally, although the length could be derived from the Addr Family = and
> >> the Encoding type, it is kept for future possible = extension to this
> >> command where other entry would be = added to this command segment.
> >> The equivalent of a swap = command where the NAS would want to switch from
> >> = multicast group 239.23.2.2 to 239.55.3.2 will have the following = format:
> >>
> = >>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> = >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= >>      = |        Type = (0x88-0C)         = |           = Length           &= nbsp;  |
> >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= >>      | Vers  |  Sub  = |MessageType=3D90 | Result|        = Code           = |
> >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= >>      | Partition ID  = |            = Transaction Identifier =3D 0001      |
> = >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= >>      = |I|      SubMessage = Number      = |           = Length           &= nbsp;  |
> >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= >>      | 0x01 = (Replication-Control)    = |            = = Length            = |
> >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= >>      | 0x01 (Access-Loop-Circuit-ID) = |        Client-ID = Length       |
> = >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= >>      = |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;  |
> >>      = ~            =           Port = Client-ID          &nbs= p;            = ;    ~
> >>      = |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;  |
> >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= >>      | Type=3DCommandCode: = Delete(0x02)|          = = Length           &= nbsp;  |
> >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= >>      | AddrFamily 01 | EncType = 0x0   |  Mcast group: = 239.23.2.2      |
> = >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
>= >>      | AddrFamily 01 | EncType = 0x0   |  Mcast Source: = 10.1.1.1       |
> = >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
>= >>      | Type=3DCommandCode: Add = (0x01)  = |           = Length           &= nbsp;  |
> >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= >>      | AddrFamily 01 | EncType = 0x0   |  Mcast group: = 239.55.3.2      |
> = >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
>= >>      | AddrFamily 01 | EncType = 0x0   |  Mcast Source: = 10.1.1.1       |
> = >>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
>= >>
> >> Each command in the list is attributed an = identification number based on
> >> its occurrence in the = message. In this case, the Delete command will be
> >> = attributed command number 1 while the Add will be attributed = command
> >> number 2. During the processing of these  = commands, upon the first
> >> failure of a command, the = sequence is interrupted and an error message
> >> (via = Multicast Status Message) will be returned with the command = number
> >> identifying the command that failed.
> = >>
> >> = _______________________________________________
> >> ANCP = mailing list
> >> ANCP@ietf.org
> >> https://www.ietf.org/= mailman/listinfo/ancp
> >>
> >>
> = >> _______________________________________________
> = >> ANCP mailing list
> >> ANCP@ietf.org
> = >> https://www.ietf.org/= mailman/listinfo/ancp
> >
> >  Please do not = print this email unless it is absolutely necessary.
> >
> = >  The information contained in this electronic message and any = attachments to
> > this message are intended for the exclusive = use of the addressee(s) and may
> > contain proprietary, = confidential or privileged information. If you are not
> > the = intended recipient, you should not disseminate, distribute or copy = this
> > e-mail. Please notify the sender immediately and = destroy all copies of this
> > message and any = attachments.
> >
> > WARNING: Computer viruses can be = transmitted via email. The recipient should
> > check this = email and any attachments for the presence of viruses. The = company
> > accepts no liability for any damage caused by any = virus transmitted by this
> > email.
> >
> > = www.wipro.com
> >
> >
> > --
> > = Einar Nilsen-Nygaard
> > Technical Leader, Cisco
> = >
> > Clothes make the man. Naked people have little or no = influence on
> > society. --Mark Twain
> = >
>

> = _______________________________________________
> ANCP mailing = list
> ANCP@ietf.org
> https://www.ietf.org/= mailman/listinfo/ancp


--
---
Toerless Eckert, = eckert@cisco.com
Cisco NSSTG Systems & Technology = Architecture
"The strategy is what you do, not what you write" - = Wesley Clark

------_=_NextPart_001_01C8A48F.1B0D4F15-- --===============0822445335== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============0822445335==-- From ancp-bounces@ietf.org Tue Apr 22 09:08:47 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78CA13A6E5A; Tue, 22 Apr 2008 09:08:47 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12AB33A6C63 for ; Tue, 22 Apr 2008 09:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgTzUTigdpR3 for ; Tue, 22 Apr 2008 09:08:41 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2FB083A6E4A for ; Tue, 22 Apr 2008 09:08:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,695,1199660400"; d="scan'208,217";a="7010788" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 22 Apr 2008 18:08:44 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3MG8itG009833 for ; Tue, 22 Apr 2008 18:08:44 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3MG8hVB011125 for ; Tue, 22 Apr 2008 16:08:44 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Apr 2008 18:08:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Apr 2008 18:08:40 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP message length field thread-index: AcikfcgluibF+DjWTfupYAEgs2PQXQAFCpLw References: From: "Wojciech Dec (wdec)" To: X-OriginalArrivalTime: 22 Apr 2008 16:08:43.0895 (UTC) FILETIME=[23454870:01C8A493] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12864; t=1208880524; x=1209744524; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20[ANCP]=20ANCP=20message=20length=20fiel d |Sender:=20; bh=yOOVJuuKTkhXcJaL7Nn1Os6GI0ryAslV0G2jwHota74=; b=vtGwPW+ijq+LTM8Rcm3iaarRVgkd9UbHLx09rjW4ROEdJRPmkM0SMQDakY B3uul4M4E1QxB2kRI56VJhR0w1LUmrIxmOAE4vT44DSJq1UvCaQw62CP92Wd Daz6aVwkQv; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [ANCP] ANCP message length field X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0608835022==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0608835022== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A493.23237925" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A493.23237925 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adding one note regarding the options for carrying PDUs exceeding 64kb. Using other GSMP derived notions in proposal options 2a and 2b it would be possible to set a "result" field flag to indicate the continuation of a fregmented PDU, with the transaction identifier allowing the possibility to stitch back together such a message. An implementation would however have to pay close attention to this flag, and the fact that overall legth of the message would be the sum of two (or more) length fields. ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: 22 April 2008 15:36 To: ancp@ietf.org Subject: [ANCP] ANCP message length field =09 =09 Hi Folks,=20 As part of our GSMP legacy we've inherited some base protocol header fields that, for lack of a better word, are largely useless for ANCP. An example of such a field are the dual message Length field deriving from rfc3292 and rfc3293, both of which in ANCP carry the same value (it's not at all clear why rfc3293 needed such a field, but that's a different story). This is shown in more detail below in the form of an ANCP header: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Type (0x88-0C) | Length |=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Vers | Sub |MessageType | Result| Code |=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Partition ID | Transaction Identifier |=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |I| SubMessage Number | Length |=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 RFC 3293 defines the first "Length" field to be: This 2-byte unsigned integer indicates the total length of the=20 GSMP message only. It does not include the 4-byte TLV header.=20 RFC 3292 defines the second "Length" field to be: Length of the GSMP message including its header fields and=20 defined GSMP message body. The length of additional data=20 appended to the end of the standard message SHOULD be included=20 in the Length field.=20 It's thus quite clear that the two fields, in ANCP's case, carry the same value and it appears reasonable to think of possible changes:. Proposal 1.=20 The "additional data" possibility is to be dropped. There appears to be no reason to transmit non ANCP data in ANCP.=20 Proposal 2 - Option a.=20 Re-define the Sub-message Number and Length fields to convey really a Sub-message Number and Sub-Message Length, and allow multiple commands to be bundled under the same transaction header, which appears interesting in the perspective of multicast control, and line configuration use-cases. Backwards compatibility with existing implementations could be maintained since currently all ANCP's applications set the I flag to "0". Implementations supporting this change, would most likely be required to send the so-far commonly implemented Port-up/down and OAM "legacy" messages with the I flag set to "1". Proposal 2 Option b.=20 Instead of using the Sub-message number and 2nd Length fields, we define these to be reserved fields of no use in ANCP.=20 Proposal 2 Option c.=20 Define the 1st Length field to be reserved fields of no use in ANCP, using instead only the Sub Message and Length fields to stitch together ANCP messages that go over 64kb boundary. Proposal 2 Option d=20 Continue using both fields as today, but refine the Sub-message and Length field to allow for messages over 64kb.=20 I solicit the WG's feedback regarding these proposed changes.=20 Regards,=20 Woj.=20 ------_=_NextPart_001_01C8A493.23237925 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ANCP message length field
Adding one note regarding the options for carrying PDUs = exceeding=20 64kb. Using other GSMP derived notions in proposal options 2a and = 2b it=20 would be possible to set a "result" field flag to indicate the = continuation=20 of a fregmented PDU, with the transaction identifier allowing the = possibility to=20 stitch back together such a message. An implementation would however = have to pay=20 close attention to this flag, and the fact that overall legth of the = message=20 would be the sum of two (or more) length fields.

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec=20 (wdec)
Sent: 22 April 2008 15:36
To:=20 ancp@ietf.org
Subject: [ANCP] ANCP message length=20 field

Hi = Folks,

As part of our GSMP = legacy we've=20 inherited some base protocol header fields that, for lack of a better = word,=20 are largely useless for ANCP. An example of such a field are the dual = message=20 Length field deriving from rfc3292 and rfc3293, both of which in ANCP = carry=20 the same value (it's not at all clear why rfc3293 needed such a field, = but=20 that's a different story). This is shown in more detail below in the = form of=20 an ANCP header:


      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 = 5 6 7 8 9=20 0 1 2 3 4 5 6 7 8 9 0 1
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /SPAN>=20
    =20 |        Type=20 (0x88-0C)        =20 |          =20 = Length           &= nbsp; =20 |
    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
     | Vers  |  Sub =20 |MessageType    |=20 Result|       =20 Code           |=20
    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
     | Partition ID =20 |           =20 Transaction=20 = Identifier          &nb= sp; =20 |
    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
     |I|      = SubMessage=20 Number     =20 |          =20 = Length           &= nbsp; =20 |
    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20

RFC 3293 defines the = first=20 "Length" field to be:       This 2-byte unsigned integer = indicates=20 the total length of the
      GSMP = message=20 only.  It does not include the 4-byte TLV header. =


RFC 3292 defines the = second=20 "Length" field to be: Length of the GSMP message including its header = fields=20 and
         defined GSMP = message=20 body.  The length of additional data
         appended to = the end of=20 the standard message SHOULD be included
         in the = Length=20 field.

It's thus quite = clear that the two=20 fields, in ANCP's case, carry the same value and it appears reasonable = to=20 think of possible changes:.

Proposal 1.=20
The = "additional=20 data" possibility is to be dropped. There appears to be no reason to = transmit=20 non ANCP data in ANCP.

Proposal 2 - Option=20 a.
Re-define the=20 Sub-message Number and Length fields to convey really a Sub-message = Number and=20 Sub-Message Length, and allow multiple commands to be bundled under = the same=20 transaction header, which appears interesting in the perspective of = multicast=20 control, and line configuration use-cases. Backwards compatibility = with=20 existing implementations could be maintained since currently all = ANCP's=20 applications set the I flag to "0". Implementations supporting this = change,=20 would most likely be required to send the so-far commonly implemented=20 Port-up/down and OAM "legacy" messages with the I flag set to=20 "1".

Proposal 2 Option = b.=20
Instead of using = the Sub-message=20 number and 2nd Length fields, we define these to be reserved fields of = no use=20 in ANCP.

Proposal 2 Option = c.=20
Define the 1st = Length field to be=20 reserved fields of no use in ANCP, using instead only the Sub Message = and=20 Length fields to stitch together ANCP messages that go over 64kb=20 boundary.

Proposal 2 Option = d=20
Continue using both = fields as=20 today, but refine the Sub-message and Length field to allow for = messages over=20 64kb.

I solicit the WG's = feedback=20 regarding these proposed changes.

Regards,
Woj.=20

------_=_NextPart_001_01C8A493.23237925-- --===============0608835022== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============0608835022==-- From ancp-bounces@ietf.org Wed Apr 23 02:20:01 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54B893A6CA3; Wed, 23 Apr 2008 02:20:01 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 797F53A6A9B for ; Wed, 23 Apr 2008 02:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wviBLOkMhnQ8 for ; Wed, 23 Apr 2008 02:19:59 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 5D8D13A6C37 for ; Wed, 23 Apr 2008 02:19:58 -0700 (PDT) Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m3N9Equc025513; Wed, 23 Apr 2008 11:15:01 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS07.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 23 Apr 2008 11:19:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Apr 2008 11:19:51 +0200 Message-ID: <7168964CAC5C144685272595141B6DBA80093A@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <000201c88a99$35dceec0$6b11530a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] draft-mammoliti-l2tp-accessline-avp Thread-Index: AciKmR8Zp+7FD8imSpuX4LxjMB4cXAaiPRdg References: <000201c88a99$35dceec0$6b11530a@amer.cisco.com> From: "OOGHE Sven" To: "Vince Mammoliti" , X-OriginalArrivalTime: 23 Apr 2008 09:19:52.0083 (UTC) FILETIME=[2F959630:01C8A523] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: draft-mammoliti-l2tp-accessline-avp@tools.ietf.org Subject: Re: [ANCP] draft-mammoliti-l2tp-accessline-avp X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Vince, Sorry for the late response. Generally I'm ok with this draft. My only remark would be that this must be passed via the DSL Forum to get their blessing as you're proposing to use their Vendor ID - see section 5: "The Vendor ID for all the listed AVP (Section 5.1 through Section 5.19) is that of the IANA assigned ADSL Forum Vendor ID, decimal 3561" Regards, Sven -----Original Message----- From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Vince Mammoliti Sent: donderdag 20 maart 2008 15:47 To: ancp@ietf.org Cc: draft-mammoliti-l2tp-accessline-avp@tools.ietf.org Subject: [ANCP] draft-mammoliti-l2tp-accessline-avp I am sending out this draft for review to the ancp group. Please provide your comments as we would like to move this draft forward. http://www.ietf.org/internet-drafts/draft-mammoliti-l2tp-accessline-avp- 02.t xt This document describes a set of Layer 2 Tunneling Protocol (L2TP) Attribute Value Pair (AVP) extensions designed to carry the Access Line information which is not currently available by the existing L2TP AVP set. It is expected that this document will be updated if and when new line information is available, since its primary purpose is to provide a reference for DSL equipment vendors wishing to interoperate with other vendors' products. Vince Mammoliti _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Apr 23 05:54:16 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EFF53A6909; Wed, 23 Apr 2008 05:54:16 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17FB83A68A9 for ; Wed, 23 Apr 2008 05:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBK8i6FyhT8n for ; Wed, 23 Apr 2008 05:54:09 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 59B0D3A6909 for ; Wed, 23 Apr 2008 05:54:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,698,1199660400"; d="scan'208,217";a="7099709" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 23 Apr 2008 14:54:04 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3NCs4nY024401 for ; Wed, 23 Apr 2008 14:54:04 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3NCs4nD001162 for ; Wed, 23 Apr 2008 12:54:04 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Apr 2008 14:54:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Apr 2008 14:53:49 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mandatory TLVs in draft-ietf-ancp-protocol proposal thread-index: AcilQRMfK4kdawUKQOWs5fdBngS8QQ== From: "Wojciech Dec (wdec)" To: X-OriginalArrivalTime: 23 Apr 2008 12:54:04.0765 (UTC) FILETIME=[1C6138D0:01C8A541] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9804; t=1208955244; x=1209819244; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20Mandatory=20TLVs=20in=20draft-ietf-ancp-protoco l=20proposal |Sender:=20; bh=HSqRSO+A4c+SUu6t1sSFRuKZ/yTbUAIOOYN5IKDPl9U=; b=tbt9F6g2zFEi5fHNzPdkwyF288zFOhRldZniYBkeLAux8C6zopnWEKS0IJ Lh4Jw7a97t7XSR/YuCQfAktdS9tIA6AjIqMeHfV8Dno1U/uEIbE9+PxDAUID 5KT4V30paW; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0822316564==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0822316564== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A541.1C4555EF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A541.1C4555EF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, Continuing with the series of e-mails regarding basic protocol issues still to be addressed, I now would now like to ask your feedback regarding the distinction the protocol places on mandatory TLVs. Given the length of this mail I'll first cut to the proposal, and after it you can find the problem description. The proposal which I am putting in front of the WG is to define a new TLV format which contains at a minimum a Mandatory flag (much like Radius VSAs do). We could have this TLV Flag be defined only for new applications. A second proposal would be try to make this flag work with existing ones by for example defining the highest order bit of the TLV# field to mean "Mandatory" when set to "0". This would be invisible to exiting implementations, but newer ones may have problems in communicating with older ones when the latter do not send all TLVs. But that can also be addressed by simply forming the set of mandatory TLVs to be the ones that all implementations currently send by default. Without additional feedback, I will assume that the WG is fine with the first proposal, and also with the 2nd one conditional on deriving a suitable "commonly used" TLV set. The problem in more detail:=20 Currently the situation is that Mandatory TLVs are only stated to be as such in the body of the protocol draft spec, with an implementer having to scour fairly attentively the text. Eg "Type (Access-Loop-Circuit-ID = =3D 0x01): This is a mandatory TLV", etc. The behaviour of an implementation that receives a message with a missing mandatory TLV is not defined at all, and the opposite is handled but not very robustly, i.e. when receiving a TLV but not recognizing it, and implementation is free to discard it (even if it is mandatory!). This is a recipe for interoperability problems and an implementation mine field. This problem is complicated by different applications. For example the current OAM section states the following regarding TLVs that are to be carried in the request message (my italics): " Following TLVs can appear in this message:=20 o Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section = 5.4.1 o Type (Access-Aggregation-Circuit-ID-Binary =3D 0x06): defined = in=20 section 5.4.1.=20 =20 o Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03): defined in section=20 5.4.1. =20 o Type (OAM-Loopback-Test-Parameters =3D 0x07): Parameters = related to =20 loopback test. This is an optional TLV. If this TLV is not present=20 in the request message, the DSLAM SHOULD use locally determined default values for the test parameters. =20 " (NOTE: The last "SHOULD" appears to be inappropriate. If the TLV is missing, the DSLAM MUST have some default parameters, or return an error) The "can" above indicates that they're all optional, while clearly the application cannot run its course without one or more of these fields. Here we have a case where one could have a perfectly compliant implementation that ignores all these TLVs... -Woj. ------_=_NextPart_001_01C8A541.1C4555EF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mandatory TLVs in draft-ietf-ancp-protocol proposal

Hi = All,

Continuing with = the series of e-mails regarding basic protocol issues still to be = addressed, I now would now like to ask your feedback regarding the = distinction the protocol places on mandatory TLVs. Given the length of = this mail I'll first cut to the proposal, and after it you can find the = problem description.

The proposal which = I am putting in front of the WG is to define a new TLV format which = contains at a minimum a Mandatory flag (much like Radius VSAs do). We = could have this TLV Flag be defined only for new = applications.

A second proposal = would be try to make this flag work with existing ones by for example = defining the highest order bit of the TLV# field to mean = "Mandatory" when set to "0". This would be invisible = to exiting implementations, but newer ones may have problems in = communicating with older ones when the latter do not send all TLVs. But = that can also be addressed by simply forming the set of mandatory TLVs = to be the ones that all implementations currently send by = default.

Without additional = feedback, I will assume that the WG is fine with the first proposal, and = also with the 2nd one conditional on deriving a suitable "commonly = used" TLV set.

The problem in = more detail:

Currently the = situation is that Mandatory TLVs are only stated to be as such in the = body of the protocol draft spec, with an implementer having to scour = fairly attentively the text. Eg "Type (Access-Loop-Circuit-ID =3D = 0x01): This is a mandatory TLV", etc.

The behaviour of = an implementation that receives a message with a missing mandatory TLV = is not defined at all, and the opposite is handled but not very = robustly, i.e. when receiving a TLV but not recognizing it, and = implementation is free to discard it (even if it is mandatory!). This is = a recipe for interoperability problems and an implementation mine = field.

This problem is = complicated by different applications. For example the current OAM = section states the following regarding TLVs that are to be carried in = the request message (my italics):

"
Following TLVs can appear in = this message:

       o Type (Access-Loop-Circuit-ID = =3D 0x01) : defined in section 5.4.1   

       o Type = (Access-Aggregation-Circuit-ID-Binary =3D 0x06): defined in =
         = section 5.4.1.
 
       o Type = (Access-Aggregation-Circuit-ID-ASCII =3D 0x03): defined in section =
         = 5.4.1. 

       o Type = (OAM-Loopback-Test-Parameters =3D 0x07): Parameters related to  =
         = loopback test. This is an optional TLV. If this TLV is not present =
         in = the request message, the DSLAM SHOULD use locally determined =
         = default values for the test parameters. 
"
(NOTE: The last "SHOULD" appears to be = inappropriate. If the TLV is missing, the DSLAM MUST have some default = parameters, or return an error)

The "can" above indicates that they're all = optional, while clearly the application cannot run its course without = one or more of these fields. Here we have a case where one could have a = perfectly compliant implementation that ignores all these = TLVs…

-Woj.












------_=_NextPart_001_01C8A541.1C4555EF-- --===============0822316564== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============0822316564==-- From ancp-bounces@ietf.org Thu Apr 24 04:13:15 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F42A3A6913; Thu, 24 Apr 2008 04:13:15 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 420B328C110 for ; Thu, 24 Apr 2008 04:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oD9zTNOWCyi for ; Thu, 24 Apr 2008 04:13:12 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id 83A2D3A6AF8 for ; Thu, 24 Apr 2008 04:13:11 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail21.telekom.de with ESMTP for ancp@ietf.org; Thu, 24 Apr 2008 13:13:15 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Apr 2008 13:13:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Apr 2008 13:13:14 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1CFBC5C4@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <1B6169C658325341A3B8066E23919E1C01230DC1@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal thread-index: AcilQRMfK4kdawUKQOWs5fdBngS8QQAAr04QACRhApA= From: "Busser, M" To: X-OriginalArrivalTime: 24 Apr 2008 11:13:15.0229 (UTC) FILETIME=[30FD08D0:01C8A5FC] Cc: "Haag, T" Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1825881548==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1825881548== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A5FC.3098B33C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A5FC.3098B33C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Woi, all =20 I see the problem but i can not see, how an additional flag will help = solving this problem. =20 Lets assume your first proposal. If an implementation does not send the complete TLV, even it is defined = to be mandatory, I would call this a bug and I can not see, how an = additional flag can help here. =20 Your second proposal seems obviously be required to keep existing things = working, if we agree on your first proposal.=20 But from my point of view it also assumes, that all existing = implementations are using the same set of TLVs now.=20 And I am not sure about that.=20 =20 Therefore I disagree with your first proposal. I recommend, the better = way will be to be more precise in definitions. In my mind, it is a bug, if a mandatory TLV is missing. It is up to the = robustness of the implementation to deal with this situation. Is it really neccesary to define the behavior of a network element in = this case of failure in the ancp protocol itself?=20 =20 If optional TLVs are not present in a message, we should describe some = kind of default behaviour, as you already stated. =20 =20 =20 =20 Comments on draft-ietf-ancp-protocol-02.txt: =20 It is not clearly stated, if the TLV "DSL Line Attributes " is = mandatory or optional.=20 In fact it is mandatory because some of its SubTLVs are mandatory.=20 We should spent a sentence to make this clear. =20 It is not clearly stated, if the TLV "Service-Profile-Name" is = mandatory or optional. I prefer mandatory because it is essetial for the use case Line Config.=20 =20 Section 5.4.3 Line Config, where the TLVs are mentioned (page 35): ...defined in section 5.4.1.... must be corrected to ...defined = in section 5.4.2........ =20 Section 5.4.4 OAM, where the TLVs are mentioned (page 36 and page 38): ...defined in section 5.4.1.... must be corrected to ...defined = in section 5.4.2........ =20 =20 =20 =20 Best Regards; Freundliche Gr=FC=DFe=20 Michael Busser T-Systems Enterprise Services GmbH=20 Production Line Network Centric Systems ICT-Systems Integration Network Integration Services =20 Br=FCckes 2 -8, 55545 Bad Kreuznach Postfach 9100, 55541 Bad Kreuznach +49 671 8333 8911 (Phone) +49 521 9210 3859 (Fax) +49 151 1211 9689 (Mobile) E-Mail: michael.busser@t-systems.com Internet: http://www.t-systems.com =20 =20 T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Reinhard Clemens (Vorsitzender)*, Helmut Binder, = Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Wilfried = Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG =20 Notice: This transmittal and/or attachments may be privileged or = confidential. If you are not the intended recipient, you are hereby = notified that you have received this transmittal in error; any review, = dissemination, or copying is strictly prohibited. If you received this = transmittal in error, please notify us immediately by reply and = immediately delete this message and all its attachments. Thank you.=20 T-Systems - Business flexibility=20 =20 =09 =09 ________________________________ Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag = von Wojciech Dec (wdec) Gesendet: Mittwoch, 23. April 2008 14:54 An: ancp@ietf.org Betreff: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal =20 Hi All,=20 Continuing with the series of e-mails regarding basic protocol issues = still to be addressed, I now would now like to ask your feedback = regarding the distinction the protocol places on mandatory TLVs. Given = the length of this mail I'll first cut to the proposal, and after it you = can find the problem description. The proposal which I am putting in front of the WG is to define a new = TLV format which contains at a minimum a Mandatory flag (much like = Radius VSAs do). We could have this TLV Flag be defined only for new = applications. A second proposal would be try to make this flag work with existing = ones by for example defining the highest order bit of the TLV# field to = mean "Mandatory" when set to "0". This would be invisible to exiting = implementations, but newer ones may have problems in communicating with = older ones when the latter do not send all TLVs. But that can also be = addressed by simply forming the set of mandatory TLVs to be the ones = that all implementations currently send by default. Without additional feedback, I will assume that the WG is fine with the = first proposal, and also with the 2nd one conditional on deriving a = suitable "commonly used" TLV set. The problem in more detail:=20 Currently the situation is that Mandatory TLVs are only stated to be as = such in the body of the protocol draft spec, with an implementer having = to scour fairly attentively the text. Eg "Type (Access-Loop-Circuit-ID = =3D 0x01): This is a mandatory TLV", etc. The behaviour of an implementation that receives a message with a = missing mandatory TLV is not defined at all, and the opposite is handled = but not very robustly, i.e. when receiving a TLV but not recognizing it, = and implementation is free to discard it (even if it is mandatory!). = This is a recipe for interoperability problems and an implementation = mine field. This problem is complicated by different applications. For example the = current OAM section states the following regarding TLVs that are to be = carried in the request message (my italics): "=20 Following TLVs can appear in this message:=20 o Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section = 5.4.1 =20 o Type (Access-Aggregation-Circuit-ID-Binary =3D 0x06): defined = in=20 section 5.4.1.=20 =20 o Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03): defined = in section=20 5.4.1. =20 o Type (OAM-Loopback-Test-Parameters =3D 0x07): Parameters = related to =20 loopback test. This is an optional TLV. If this TLV is not = present=20 in the request message, the DSLAM SHOULD use locally = determined=20 default values for the test parameters. =20 "=20 (NOTE: The last "SHOULD" appears to be inappropriate. If the TLV is = missing, the DSLAM MUST have some default parameters, or return an = error) The "can" above indicates that they're all optional, while clearly the = application cannot run its course without one or more of these fields. = Here we have a case where one could have a perfectly compliant = implementation that ignores all these TLVs... -Woj.=20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 ------_=_NextPart_001_01C8A5FC.3098B33C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nachricht</TIT= LE> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.6000.16608" name=3DGENERATOR><!--[if !mso]> <STYLE>v\:* { BEHAVIOR: url(#default#VML) } o\:* { BEHAVIOR: url(#default#VML) } w\:* { BEHAVIOR: url(#default#VML) } .shape { BEHAVIOR: url(#default#VML) } </STYLE> <![endif]--> <STYLE>@font-face { font-family: Tahoma; } @page Section1 {size: 595.3pt 841.9pt; margin: 70.85pt 70.85pt 2.0cm = 70.85pt; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline } A:visited { COLOR: purple; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline } P { FONT-SIZE: 12pt; MARGIN-LEFT: 0cm; MARGIN-RIGHT: 0cm; FONT-FAMILY: = "Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto } SPAN.E-MailFormatvorlage18 { COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply } DIV.Section1 { page: Section1 } </STYLE> </HEAD> <BODY lang=3DDE vLink=3Dpurple link=3Dblue> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>Hi = Woi,=20 all</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>I see = the problem=20 but i can not see, how an additional flag will help solving this=20 problem.</FONT></SPAN></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>Lets = assume your=20 first proposal.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>If an=20 implementation does not send the complete TLV, even it is = defined to=20 be mandatory, I would call this a bug and I can not see, = how an=20 additional flag can help here.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>Your = second proposal=20 seems obviously be required to keep existing things working, if=20 we agree on your first proposal. </FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>But = from my point of=20 view it also assumes, that all existing implementations are using = the same=20 set of TLVs now. </FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>And I am not=20 sure about that. </FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2><SPAN=20 class=3D364043506-24042008><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV></FONT></SPAN> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Therefore I disagree=20 with your first proposal. I recommend, the better way will be to be = more=20 precise in definitions.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>In my = mind, it is a=20 bug, if a mandatory TLV is missing. It is up to the robustness of the=20 implementation to deal with this situation.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>Is it = really=20 neccesary to define the behavior of a network element in this case of = failure in=20 the ancp protocol itself? </FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>If = optional TLVs are=20 not present in a message, we should describe some kind of default = behaviour, as=20 you already stated.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Comments on=20 draft-ietf-ancp-protocol-02.txt:</FONT></SPAN></DIV></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT = face=3DArial>It is not=20 clearly stated, if the TLV  "<SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA">DSL=20 Line Attributes "<FONT face=3DArial> is mandatory or optional.=20 </FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT = face=3DArial><SPAN=20 lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>In fact it is mandatory because some of its SubTLVs are = mandatory.=20 </FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT = face=3DArial><SPAN=20 lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>We should spent a sentence to make this=20 clear.</FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2><SPAN=20 class=3D364043506-24042008><FONT size=3D2><FONT face=3DArial>It is not = clearly=20 stated, if the TLV  "<SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: = AR-SA">Service-Profile-Name"<FONT=20 face=3DArial> is mandatory or=20 optional.</FONT></SPAN></FONT></FONT></SPAN></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2><SPAN=20 class=3D364043506-24042008><FONT size=3D2><FONT face=3DArial><SPAN = lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>I prefer mandatory because it is essetial for the use case = Line=20 Config. </FONT></SPAN></FONT></FONT></SPAN></DIV></FONT></SPAN><SPAN= =20 class=3D364043506-24042008><FONT face=3DArial size=3D2></FONT></SPAN> <DIV><SPAN class=3D364043506-24042008></SPAN><SPAN = class=3D364043506-24042008><FONT=20 face=3DArial size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Section 5.4.3 Line=20 Config, where the TLVs are mentioned (page 35):</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>  = ...defined in=20 section 5.4.1....    must be corrected = to   =20 ...defined in section 5.4.2........</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Section=20 5.4.4 OAM, where the TLVs are mentioned (page 36 and page=20 38):</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>  = ...defined in=20 section 5.4.1....    must be corrected = to   =20 ...defined in section 5.4.2........</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV></FONT></SPAN><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV></DIV> <DIV><SPAN class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN = class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN = class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV align=3Dleft><FONT color=3D#000080 size=3D2> <P align=3Dleft>Best Regards; Freundliche Gr=FC=DFe </P></FONT><B><FONT = color=3D#000080> <P>Michael Busser</P></B></FONT><FONT size=3D1> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: = 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt">T-Systems=20 Enterprise Services GmbH </SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: = 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1>Production Line Network Centric Systems</FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: = 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1>ICT-Systems Integration</FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: = 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1>Network Integration Services</FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: = 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1></FONT><SPAN style=3D"COLOR: navy"></SPAN><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy"><FONT face=3DArial = color=3D#000000=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: = 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy"><FONT color=3D#000000 = size=3D1>Br=FCckes 2 -8,=20 55545 Bad Kreuznach<BR>Postfach 9100, 55541 Bad Kreuznach<BR>+49 671 = 8333 8911=20 (Phone)<BR>+49 521 9210 3859 (Fax)<BR>+49 151 1211 9689=20 (Mobile)<BR>E-Mail: <A=20 href=3D"mailto:michael.busser@t-systems.com">michael.busser@t-systems.com= </A></FONT></SPAN></DIV></SPAN> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: = 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: = 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN></DIV><SPAN style=3D"FONT-SIZE: = 8pt">Internet:=20 </SPAN><SPAN style=3D"FONT-SIZE: 8pt"><p:onmouseclick=20 href=3D"http://www.t-systems.com/" = hyperlinktype=3D"url"></p:onmouseclick><A=20 onclick=3Dwindow.event.cancelBubble=3Dtrue; = href=3D"http://www.t-systems.com/"=20 target=3D_parent><FONT=20 color=3D#6699ff>http://www.t-systems.com</FONT></A></SPAN><SPAN=20 style=3D"FONT-SIZE: 8pt"> </SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN> </DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D3><FONT size=3D1><SPAN=20 style=3D"FONT-SIZE: 7.5pt; COLOR: black; FONT-FAMILY: Arial">T-Systems = Enterprise=20 Services GmbH<BR>Aufsichtsrat: Ren=E9 Obermann = (Vorsitzender)<BR>Executive=20 Committee: Reinhard Clemens (Vorsitzender)*, Helmut Binder, Albert Henn, = Olaf=20 Heyden*, Katrin Horstmann, Ulrich Kemp, Wilfried Peters*,<BR>Dr. Herbert = Schaaff*, Zvezdana Seeger*<BR>Handelsregister: Amtsgericht Frankfurt am = Main HRB=20 55933<BR>Sitz der Gesellschaft: Frankfurt am Main<BR>WEEE-Reg.-Nr.=20 DE87523644<BR>*Gesch=E4ftsf=FChrer gem. =A7 35 = GmbHG</SPAN></FONT></FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT face=3DArial = size=3D2></FONT></SPAN></SPAN> </DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT size=3D1>Notice: This transmittal and/or = attachments=20 may be privileged or confidential. If you are not the intended = recipient, you=20 are hereby notified that you have received this transmittal in error; = any=20 review, dissemination, or copying is strictly prohibited. If you = received this=20 transmittal in error, please notify us immediately by reply and = immediately=20 delete this message and all its attachments. Thank you. </FONT><FONT=20 size=3D1><BR>T-Systems =96 Business flexibility = </FONT></DIV></SPAN></SPAN> <DIV><FONT face=3DArial size=3D2></FONT> </DIV></FONT></DIV> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"> <DIV></DIV> <DIV class=3DOutlookMessageHeader lang=3Dde dir=3Dltr align=3Dleft> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: = Arial"><o:p></o:p></SPAN></FONT></P><FONT=20 face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: = 12pt"><FONT face=3DArial=20 size=3D2></FONT> <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2> </SPAN></FONT></DIV> <DIV class=3DSection1> <DIV> <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: = Tahoma">Von:</SPAN></FONT></B><FONT=20 face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Tahoma">=20 ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] <B><SPAN=20 style=3D"FONT-WEIGHT: bold">Im Auftrag von </SPAN></B>Wojciech Dec=20 (wdec)<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Gesendet:</SPAN></B> = Mittwoch,=20 23. April 2008 14:54<BR><B><SPAN style=3D"FONT-WEIGHT: = bold">An:</SPAN></B>=20 ancp@ietf.org<BR><B><SPAN style=3D"FONT-WEIGHT: = bold">Betreff:</SPAN></B> [ANCP]=20 Mandatory TLVs in draft-ietf-ancp-protocol=20 proposal</SPAN></FONT><o:p></o:p></P></DIV> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi = All,</SPAN></FONT><SPAN=20 lang=3DEN-GB> </SPAN><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Continuing with the = series of=20 e-mails regarding basic protocol issues still to be addressed, I now = would now=20 like to ask your feedback regarding the distinction the protocol = places on=20 mandatory TLVs. Given the length of this mail I'll first cut to the = proposal,=20 and after it you can find the problem=20 description.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The proposal which I am = putting in=20 front of the WG is to define a new TLV format which contains at a = minimum a=20 Mandatory flag (much like Radius VSAs do). We could have this TLV Flag = be=20 defined only for new applications.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">A second proposal would = be try to=20 make this flag work with existing ones by for example defining the = highest=20 order bit of the TLV# field to mean "Mandatory" when set to "0". This = would be=20 invisible to exiting implementations, but newer ones may have problems = in=20 communicating with older ones when the latter do not send all TLVs. = But that=20 can also be addressed by simply forming the set of mandatory TLVs to = be the=20 ones that all implementations currently send by=20 default.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Without additional = feedback, I=20 will assume that the WG is fine with the first proposal, and also with = the 2nd=20 one conditional on deriving a suitable "commonly used" TLV=20 set.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The problem in more = detail:=20 </SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Currently the situation = is that=20 Mandatory TLVs are only stated to be as such in the body of the = protocol draft=20 spec, with an implementer having to scour fairly attentively the text. = Eg=20 "Type (Access-Loop-Circuit-ID =3D 0x01): This is a mandatory TLV",=20 etc.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The behaviour of an = implementation=20 that receives a message with a missing mandatory TLV is not defined at = all,=20 and the opposite is handled but not very robustly, i.e. when receiving = a TLV=20 but not recognizing it, and implementation is free to discard it (even = if it=20 is mandatory!). This is a recipe for interoperability problems and an=20 implementation mine field.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">This problem is = complicated by=20 different applications. For example the current OAM section states the = following regarding TLVs that are to be carried in the request message = (my=20 italics):</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">"</SPAN></FONT> = <BR><FONT=20 face=3D"Courier New" color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">Following=20 TLVs<B><I><SPAN style=3D"FONT-WEIGHT: bold; FONT-STYLE: italic">=20 can</SPAN></I></B> appear in this message: = </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section=20 5.4.1    </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (Access-Aggregation-Circuit-ID-Binary =3D 0x06): defined in=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 section 5.4.1. </SPAN></FONT><BR><FONT face=3D"Courier New" = color=3Dblack=20 size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'"> </SPAN></FONT>=20 <BR><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03): defined in = section=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 5.4.1.  </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (OAM-Loopback-Test-Parameters =3D 0x07): Parameters related = to =20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 loopback test. This is an optional TLV. If this TLV is not present=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 in the request message, the DSLAM SHOULD use locally determined=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 default values for the test parameters.  </SPAN></FONT><BR><FONT=20 face=3D"Courier New" color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">"</SPAN></FONT>=20 <BR><FONT face=3DArial color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">(NOTE: The = last=20 "SHOULD" appears to be inappropriate. If the TLV is missing, the DSLAM = MUST=20 have some default parameters, or return an = error)</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">The "can" = above=20 indicates that they're all optional, while clearly the application = cannot run=20 its course without one or more of these fields. Here we have a case = where one=20 could have a perfectly compliant implementation that ignores all these = TLVs=85</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = Arial">-Woj.</SPAN></FONT><SPAN=20 lang=3DEN-US> </SPAN><o:p></o:p></P> <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><FONT face=3D"Times = New Roman"=20 size=3D3><SPAN=20 style=3D"FONT-SIZE: = 12pt"><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><o:p></o:p></SPAN></FONT></= P></DIV></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C8A5FC.3098B33C-- --===============1825881548== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============1825881548==-- From ancp-bounces@ietf.org Thu Apr 24 04:56:51 2008 Return-Path: <ancp-bounces@ietf.org> X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6857E28C0D7; Thu, 24 Apr 2008 04:56:51 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C04EB3A682D for <ancp@core3.amsl.com>; Thu, 24 Apr 2008 04:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4chQDAi9baV for <ancp@core3.amsl.com>; Thu, 24 Apr 2008 04:56:48 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 4EB943A6C04 for <ancp@ietf.org>; Thu, 24 Apr 2008 04:56:08 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP for ancp@ietf.org; Thu, 24 Apr 2008 13:56:12 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Apr 2008 13:56:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8A602.30033CE1" Date: Thu, 24 Apr 2008 13:56:10 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1CFBC5C5@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal thread-index: AcimAi8p7t9nyaObSuqCLEf2fY/H5g== From: "Busser, M" <Michael.Busser@t-systems.com> To: <ancp@ietf.org> X-OriginalArrivalTime: 24 Apr 2008 11:56:11.0714 (UTC) FILETIME=[30B17220:01C8A602] Subject: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list <ancp.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/ancp> List-Post: <mailto:ancp@ietf.org> List-Help: <mailto:ancp-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=subscribe> Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A602.30033CE1 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C8A602.30033CE1" ------_=_NextPart_002_01C8A602.30033CE1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all =20 At the actual ANCP draft most of the Sub-TLVs in "DSL Line Attributes" = are optional. At the DSL Forum, this TLVs are mandatory. =20 I suggest to set them mandatory in ANCP as well to be in line with the = DSL Forum. =20 Another suggestion is to have a small table somewhere in the draft = (maybe an appendix) where all the TLVs are listed with their encodings an if they are = mandatory or optional. Please see attachement as an example. =20 =20 Best Regards; Freundliche Gr=FC=DFe=20 Michael Busser T-Systems Enterprise Services GmbH=20 Production Line Network Centric Systems ICT-Systems Integration Network Integration Services =20 Br=FCckes 2 -8, 55545 Bad Kreuznach Postfach 9100, 55541 Bad Kreuznach +49 671 8333 8911 (Phone) +49 521 9210 3859 (Fax) +49 151 1211 9689 (Mobile) E-Mail: michael.busser@t-systems.com Internet: http://www.t-systems.com <http://www.t-systems.com/> =20 =20 T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Reinhard Clemens (Vorsitzender)*, Helmut Binder, = Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Wilfried = Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG =20 Notice: This transmittal and/or attachments may be privileged or = confidential. If you are not the intended recipient, you are hereby = notified that you have received this transmittal in error; any review, = dissemination, or copying is strictly prohibited. If you received this = transmittal in error, please notify us immediately by reply and = immediately delete this message and all its attachments. Thank you.=20 T-Systems - Business flexibility=20 =20 =20 ------_=_NextPart_002_01C8A602.30033CE1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD><TITLE>Nachricht
Hi=20 all
 
At = the actual=20 ANCP draft most of the Sub-TLVs in "DSL Line Attributes"  are=20 optional.
At the = DSL Forum,=20 this TLVs are mandatory.
 
I = suggest to set=20 them mandatory in ANCP as well to be in line with the DSL=20 Forum.
 
Another suggestion=20 is to have a small table somewhere in the draft (maybe an=20 appendix)
where = all the TLVs=20 are listed with their encodings an if they are mandatory or=20 optional.
Please see=20 attachement as an example.  
 

Best Regards; Freundliche Gr=FC=DFe

Michael Busser
T-Systems=20 Enterprise Services GmbH
Production Line Network Centric Systems
ICT-Systems Integration
Network Integration Services
 
Br=FCckes 2 -8,=20 55545 Bad Kreuznach
Postfach 9100, 55541 Bad Kreuznach
+49 671 = 8333 8911=20 (Phone)
+49 521 9210 3859 (Fax)
+49 151 1211 9689=20 (Mobile)
E-Mail: michael.busser@t-systems.com=
Internet:=20 http://www.t-systems.com
 
T-Systems = Enterprise=20 Services GmbH
Aufsichtsrat: Ren=E9 Obermann = (Vorsitzender)
Executive=20 Committee: Reinhard Clemens (Vorsitzender)*, Helmut Binder, Albert Henn, = Olaf=20 Heyden*, Katrin Horstmann, Ulrich Kemp, Wilfried Peters*,
Dr. Herbert = Schaaff*, Zvezdana Seeger*
Handelsregister: Amtsgericht Frankfurt am = Main HRB=20 55933
Sitz der Gesellschaft: Frankfurt am Main
WEEE-Reg.-Nr.=20 DE87523644
*Gesch=E4ftsf=FChrer gem. =A7 35 = GmbHG
 
Notice: This transmittal and/or = attachments=20 may be privileged or confidential. If you are not the intended = recipient, you=20 are hereby notified that you have received this transmittal in error; = any=20 review, dissemination, or copying is strictly prohibited. If you = received this=20 transmittal in error, please notify us immediately by reply and = immediately=20 delete this message and all its attachments. Thank you.
T-Systems =96 Business flexibility =
 
 
------_=_NextPart_002_01C8A602.30033CE1-- ------_=_NextPart_001_01C8A602.30033CE1 Content-Type: application/msword; name="TLV_List.doc" Content-Transfer-Encoding: base64 Content-Description: TLV_List.doc Content-Disposition: attachment; filename="TLV_List.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAbQAAAAAAAAAA EAAAbwAAAAEAAAD+////AAAAAG4AAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEACUAJBAAA8BK/AAAAAAAAEAAAAAAABgAA2w0AAA4AYmpianHkceQAAAAAAAAAAAAAAAAAAAAA AAAHBBYAN2QAABOOAQATjgEA2wUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAIgAAAAAAMYBAAAAAAAAxgEAAMYB AAAAAAAAxgEAAAAAAADGAQAAAAAAAMYBAAAAAAAAxgEAABQAAAAAAAAAAAAAANoBAAAAAAAAIisA AAAAAAAiKwAAAAAAACIrAAAAAAAAIisAABwAAAA+KwAAPAEAANoBAAAAAAAAFDUAALYAAACGLAAA AAAAAIYsAAAAAAAAhiwAAAAAAACGLAAAAAAAAIYsAAAAAAAAhiwAAAAAAACGLAAAAAAAAIYsAAAA AAAAkzQAAAIAAACVNAAAAAAAAJU0AAAAAAAAlTQAAAAAAACVNAAAAAAAAJU0AAAAAAAAlTQAACQA AADKNQAAUgIAABw4AABiAAAAuTQAABUAAAAAAAAAAAAAAAAAAAAAAAAAxgEAAAAAAAAHLQAAAAAA AAAAAAAAAAAAAAAAAAAAAACGLAAAAAAAAIYsAAAAAAAABy0AAAAAAAAHLQAAAAAAALk0AAAAAAAA AAAAAAAAAADGAQAAAAAAAMYBAAAAAAAAhiwAAAAAAAAAAAAAAAAAAIYsAAAAAAAAzjQAABYAAAAv LwAAAAAAAC8vAAAAAAAALy8AAAAAAAAHLQAAAAAAAMYBAAAAAAAAhiwAAAAAAADGAQAAAAAAAIYs AAAAAAAAkzQAAAAAAAAAAAAAAAAAAC8vAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAABy0AAAAAAACTNAAAAAAAAAAAAAAAAAAALy8AAAAAAAAAAAAA AAAAAC8vAAAAAAAAxgEAAAAAAADGAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALy8AAAAAAACGLAAAAAAAAHosAAAMAAAAQEs5w/2l yAEAAAAAAAAAACIrAAAAAAAABy0AACIAAAAvLwAAAAAAAAAAAAAAAAAAdy8AABwFAADkNAAAMAAA ABQ1AAAAAAAALy8AAAAAAAB+OAAAAAAAACktAADwAQAAfjgAAAAAAAAvLwAAAAAAAAAAAAAAAAAA 2gEAAAAAAADaAQAAAAAAAMYBAAAAAAAAxgEAAAAAAADGAQAAAAAAAMYBAAAAAAAAAAAAAAAAAAAA AAAAAAAAAH44AAAAAAAAAAAAAAAAAADGAQAAAAAAAC8vAABIAAAAhiwAABQAAACaLAAADgAAAC8v AAAAAAAAqCwAAAwAAAC0LAAAUwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhiwA AAAAAACGLAAAAAAAAIYsAAAAAAAAuTQAAAAAAAC5NAAAAAAAANoBAAAAAAAA2gEAAOQVAAC+FwAA ZBMAAAAAAAAAAAAAGS8AABYAAADaAQAAAAAAANoBAAAAAAAAvhcAAAAAAAACAAEBAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1EZWZp bmVkIFRMVnM6DVNlY3Rpb24HVExWLU5hbWUHQ29kZQdBB0IHQwcHNS40LjIuMQdBY2Nlc3MtTG9v cC1DaXJjdWl0LUlEIAcweDAxB20HbQdtBwc1LjQuMi4yB0FjY2Vzcy1Mb29wLVJlbW90ZS1JZCAH MHgwMgdvB25hB25hBwc1LjQuMi40B0FjY2Vzcy1BZ2dyZWdhdGlvbi1DaXJjdWl0LUlELUFTQ0lJ BzB4MDMHbwdvB28HBzUuNC4yLjUHRFNMIExpbmUgQXR0cmlidXRlcyAHMHgwNAdtB25hB25hBwc1 LjQuMwdTZXJ2aWNlLVByb2ZpbGUtTmFtZSAHMHgwNQduYQdtB25hBwc1LjQuMi4zB0FjY2Vzcy1B Z2dyZWdhdGlvbi1DaXJjdWl0LUlELUJpbmFyeQcweDA2B28HbwdvBwc1LjQuNCAHT0FNLUxvb3Bi YWNrLVRlc3QtUGFyYW1ldGVycyAHMHgwNwduYQduYQdvBwc1LjQuNCAHT3BhcXVlLURhdGEgBzB4 MDgHbmEHbmEHbwcHNS40LjQgB09BTS1Mb29wYmFjay1UZXN0LVJlc3BvbnNlLVN0cmluZyAHMHgw OQduYQduYQdvBwdBID0gVG9wb2xvZ3kgRGlzY292ZXJ5DUIgPSBMaW5lIENvbmZpZ3VyYXRpb24N QyA9IE9BTQ1tID0gbWFuZGF0b3J5DW8gPSBvcHRpb25hbA1uYSA9IG5vdCBhcHBsaWNhYmxlDQ1E ZWZpbmVkIFN1Yi1UTFZzOg1TZWN0aW9uB1N1Yi1UTFYHQ29kZQdNYW5kYXRvcnkgLyBvcGlvbmFs IAcHNS40LjIuNQdBY3R1YWwtTmV0LURhdGEtUmF0ZS1VcHN0cmVhbSAHMHg4MSAHbQcHNS40LjIu NQdBY3R1YWwtTmV0LURhdGEtUmF0ZS1Eb3duc3RyZWFtIAcweDgyB20HBzUuNC4yLjUHTWluaW11 bS0gTmV0LURhdGEtUmF0ZS1VcHN0cmVhbSAHMHg4MyAHbwcHNS40LjIuNQdNaW5pbXVtLSBOZXQt RGF0YS1SYXRlLURvd25zdHJlYW0gBzB4ODQHbwcHNS40LjIuNQdBdHRhaW5hYmxlLSBOZXQtRGF0 YS1SYXRlLVVwc3RyZWFtIAcweDg1B28HBzUuNC4yLjUHQXR0YWluYWJsZS0gTmV0LURhdGEtUmF0 ZS1Eb3duc3RyZWFtBzB4ODYHbwcHNS40LjIuNQdNYXhpbXVtLSBOZXQtRGF0YS1SYXRlLVVwc3Ry ZWFtIAcweDg3B28HBzUuNC4yLjUHTWF4aW11bS0gTmV0LURhdGEtUmF0ZS1Eb3duc3RyZWFtBzB4 ODgHbwcHNS40LjIuNQdNaW5pbXVtLSBOZXQtTG93LVBvd2VyLURhdGEtUmF0ZS1VcHN0cmVhbSAH MHg4OSAHbwcHNS40LjIuNQdNaW5pbXVtLSBOZXQtTG93LVBvd2VyLURhdGEtUmF0ZS1Eb3duc3Ry ZWFtBzB4OEEHbwcHNS40LjIuNQdNYXhpbXVtLUludGVybGVhdmluZy1EZWxheS1VcHN0cmVhbSAH MHg4QgdvBwc1LjQuMi41B0FjdHVhbC1JbnRlcmxlYXZpbmctRGVsYXktVXBzdHJlYW0HMHg4QyAH bwcHNS40LjIuNQdNYXhpbXVtLUludGVybGVhdmluZy1EZWxheS1Eb3duc3RyZWFtIAcweDhEB28H BzUuNC4yLjUHQWN0dWFsLUludGVybGVhdmluZy1EZWxheS1Eb3duc3RyZWFtIAcweDhFB28HBzUu NC4yLjUHRFNMIGxpbmUgc3RhdGUgBzB4OEYHUE9SVC1VUAlvC1BPUlQtRE9XTgltBwc1LjQuMi41 B0FjY2VzcyBMb29wIEVuY2Fwc3VsYXRpb24gBzB4OTAgB28HBzUuNC4yLjUHRFNMLVR5cGUgBzB4 OTEgB20HBw0NDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAPCAAA FggAABcIAAAfCAAAIAgAACQIAAAlCAAAJggAACcIAAAoCAAAKQgAACoIAABRCAAAUggAAFMIAABU CAAAVQgAAFYIAAB8CAAAfQgAAH4IAACACAAAgQgAAIMIAAC2CAAAtwgAALgIAAC5CAAAuggAALsI AADfCAAA4AgAAOEIAADjCAAA5AgAAOYIAAAJCQAACwkAAAwJAAANCQAADgkAABAJAAA/CQAAQAkA AEQJAABFCQAARgkAAEcJAABICQAASQkAAHUJAAB3CQAAeAkAAHoJAAB7CQAAfAkAAJcJAACZCQAA mgkAAJwJAACdCQAAngkAAM8JAADRCQAA0gkAANQJAADVCQAA1gkAANgJAADlCQAA8eXW5dbl1uXW 5dbl1uXW5dbl1uXW5dbl1uXW5dbl1uXW5dbl1uXWytbl1uXW5dbl1uXW5dbl1uXW5dbl1uXW5dbl 1uXWvgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFhZoSHpOAENKFABhShQAbUgJCHNICQgAFhZo +xc6AENKFABhShQAbUgJCHNICQgAHBVoESHLABZohzjgAENKFABhShQAbUgJCHNICQgAFhZohzjg AENKFABhShQAbUgJCHNICQgAHBVoESHLABZoESHLAENKFABhShQAbUgJCHNICQhGAAYAAAEIAAAP CAAAFwgAACAIAAAlCAAAJwgAACkIAAArCAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAADxAAAA AAAAAAAAAAAA8QAAAAAAAAAAAAAAAOUAAAAAAAAAAAAAAADZAAAAAAAAAAAAAAAA2QAAAAAAAAAA AAAAANkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAADJAEWJAFJZgEAAABhJAFnZOgaIgAMAAADJAEW JAFJZgEAAABhJAFnZBEhywAJAAAWJAFJZgEAAABnZBEhywAABAAAZ2QRIcsAAAgABgAA2w0AAP4A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEBASsIAAAsCAAANAgA AEwIAAA4AAAAAAAAAAAAAAAALwAAAAAAAAAAAAAAAC8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAWJAFJZgEAAABnZBEhywAAxgAAa2QAAAAAFiQB FyQBSWYBAAAAApZGAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWiAAGlP9TA7gRfRS0FusY IhsABr8DAAAAAAAAAAAAAAAAAAAAAAAGZQ4AAAAAAAAAAAAAAAAAAAAAAAbFAgAAAAAAAAAAAAAA AAAAAAAABjcCAAAAAAAAAAAAAAAAAAAAAAAGNwIAAAAAAAAAAAAAAAAAAAAAAAY3AgAAAAAAAAAA AAAAAAAAAAAKdAAA4AET1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAA AAAA/wQBAAAU9gEAABU2ARf2AwAAGPYDAAAa1hgAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8b1hgA AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8c1hgAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8d1hgAAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gMAAAADTAgAAFEIAABTCAAA VQgAAFcIAADzAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADnAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAyQB FiQBSWYBAAAAYSQBZ2ToGiIADAAAAyQBFiQBSWYBAAAAYSQBZ2QRIcsAAARXCAAAWAgAAGAIAAB3 CAAAOAAAAAAAAAAAAAAAAC8AAAAAAAAAAAAAAAAvAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAFiQBSWYBAAAAZ2QRIcsAAMYAAGtkmwAAABYkARck AUlmAQAAAAKWRgAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1ogABpT/UwO4EX0UtBbrGCIb AAa/AwAAAAAAAAAAAAAAAAAAAAAABmUOAAAAAAAAAAAAAAAAAAAAAAAGxQIAAAAAAAAAAAAAAAAA AAAAAAY3AgAAAAAAAAAAAAAAAAAAAAAABjcCAAAAAAAAAAAAAAAAAAAAAAAGNwIAAAAAAAAAAAAA AAAAAAAACnQAAOABE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAA AP8EAQAAFPYBAAAVNgEX9gMAABj2AwAAGtYYAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/G9YYAAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/HNYYAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/HdYYAAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDAAAAA3cIAAB8CAAAfggAAIEI AACECAAA8wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAMkARYk AUlmAQAAAGEkAWdk6BoiAAwAAAMkARYkAUlmAQAAAGEkAWdkESHLAAAEhAgAAIUIAACNCAAAsQgA ADgAAAAAAAAAAAAAAAAvAAAAAAAAAAAAAAAALwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAABYkAUlmAQAAAGdkESHLAADGAABrZDYBAAAWJAEXJAFJ ZgEAAAAClkYABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNaIAAaU/1MDuBF9FLQW6xgiGwAG vwMAAAAAAAAAAAAAAAAAAAAAAAZlDgAAAAAAAAAAAAAAAAAAAAAABsUCAAAAAAAAAAAAAAAAAAAA AAAGNwIAAAAAAAAAAAAAAAAAAAAAAAY3AgAAAAAAAAAAAAAAAAAAAAAABjcCAAAAAAAAAAAAAAAA AAAAAAp0AADgARPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/ BAEAABT2AQAAFTYBF/YDAAAY9gMAABrWGAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/xvWGAAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/xzWGAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/x3WGAAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2AwAAAAOxCAAAtggAALgIAAC6CAAA vAgAAPMAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAADJAEWJAFJ ZgEAAABhJAFnZOgaIgAMAAADJAEWJAFJZgEAAABhJAFnZBEhywAABLwIAAC9CAAAxQgAANoIAAA4 AAAAAAAAAAAAAAAALwAAAAAAAAAAAAAAAC8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAWJAFJZgEAAABnZBEhywAAxgAAa2TRAQAAFiQBFyQBSWYB AAAAApZGAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWiAAGlP9TA7gRfRS0FusYIhsABr8D AAAAAAAAAAAAAAAAAAAAAAAGZQ4AAAAAAAAAAAAAAAAAAAAAAAbFAgAAAAAAAAAAAAAAAAAAAAAA BjcCAAAAAAAAAAAAAAAAAAAAAAAGNwIAAAAAAAAAAAAAAAAAAAAAAAY3AgAAAAAAAAAAAAAAAAAA AAAKdAAA4AET1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQB AAAU9gEAABU2ARf2AwAAGPYDAAAa1hgAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8b1hgAAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8c1hgAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8d1hgAAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gMAAAAD2ggAAN8IAADhCAAA5AgAAOcI AADzAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAyQBFiQBSWYB AAAAYSQBZ2ToGiIADAAAAyQBFiQBSWYBAAAAYSQBZ2QRIcsAAATnCAAA6AgAAO4IAAAECQAAOAAA AAAAAAAAAAAAAC8AAAAAAAAAAAAAAAAvAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAACQAAFiQBSWYBAAAAZ2QRIcsAAMYAAGtkbAIAABYkARckAUlmAQAA AAKWRgAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1ogABpT/UwO4EX0UtBbrGCIbAAa/AwAA AAAAAAAAAAAAAAAAAAAABmUOAAAAAAAAAAAAAAAAAAAAAAAGxQIAAAAAAAAAAAAAAAAAAAAAAAY3 AgAAAAAAAAAAAAAAAAAAAAAABjcCAAAAAAAAAAAAAAAAAAAAAAAGNwIAAAAAAAAAAAAAAAAAAAAA CnQAAOABE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAA FPYBAAAVNgEX9gMAABj2AwAAGtYYAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/G9YYAAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/HNYYAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/HdYYAAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDAAAAAwQJAAAJCQAADAkAAA4JAAARCQAA 8wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAMkARYkAUlmAQAA AGEkAWdk6BoiAAwAAAMkARYkAUlmAQAAAGEkAWdkESHLAAAEEQkAABIJAAAaCQAAPwkAADgAAAAA AAAAAAAAAAAvAAAAAAAAAAAAAAAALwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAkAABYkAUlmAQAAAGdkESHLAADGAABrZAcDAAAWJAEXJAFJZgEAAAAC lkYABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNaIAAaU/1MDuBF9FLQW6xgiGwAGvwMAAAAA AAAAAAAAAAAAAAAAAAZlDgAAAAAAAAAAAAAAAAAAAAAABsUCAAAAAAAAAAAAAAAAAAAAAAAGNwIA AAAAAAAAAAAAAAAAAAAAAAY3AgAAAAAAAAAAAAAAAAAAAAAABjcCAAAAAAAAAAAAAAAAAAAAAAp0 AADgARPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2 AQAAFTYBF/YDAAAY9gMAABrWGAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/xvWGAAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/xzWGAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/x3WGAAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2AwAAAAM/CQAARAkAAEYJAABICQAASgkAAPMA AAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAADJAEWJAFJZgEAAABh JAFnZOgaIgAMAAADJAEWJAFJZgEAAABhJAFnZBEhywAABEoJAABLCQAAUgkAAHAJAAA4AAAAAAAA AAAAAAAALwAAAAAAAAAAAAAAAC8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAJAAAWJAFJZgEAAABnZBEhywAAxgAAa2SiAwAAFiQBFyQBSWYBAAAAApZG AAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWiAAGlP9TA7gRfRS0FusYIhsABr8DAAAAAAAA AAAAAAAAAAAAAAAGZQ4AAAAAAAAAAAAAAAAAAAAAAAbFAgAAAAAAAAAAAAAAAAAAAAAABjcCAAAA AAAAAAAAAAAAAAAAAAAGNwIAAAAAAAAAAAAAAAAAAAAAAAY3AgAAAAAAAAAAAAAAAAAAAAAKdAAA 4AET1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEA ABU2ARf2AwAAGPYDAAAa1hgAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8b1hgAAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8c1hgAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8d1hgAAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gMAAAADcAkAAHUJAAB4CQAAewkAAH0JAADzAAAA AAAAAAAAAAAA5wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAyQBFiQBSWYBAAAAYSQB Z2ToGiIADAAAAyQBFiQBSWYBAAAAYSQBZ2QRIcsAAAR9CQAAfgkAAIUJAACSCQAAOAAAAAAAAAAA AAAAAC8AAAAAAAAAAAAAAAAvAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAACQAAFiQBSWYBAAAAZ2QRIcsAAMYAAGtkPQQAABYkARckAUlmAQAAAAKWRgAF 1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1ogABpT/UwO4EX0UtBbrGCIbAAa/AwAAAAAAAAAA AAAAAAAAAAAABmUOAAAAAAAAAAAAAAAAAAAAAAAGxQIAAAAAAAAAAAAAAAAAAAAAAAY3AgAAAAAA AAAAAAAAAAAAAAAABjcCAAAAAAAAAAAAAAAAAAAAAAAGNwIAAAAAAAAAAAAAAAAAAAAACnQAAOAB E9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAV NgEX9gMAABj2AwAAGtYYAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/G9YYAAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/HNYYAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/HdYYAAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDAAAAA5IJAACXCQAAmgkAAJ0JAACfCQAA8wAAAAAA AAAAAAAAAOcAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAMkARYkAUlmAQAAAGEkAWdk 6BoiAAwAAAMkARYkAUlmAQAAAGEkAWdkESHLAAAEnwkAAKAJAACnCQAAygkAADgAAAAAAAAAAAAA AAAvAAAAAAAAAAAAAAAALwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAkAABYkAUlmAQAAAGdkESHLAADGAABrZNgEAAAWJAEXJAFJZgEAAAAClkYABdYY BAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNaIAAaU/1MDuBF9FLQW6xgiGwAGvwMAAAAAAAAAAAAA AAAAAAAAAAZlDgAAAAAAAAAAAAAAAAAAAAAABsUCAAAAAAAAAAAAAAAAAAAAAAAGNwIAAAAAAAAA AAAAAAAAAAAAAAY3AgAAAAAAAAAAAAAAAAAAAAAABjcCAAAAAAAAAAAAAAAAAAAAAAp0AADgARPW MAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAFTYB F/YDAAAY9gMAABrWGAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/xvWGAAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/xzWGAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/x3WGAAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/zTWBgABBQMAADTWBgABCgNsAGH2AwAAAAPKCQAAzwkAANIJAADVCQAA1wkAAPMAAAAAAAAA AAAAAADnAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAADJAEWJAFJZgEAAABhJAFnZOga IgAMAAADJAEWJAFJZgEAAABhJAFnZBEhywAABNcJAADYCQAA7wkAAAYKAAAOCgAAHAoAADgAAAAA AAAAAAAAAAAzAAAAAAAAAAAAAAAAMwAAAAAAAAAAAAAAADMAAAAAAAAAAAAAAAAzAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAEAABnZBEhywAAxgAAa2RzBQAAFiQBFyQBSWYBAAAAApZGAAXWGAQB AAAEAQAABAEAAAQBAAAEAQAABAEAAAjWiAAGlP9TA7gRfRS0FusYIhsABr8DAAAAAAAAAAAAAAAA AAAAAAAGZQ4AAAAAAAAAAAAAAAAAAAAAAAbFAgAAAAAAAAAAAAAAAAAAAAAABjcCAAAAAAAAAAAA AAAAAAAAAAAGNwIAAAAAAAAAAAAAAAAAAAAAAAY3AgAAAAAAAAAAAAAAAAAAAAAKdAAA4AET1jAA AAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEAABU2ARf2 AwAAGPYDAAAa1hgAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8b1hgAAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8c1hgAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8d1hgAAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP801gYAAQUDAAA01gYAAQoDbABh9gMAAAAF5QkAAOYJAADuCQAA7wkAAPMJAAAFCgAABgoAAA4K AAAbCgAAHAoAACkKAAA8CgAAPQoAAFAKAABXCgAAWAoAAF8KAABgCgAAZAoAAGUKAABvCgAAcAoA AHEKAAByCgAAeQoAAIoKAACOCgAAqAoAAKkKAAC6CgAAvgoAANkKAADaCgAA7AoAAPEKAAALCwAA DAsAAB4LAAAjCwAAPgsAAD8LAABUCwAAWQsAAHILAABzCwAAiAsAAI0LAACnCwAAqAsAALoLAAC/ CwAA2AsAANkLAADrCwAA8AsAAPTo3OjQ6NDE3MTQtaaai5qLmovEmsSaxIuai5qLmouai5qLmoua i5qLmouai5qLmouai5qLmgAAAAAcFWgRIcsAFmiZVHMAQ0oUAGFKFABtSAkIc0gJCAAWFmiZVHMA Q0oUAGFKFABtSAkIc0gJCAAcFWgRIcsAFmgRIcsAQ0oUAGFKFABtSAkIc0gJCAAcFWgRIcsAFmiH OOAAQ0oUAGFKFABtSAkIc0gJCAAWFmj7FzoAQ0oUAGFKFABtSAkIc0gJCAAWFmiHOOAAQ0oUAGFK FABtSAkIc0gJCAAWFmgRIcsAQ0oUAGFKFABtSAkIc0gJCAAWFmhIek4AQ0oUAGFKFABtSAkIc0gJ CAAWFmhWd1wAQ0oUAGFKFABtSAkIc0gJCDYcCgAAKQoAAD0KAAA+CgAAUAoAAFgKAABgCgAAZQoA AHoKAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA 8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAABYkAUlmAQAAAGdk6BoiAAkAABYk AUlmAQAAAGdkESHLAAAEAABnZBEhywAACHoKAAB7CgAAgwoAAKIKAACoCgAAqgoAAF4AAAAAAAAA AAAAAABVAAAAAAAAAAAAAAAAVQAAAAAAAAAAAAAAAFUAAAAAAAAAAAAAAABJAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA DAAAAyQBFiQBSWYBAAAAYSQBZ2ToGiIACQAAFiQBSWYBAAAAZ2QRIcsAAKAAAGtkDgYAABYkARck AUlmAQAAAAKWRgAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1lwABJT/UwOZFV0YHiAABr8D AAAAAAAAAAAAAAAAAAAAAAAGRhIAAAAAAAAAAAAAAAAAAAAAAAbEAgAAAAAAAAAAAAAAAAAAAAAA BsEHAAAAAAAAAAAAAAAAAAAAAAp0AADgARPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8E AQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b 1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP80 1gYAAQUDAAA01gYAAQoDbABh9gMAAAAFqgoAAKsKAACzCgAA1AoAANkKAADbCgAAXgAAAAAAAAAA AAAAAFUAAAAAAAAAAAAAAABVAAAAAAAAAAAAAAAAVQAAAAAAAAAAAAAAAEkAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAM AAADJAEWJAFJZgEAAABhJAFnZOgaIgAJAAAWJAFJZgEAAABnZBEhywAAoAAAa2SZBgAAFiQBFyQB SWYBAAAAApZGAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWXAAElP9TA5kVXRgeIAAGvwMA AAAAAAAAAAAAAAAAAAAAAAZGEgAAAAAAAAAAAAAAAAAAAAAABsQCAAAAAAAAAAAAAAAAAAAAAAAG wQcAAAAAAAAAAAAAAAAAAAAACnQAAOABE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQB AAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvW EAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTW BgABBQMAADTWBgABCgNsAGH2AwAAAAXbCgAA3AoAAOQKAAAFCwAACwsAAA0LAABeAAAAAAAAAAAA AAAAVQAAAAAAAAAAAAAAAFUAAAAAAAAAAAAAAABVAAAAAAAAAAAAAAAASQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwA AAMkARYkAUlmAQAAAGEkAWdk6BoiAAkAABYkAUlmAQAAAGdkESHLAACgAABrZCQHAAAWJAEXJAFJ ZgEAAAAClkYABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNZcAASU/1MDmRVdGB4gAAa/AwAA AAAAAAAAAAAAAAAAAAAABkYSAAAAAAAAAAAAAAAAAAAAAAAGxAIAAAAAAAAAAAAAAAAAAAAAAAbB BwAAAAAAAAAAAAAAAAAAAAAKdAAA4AET1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEA AAAAAP8EAQAAAAAA/wQBAAAU9gEAABU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQ AAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYG AAEFAwAANNYGAAEKA2wAYfYDAAAABQ0LAAAOCwAAFgsAADkLAAA+CwAAQAsAAF4AAAAAAAAAAAAA AABVAAAAAAAAAAAAAAAAVQAAAAAAAAAAAAAAAFUAAAAAAAAAAAAAAABJAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAA AyQBFiQBSWYBAAAAYSQBZ2ToGiIACQAAFiQBSWYBAAAAZ2QRIcsAAKAAAGtkrwcAABYkARckAUlm AQAAAAKWRgAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1lwABJT/UwOZFV0YHiAABr8DAAAA AAAAAAAAAAAAAAAAAAAGRhIAAAAAAAAAAAAAAAAAAAAAAAbEAgAAAAAAAAAAAAAAAAAAAAAABsEH AAAAAAAAAAAAAAAAAAAAAAp0AADgARPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAA AAAA/wQBAAAAAAD/BAEAABT2AQAAFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAA AAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYA AQUDAAA01gYAAQoDbABh9gMAAAAFQAsAAEELAABJCwAAbQsAAHILAAB0CwAAXgAAAAAAAAAAAAAA AFUAAAAAAAAAAAAAAABVAAAAAAAAAAAAAAAAVQAAAAAAAAAAAAAAAEkAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAD JAEWJAFJZgEAAABhJAFnZOgaIgAJAAAWJAFJZgEAAABnZBEhywAAoAAAa2Q6CAAAFiQBFyQBSWYB AAAAApZGAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWXAAElP9TA5kVXRgeIAAGvwMAAAAA AAAAAAAAAAAAAAAAAAZGEgAAAAAAAAAAAAAAAAAAAAAABsQCAAAAAAAAAAAAAAAAAAAAAAAGwQcA AAAAAAAAAAAAAAAAAAAACnQAAOABE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAA AAD/BAEAAAAAAP8EAQAAFPYBAAAVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAA AP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgAB BQMAADTWBgABCgNsAGH2AwAAAAV0CwAAdQsAAH0LAACiCwAApwsAAKkLAABeAAAAAAAAAAAAAAAA VQAAAAAAAAAAAAAAAFUAAAAAAAAAAAAAAABVAAAAAAAAAAAAAAAASQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAMk ARYkAUlmAQAAAGEkAWdk6BoiAAkAABYkAUlmAQAAAGdkESHLAACgAABrZMUIAAAWJAEXJAFJZgEA AAAClkYABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNZcAASU/1MDmRVdGB4gAAa/AwAAAAAA AAAAAAAAAAAAAAAABkYSAAAAAAAAAAAAAAAAAAAAAAAGxAIAAAAAAAAAAAAAAAAAAAAAAAbBBwAA AAAAAAAAAAAAAAAAAAAKdAAA4AET1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAA AP8EAQAAAAAA/wQBAAAU9gEAABU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA /wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEF AwAANNYGAAEKA2wAYfYDAAAABakLAACqCwAAsgsAANMLAADYCwAA2gsAAF4AAAAAAAAAAAAAAABV AAAAAAAAAAAAAAAAVQAAAAAAAAAAAAAAAFUAAAAAAAAAAAAAAABJAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAyQB FiQBSWYBAAAAYSQBZ2ToGiIACQAAFiQBSWYBAAAAZ2QRIcsAAKAAAGtkUAkAABYkARckAUlmAQAA AAKWRgAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1lwABJT/UwOZFV0YHiAABr8DAAAAAAAA AAAAAAAAAAAAAAAGRhIAAAAAAAAAAAAAAAAAAAAAAAbEAgAAAAAAAAAAAAAAAAAAAAAABsEHAAAA AAAAAAAAAAAAAAAAAAp0AADgARPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA /wQBAAAAAAD/BAEAABT2AQAAFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/ AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUD AAA01gYAAQoDbABh9gMAAAAF2gsAANsLAADjCwAABQwAAAoMAAAMDAAAXgAAAAAAAAAAAAAAAFUA AAAAAAAAAAAAAABVAAAAAAAAAAAAAAAAVQAAAAAAAAAAAAAAAEkAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAADJAEW JAFJZgEAAABhJAFnZOgaIgAJAAAWJAFJZgEAAABnZBEhywAAoAAAa2TbCQAAFiQBFyQBSWYBAAAA ApZGAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWXAAElP9TA5kVXRgeIAAGvwMAAAAAAAAA AAAAAAAAAAAAAAZGEgAAAAAAAAAAAAAAAAAAAAAABsQCAAAAAAAAAAAAAAAAAAAAAAAGwQcAAAAA AAAAAAAAAAAAAAAACnQAAOABE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/ BAEAAAAAAP8EAQAAFPYBAAAVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8A AAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMA ADTWBgABCgNsAGH2AwAAAAXwCwAACgwAAAsMAAAdDAAAIgwAAEYMAABHDAAAWQwAAF4MAACCDAAA gwwAALcMAAC4DAAA6wwAAOwMAAAiDQAAIw0AAFgNAABZDQAAeA0AAH0NAACNDQAAuA0AALkNAAC7 DQAA1g0AANsNAADx5fHl8eXx5fHl8eXx5fHl8eXx2eXx5fHKvwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA FBVomVRzABZoESHLAG1ICQhzSAkIABwVaJlUcwAWaJlUcwBDShQAYUoUAG1ICQhzSAkIABYWaPsX OgBDShQAYUoUAG1ICQhzSAkIABYWaJlUcwBDShQAYUoUAG1ICQhzSAkIABwVaBEhywAWaJlUcwBD ShQAYUoUAG1ICQhzSAkIGgwMAAANDAAAFQwAAEAMAABGDAAASAwAAF4AAAAAAAAAAAAAAABVAAAA AAAAAAAAAAAAVQAAAAAAAAAAAAAAAFUAAAAAAAAAAAAAAABJAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAyQBFiQB SWYBAAAAYSQBZ2ToGiIACQAAFiQBSWYBAAAAZ2QRIcsAAKAAAGtkZgoAABYkARckAUlmAQAAAAKW RgAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1lwABJT/UwOZFV0YHiAABr8DAAAAAAAAAAAA AAAAAAAAAAAGRhIAAAAAAAAAAAAAAAAAAAAAAAbEAgAAAAAAAAAAAAAAAAAAAAAABsEHAAAAAAAA AAAAAAAAAAAAAAp0AADgARPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQB AAAAAAD/BAEAABT2AQAAFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA /wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA0 1gYAAQoDbABh9gMAAAAFSAwAAEkMAABRDAAAfQwAAIIMAACEDAAAXgAAAAAAAAAAAAAAAFUAAAAA AAAAAAAAAABVAAAAAAAAAAAAAAAAVQAAAAAAAAAAAAAAAEkAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAADJAEWJAFJ ZgEAAABhJAFnZOgaIgAJAAAWJAFJZgEAAABnZBEhywAAoAAAa2TxCgAAFiQBFyQBSWYBAAAAApZG AAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWXAAElP9TA5kVXRgeIAAGvwMAAAAAAAAAAAAA AAAAAAAAAAZGEgAAAAAAAAAAAAAAAAAAAAAABsQCAAAAAAAAAAAAAAAAAAAAAAAGwQcAAAAAAAAA AAAAAAAAAAAACnQAAOABE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEA AAAAAP8EAQAAFPYBAAAVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/ AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTW BgABCgNsAGH2AwAAAAWEDAAAhQwAAI0MAACyDAAAtwwAALkMAABeAAAAAAAAAAAAAAAAVQAAAAAA AAAAAAAAAFUAAAAAAAAAAAAAAABVAAAAAAAAAAAAAAAASQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAMkARYkAUlm AQAAAGEkAWdk6BoiAAkAABYkAUlmAQAAAGdkESHLAACgAABrZHwLAAAWJAEXJAFJZgEAAAAClkYA BdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNZcAASU/1MDmRVdGB4gAAa/AwAAAAAAAAAAAAAA AAAAAAAABkYSAAAAAAAAAAAAAAAAAAAAAAAGxAIAAAAAAAAAAAAAAAAAAAAAAAbBBwAAAAAAAAAA AAAAAAAAAAAKdAAA4AET1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAA AAAA/wQBAAAU9gEAABU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8A AAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYG AAEKA2wAYfYDAAAABbkMAAC6DAAAwgwAAOUMAADrDAAA7QwAAF4AAAAAAAAAAAAAAABVAAAAAAAA AAAAAAAAVQAAAAAAAAAAAAAAAFUAAAAAAAAAAAAAAABJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAyQBFiQBSWYB AAAAYSQBZ2ToGiIACQAAFiQBSWYBAAAAZ2QRIcsAAKAAAGtkBwwAABYkARckAUlmAQAAAAKWRgAF 1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1lwABJT/UwOZFV0YHiAABr8DAAAAAAAAAAAAAAAA AAAAAAAGRhIAAAAAAAAAAAAAAAAAAAAAAAbEAgAAAAAAAAAAAAAAAAAAAAAABsEHAAAAAAAAAAAA AAAAAAAAAAp0AADgARPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAA AAD/BAEAABT2AQAAFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAA AP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYA AQoDbABh9gMAAAAF7QwAAO4MAAD2DAAAHQ0AACINAAAkDQAAXgAAAAAAAAAAAAAAAFUAAAAAAAAA AAAAAABVAAAAAAAAAAAAAAAAVQAAAAAAAAAAAAAAAEkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAADJAEWJAFJZgEA AABhJAFnZOgaIgAJAAAWJAFJZgEAAABnZBEhywAAoAAAa2SSDAAAFiQBFyQBSWYBAAAAApZGAAXW GAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWXAAElP9TA5kVXRgeIAAGvwMAAAAAAAAAAAAAAAAA AAAAAAZGEgAAAAAAAAAAAAAAAAAAAAAABsQCAAAAAAAAAAAAAAAAAAAAAAAGwQcAAAAAAAAAAAAA AAAAAAAACnQAAOABE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAA AP8EAQAAFPYBAAAVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA /wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgAB CgNsAGH2AwAAAAUkDQAAJQ0AAC0NAABTDQAAWA0AAFoNAABeAAAAAAAAAAAAAAAAVQAAAAAAAAAA AAAAAFUAAAAAAAAAAAAAAABVAAAAAAAAAAAAAAAASQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAMkARYkAUlmAQAA AGEkAWdk6BoiAAkAABYkAUlmAQAAAGdkESHLAACgAABrZB0NAAAWJAEXJAFJZgEAAAAClkYABdYY BAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNZcAASU/1MDmRVdGB4gAAa/AwAAAAAAAAAAAAAAAAAA AAAABkYSAAAAAAAAAAAAAAAAAAAAAAAGxAIAAAAAAAAAAAAAAAAAAAAAAAbBBwAAAAAAAAAAAAAA AAAAAAAKdAAA4AET1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA /wQBAAAU9gEAABU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/ AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEK A2wAYfYDAAAABVoNAABbDQAAYw0AAHMNAAB4DQAAjg0AAF4AAAAAAAAAAAAAAABVAAAAAAAAAAAA AAAAVQAAAAAAAAAAAAAAAFUAAAAAAAAAAAAAAABIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0AAA3GBQABHgWAFiQBSWYB AAAAZ2SZVHMACQAAFiQBSWYBAAAAZ2QRIcsAAKAAAGtkqA0AABYkARckAUlmAQAAAAKWRgAF1hgE AQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1lwABJT/UwOZFV0YHiAABr8DAAAAAAAAAAAAAAAAAAAA AAAGRhIAAAAAAAAAAAAAAAAAAAAAAAbEAgAAAAAAAAAAAAAAAAAAAAAABsEHAAAAAAAAAAAAAAAA AAAAAAp0AADgARPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/ BAEAABT2AQAAFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8A AAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoD bABh9gMAAAAFjg0AAI8NAACXDQAAsg0AALgNAAC6DQAAXgAAAAAAAAAAAAAAAFUAAAAAAAAAAAAA AABVAAAAAAAAAAAAAAAAVQAAAAAAAAAAAAAAAEkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAADJAEWJAFJZgEAAABh JAFnZOgaIgAJAAAWJAFJZgEAAABnZBEhywAAoAAAa2QzDgAAFiQBFyQBSWYBAAAAApZGAAXWGAQB AAAEAQAABAEAAAQBAAAEAQAABAEAAAjWXAAElP9TA5kVXRgeIAAGvwMAAAAAAAAAAAAAAAAAAAAA AAZGEgAAAAAAAAAAAAAAAAAAAAAABsQCAAAAAAAAAAAAAAAAAAAAAAAGwQcAAAAAAAAAAAAAAAAA AAAACnQAAOABE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8E AQAAFPYBAAAVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAA AP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgABCgNs AGH2AwAAAAW6DQAAuw0AAMMNAADNDQAA0w0AANUNAABeAAAAAAAAAAAAAAAAVQAAAAAAAAAAAAAA AFUAAAAAAAAAAAAAAABVAAAAAAAAAAAAAAAASQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAMkARYkAUlmAQAAAGEk AWdk6BoiAAkAABYkAUlmAQAAAGdkESHLAACgAABrZL4OAAAWJAEXJAFJZgEAAAAClkYABdYYBAEA AAQBAAAEAQAABAEAAAQBAAAEAQAACNZcAASU/1MDmRVdGB4gAAa/AwAAAAAAAAAAAAAAAAAAAAAA BkYSAAAAAAAAAAAAAAAAAAAAAAAGxAIAAAAAAAAAAAAAAAAAAAAAAAbBBwAAAAAAAAAAAAAAAAAA AAAKdAAA4AET1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQB AAAU9gEAABU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA /xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wA YfYDAAAABdUNAADWDQAA1w0AANgNAADZDQAA2g0AANsNAABeAAAAAAAAAAAAAAAAWQAAAAAAAAAA AAAAAFcAAAAAAAAAAAAAAABXAAAAAAAAAAAAAAAAVwAAAAAAAAAAAAAAAFcAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAABAAAABAAAZ2QRIcsAAKAAAGtkSQ8AABYkARckAUlmAQAAAAKWRgAF1hgEAQAA BAEAAAQBAAAEAQAABAEAAAQBAAAI1lwABJT/UwOZFV0YHiAABr8DAAAAAAAAAAAAAAAAAAAAAAAG RhIAAAAAAAAAAAAAAAAAAAAAAAbEAgAAAAAAAAAAAAAAAAAAAAAABsEHAAAAAAAAAAAAAAAAAAAA AAp0AADgARPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEA ABT2AQAAFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/ HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh 9gMAAAAGNQAxkGgBHTACOnARIcsAH7DGQSCwgi4hsG4EIrCKBSOQigUkkIoFJbAAABewxQIYsMUC DJDEAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAACZABYkARckAUlmAQAAAAGW2v8hdgAGaAE11gUAAQO/AzXWBQECA2UONdYFAgMDxQI11gUD BAM3AjXWBQQFAzcCNdYFBQYDNwIjdgABvwMjdgECZQ4jdgIDxQIjdgMGNwI6Vg8AApZGAAp0AADg ART2AQAAFTYBGPYDAAA11gUAAQO/AzXWBQECA2UONdYFAgMDxQI11gUDBgM3ApkAFiQBFyQBSWYB AAAAAZba/yF2AAZoATXWBQABA78DNdYFAQIDZQ411gUCAwPFAjXWBQMEAzcCNdYFBAUDNwI11gUF BgM3AiN2AAG/AyN2AQJlDiN2AgPFAiN2AwY3AjpWDwAClkYACnQAAOABFPYBAAAVNgEY9gMAADXW BQABA78DNdYFAQIDZQ411gUCAwPFAjXWBQMGAzcCmQAWJAEXJAFJZgEAAAABltr/IXYABmgBNdYF AAEDvwM11gUBAgNlDjXWBQIDA8UCNdYFAwQDNwI11gUEBQM3AjXWBQUGAzcCI3YAAb8DI3YBAmUO I3YCA8UCI3YDBjcCOlYPAAKWRgAKdAAA4AEU9gEAABU2ARj2AwAANdYFAAEDvwM11gUBAgNlDjXW BQIDA8UCNdYFAwYDNwKZABYkARckAUlmAQAAAAGW2v8hdgAGaAE11gUAAQO/AzXWBQECA2UONdYF AgMDxQI11gUDBAM3AjXWBQQFAzcCNdYFBQYDNwIjdgABvwMjdgECZQ4jdgIDxQIjdgMGNwI6Vg8A ApZGAAp0AADgART2AQAAFTYBGPYDAAA11gUAAQO/AzXWBQECA2UONdYFAgMDxQI11gUDBgM3ApkA FiQBFyQBSWYBAAAAAZba/yF2AAZoATXWBQABA78DNdYFAQIDZQ411gUCAwPFAjXWBQMEAzcCNdYF BAUDNwI11gUFBgM3AiN2AAG/AyN2AQJlDiN2AgPFAiN2AwY3AjpWDwAClkYACnQAAOABFPYBAAAV NgEY9gMAADXWBQABA78DNdYFAQIDZQ411gUCAwPFAjXWBQMGAzcCmQAWJAEXJAFJZgEAAAABltr/ IXYABmgBNdYFAAEDvwM11gUBAgNlDjXWBQIDA8UCNdYFAwQDNwI11gUEBQM3AjXWBQUGAzcCI3YA Ab8DI3YBAmUOI3YCA8UCI3YDBjcCOlYPAAKWRgAKdAAA4AEU9gEAABU2ARj2AwAANdYFAAEDvwM1 1gUBAgNlDjXWBQIDA8UCNdYFAwYDNwKZABYkARckAUlmAQAAAAGW2v8hdgAGaAE11gUAAQO/AzXW BQECA2UONdYFAgMDxQI11gUDBAM3AjXWBQQFAzcCNdYFBQYDNwIjdgABvwMjdgECZQ4jdgIDxQIj dgMGNwI6Vg8AApZGAAp0AADgART2AQAAFTYBGPYDAAA11gUAAQO/AzXWBQECA2UONdYFAgMDxQI1 1gUDBgM3ApkAFiQBFyQBSWYBAAAAAZba/yF2AAZoATXWBQABA78DNdYFAQIDZQ411gUCAwPFAjXW BQMEAzcCNdYFBAUDNwI11gUFBgM3AiN2AAG/AyN2AQJlDiN2AgPFAiN2AwY3AjpWDwAClkYACnQA AOABFPYBAAAVNgEY9gMAADXWBQABA78DNdYFAQIDZQ411gUCAwPFAjXWBQMGAzcCmQAWJAEXJAFJ ZgEAAAABltr/IXYABmgBNdYFAAEDvwM11gUBAgNlDjXWBQIDA8UCNdYFAwQDNwI11gUEBQM3AjXW BQUGAzcCI3YAAb8DI3YBAmUOI3YCA8UCI3YDBjcCOlYPAAKWRgAKdAAA4AEU9gEAABU2ARj2AwAA NdYFAAEDvwM11gUBAgNlDjXWBQIDA8UCNdYFAwYDNwKZABYkARckAUlmAQAAAAGW2v8hdgAGaAE1 1gUAAQO/AzXWBQECA2UONdYFAgMDxQI11gUDBAM3AjXWBQQFAzcCNdYFBQYDNwIjdgABvwMjdgEC ZQ4jdgIDxQIjdgMGNwI6Vg8AApZGAAp0AADgART2AQAAFTYBGPYDAAA11gUAAQO/AzXWBQECA2UO NdYFAgMDxQI11gUDBgM3AokAFiQBFyQBSWYBAAAAAZba/yF2AARoATXWBQABA78DNdYFAQIDRhI1 1gUCAwPEAjXWBQMEA8EHI3YAAb8DI3YBAkYSI3YCA8QCI3YDBMEHOlYPAAKWRgAKdAAA4AEU9gEA ABU2ARj2AwAANdYFAAEDvwM11gUBAgNGEjXWBQIDA8QCNdYFAwQDwQeJABYkARckAUlmAQAAAAGW 2v8hdgAEaAE11gUAAQO/AzXWBQECA0YSNdYFAgMDxAI11gUDBAPBByN2AAG/AyN2AQJGEiN2AgPE AiN2AwTBBzpWDwAClkYACnQAAOABFPYBAAAVNgEY9gMAADXWBQABA78DNdYFAQIDRhI11gUCAwPE AjXWBQMEA8EHiQAWJAEXJAFJZgEAAAABltr/IXYABGgBNdYFAAEDvwM11gUBAgNGEjXWBQIDA8QC NdYFAwQDwQcjdgABvwMjdgECRhIjdgIDxAIjdgMEwQc6Vg8AApZGAAp0AADgART2AQAAFTYBGPYD AAA11gUAAQO/AzXWBQECA0YSNdYFAgMDxAI11gUDBAPBB4kAFiQBFyQBSWYBAAAAAZba/yF2AARo ATXWBQABA78DNdYFAQIDRhI11gUCAwPEAjXWBQMEA8EHI3YAAb8DI3YBAkYSI3YCA8QCI3YDBMEH OlYPAAKWRgAKdAAA4AEU9gEAABU2ARj2AwAANdYFAAEDvwM11gUBAgNGEjXWBQIDA8QCNdYFAwQD wQeJABYkARckAUlmAQAAAAGW2v8hdgAEaAE11gUAAQO/AzXWBQECA0YSNdYFAgMDxAI11gUDBAPB ByN2AAG/AyN2AQJGEiN2AgPEAiN2AwTBBzpWDwAClkYACnQAAOABFPYBAAAVNgEY9gMAADXWBQAB A78DNdYFAQIDRhI11gUCAwPEAjXWBQMEA8EHiQAWJAEXJAFJZgEAAAABltr/IXYABGgBNdYFAAED vwM11gUBAgNGEjXWBQIDA8QCNdYFAwQDwQcjdgABvwMjdgECRhIjdgIDxAIjdgMEwQc6Vg8AApZG AAp0AADgART2AQAAFTYBGPYDAAA11gUAAQO/AzXWBQECA0YSNdYFAgMDxAI11gUDBAPBB4kAFiQB FyQBSWYBAAAAAZba/yF2AARoATXWBQABA78DNdYFAQIDRhI11gUCAwPEAjXWBQMEA8EHI3YAAb8D I3YBAkYSI3YCA8QCI3YDBMEHOlYPAAKWRgAKdAAA4AEU9gEAABU2ARj2AwAANdYFAAEDvwM11gUB AgNGEjXWBQIDA8QCNdYFAwQDwQeJABYkARckAUlmAQAAAAGW2v8hdgAEaAE11gUAAQO/AzXWBQEC A0YSNdYFAgMDxAI11gUDBAPBByN2AAG/AyN2AQJGEiN2AgPEAiN2AwTBBzpWDwAClkYACnQAAOAB FPYBAAAVNgEY9gMAADXWBQABA78DNdYFAQIDRhI11gUCAwPEAjXWBQMEA8EHiQAWJAEXJAFJZgEA AAABltr/IXYABGgBNdYFAAEDvwM11gUBAgNGEjXWBQIDA8QCNdYFAwQDwQcjdgABvwMjdgECRhIj dgIDxAIjdgMEwQc6Vg8AApZGAAp0AADgART2AQAAFTYBGPYDAAA11gUAAQO/AzXWBQECA0YSNdYF AgMDxAI11gUDBAPBB4kAFiQBFyQBSWYBAAAAAZba/yF2AARoATXWBQABA78DNdYFAQIDRhI11gUC AwPEAjXWBQMEA8EHI3YAAb8DI3YBAkYSI3YCA8QCI3YDBMEHOlYPAAKWRgAKdAAA4AEU9gEAABU2 ARj2AwAANdYFAAEDvwM11gUBAgNGEjXWBQIDA8QCNdYFAwQDwQeJABYkARckAUlmAQAAAAGW2v8h dgAEaAE11gUAAQO/AzXWBQECA0YSNdYFAgMDxAI11gUDBAPBByN2AAG/AyN2AQJGEiN2AgPEAiN2 AwTBBzpWDwAClkYACnQAAOABFPYBAAAVNgEY9gMAADXWBQABA78DNdYFAQIDRhI11gUCAwPEAjXW BQMEA8EHiQAWJAEXJAFJZgEAAAABltr/IXYABGgBNdYFAAEDvwM11gUBAgNGEjXWBQIDA8QCNdYF AwQDwQcjdgABvwMjdgECRhIjdgIDxAIjdgMEwQc6Vg8AApZGAAp0AADgART2AQAAFTYBGPYDAAA1 1gUAAQO/AzXWBQECA0YSNdYFAgMDxAI11gUDBAPBB4kAFiQBFyQBSWYBAAAAAZba/yF2AARoATXW BQABA78DNdYFAQIDRhI11gUCAwPEAjXWBQMEA8EHI3YAAb8DI3YBAkYSI3YCA8QCI3YDBMEHOlYP AAKWRgAKdAAA4AEU9gEAABU2ARj2AwAANdYFAAEDvwM11gUBAgNGEjXWBQIDA8QCNdYFAwQDwQeJ ABYkARckAUlmAQAAAAGW2v8hdgAEaAE11gUAAQO/AzXWBQECA0YSNdYFAgMDxAI11gUDBAPBByN2 AAG/AyN2AQJGEiN2AgPEAiN2AwTBBzpWDwAClkYACnQAAOABFPYBAAAVNgEY9gMAADXWBQABA78D NdYFAQIDRhI11gUCAwPEAjXWBQMEA8EHiQAWJAEXJAFJZgEAAAABltr/IXYABGgBNdYFAAEDvwM1 1gUBAgNGEjXWBQIDA8QCNdYFAwQDwQcjdgABvwMjdgECRhIjdgIDxAIjdgMEwQc6Vg8AApZGAAp0 AADgART2AQAAFTYBGPYDAAA11gUAAQO/AzXWBQECA0YSNdYFAgMDxAI11gUDBAPBB4kAFiQBFyQB SWYBAAAAAZba/yF2AARoATXWBQABA78DNdYFAQIDRhI11gUCAwPEAjXWBQMEA8EHI3YAAb8DI3YB AkYSI3YCA8QCI3YDBMEHOlYPAAKWRgAKdAAA4AEU9gEAABU2ARj2AwAANdYFAAEDvwM11gUBAgNG EjXWBQIDA8QCNdYFAwQDwQeJABYkARckAUlmAQAAAAGW2v8hdgAEaAE11gUAAQO/AzXWBQECA0YS NdYFAgMDxAI11gUDBAPBByN2AAG/AyN2AQJGEiN2AgPEAiN2AwTBBzpWDwAClkYACnQAAOABFPYB AAAVNgEY9gMAADXWBQABA78DNdYFAQIDRhI11gUCAwPEAjXWBQMEA8EHiQAWJAEXJAFJZgEAAAAB ltr/IXYABGgBNdYFAAEDvwM11gUBAgNGEjXWBQIDA8QCNdYFAwQDwQcjdgABvwMjdgECRhIjdgID xAIjdgMEwQc6Vg8AApZGAAp0AADgART2AQAAFTYBGPYDAAA11gUAAQO/AzXWBQECA0YSNdYFAgMD xAI11gUDBAPBBwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAQ ABIAAQCcAA8AAwAAAAAAAAAAAEQAAEDx/wIARAAMAAAAAAAAAAAACABTAHQAYQBuAGQAYQByAGQA AAACAAAAGABDShgAX0gBBGFKGABtSAcEc0gHBHRIBwQAAAAAAAAAAAAAAAAAAAAAAABKAEEA8v+h AEoADAEAAAAAAAAAABkAQQBiAHMAYQB0AHoALQBTAHQAYQBuAGQAYQByAGQAcwBjAGgAcgBpAGYA dABhAHIAdAAAAAAAWABpQPP/swBYAAwBAAAAAAAAAAAPAE4AbwByAG0AYQBsAGUAIABUAGEAYgBl AGwAbABlAAAAHAAX9gMAADTWBgABCgNsADTWBgABBQMAAGH2AwAAAgALAAAAMABrAPT/wQAwAAAB AAAAAAAAAAALAEsAZQBpAG4AZQAgAEwAaQBzAHQAZQAAAAIAAAAAAAAAegCaQLMA8wB6AAwAAAAR IcsAAAASAFQAYQBiAGUAbABsAGUAbgBnAGkAdAB0AGUAcgBuAGUAdAB6AAAANwA6Vg8AE9YwAAAA /wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAIADwAAAAAAAADb BQAABQAAZAAABAD/////AAAAAAEAAAAPAAAAFwAAACAAAAAlAAAAJwAAACkAAAArAAAALAAAADQA AABMAAAAUQAAAFMAAABVAAAAVwAAAFgAAABgAAAAdwAAAHwAAAB+AAAAgQAAAIQAAACFAAAAjQAA ALEAAAC2AAAAuAAAALoAAAC8AAAAvQAAAMUAAADaAAAA3wAAAOEAAADkAAAA5wAAAOgAAADuAAAA BAEAAAkBAAAMAQAADgEAABEBAAASAQAAGgEAAD8BAABEAQAARgEAAEgBAABKAQAASwEAAFIBAABw AQAAdQEAAHgBAAB7AQAAfQEAAH4BAACFAQAAkgEAAJcBAACaAQAAnQEAAJ8BAACgAQAApwEAAMoB AADPAQAA0gEAANUBAADXAQAA2AEAAO8BAAAGAgAADgIAABwCAAApAgAAPQIAAD4CAABQAgAAWAIA AGACAABlAgAAegIAAHsCAACDAgAAogIAAKgCAACqAgAAqwIAALMCAADUAgAA2QIAANsCAADcAgAA 5AIAAAUDAAALAwAADQMAAA4DAAAWAwAAOQMAAD4DAABAAwAAQQMAAEkDAABtAwAAcgMAAHQDAAB1 AwAAfQMAAKIDAACnAwAAqQMAAKoDAACyAwAA0wMAANgDAADaAwAA2wMAAOMDAAAFBAAACgQAAAwE AAANBAAAFQQAAEAEAABGBAAASAQAAEkEAABRBAAAfQQAAIIEAACEBAAAhQQAAI0EAACyBAAAtwQA ALkEAAC6BAAAwgQAAOUEAADrBAAA7QQAAO4EAAD2BAAAHQUAACIFAAAkBQAAJQUAAC0FAABTBQAA WAUAAFoFAABbBQAAYwUAAHMFAAB4BQAAjgUAAI8FAACXBQAAsgUAALgFAAC6BQAAuwUAAMMFAADN BQAA0wUAANUFAADWBQAA1wUAANgFAADZBQAA2gUAAN0FAACYAAAAADAAAAAAAAAAgAAAAIAAAAAw AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAYAAAAAAAAKkAAAAAMAAAAAAAAACAAAAAgAEAAFAA AAAAIACpAAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAUAAA AAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAABQAAAA ACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAAFQAAAAA IACpAAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAg AKkAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAA qQAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACZ AAAAADAAAAAAAAAAgAAAAIABAABUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKkA AAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAqQAA AAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACpAAAA ADAAAAAAAAAAgAAAAIABAABQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAAVAAAAAAgAKlAAAAA MAAAAAAAAACAAAAAgAEAAFAAAAAAIACpQAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAqUAAAAAw AAAAAAAAAIAAAACAAQAAUAAAAAAgAKlAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACpQAAAADAA AAAAAAAAgAAAAIABAABQAAAAACAAqUAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAJlAAAAAMAAA AAAAAACAAAAAgAEAAFQAAAAAIACpQAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAqUAAAAAwAAAA AAAAAIAAAACAAQAAUAAAAAAgAKlAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACpQAAAADAAAAAA AAAAgAAAAIABAABQAAAAACAAqUAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAalAAAAAMAAAAAAA AACAAAAAgAEAAFAAAAAAIAGZQAAAADAAAAAAAAAAgAAAAIABAABUAAAAACAAqUAAAAAwAAAAAAAA AIAAAACAAQAAUAAAAAAgAKlAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACpQAAAADAAAAAAAAAA gAAAAIABAABQAAAAACAAqUAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAalAAAAAMAAAAAAAAACA AAAAgAEAAFAAAAAAIAGpQAAAADAAAAAAAAAAgAAAAIABAABQAAAAACABmUAAAAAwAAAAAAAAAIAA AACAAQAAVAAAAAAgAKlAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACpQAAAADAAAAAAAAAAgAAA AIABAABQAAAAACAAqUAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKlAAAAAMAAAAAAAAACAAAAA gAEAAFAAAAAAIACpQAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAqUAAAAAwAAAAAAAAAIAAAACA AQAAUAAAAAAgAJlAAAAAMAAAAAAAAACAAAAAgAEAAFQAAAAAIACpQAAAADAAAAAAAAAAgAAAAIAB AABQAAAAACAAqUAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKlAAAAAMAAAAAAAAACAAAAAgAEA AFAAAAAAIACpQAAAADAAAAAAAAAAgAAAAIABAABQAAAAACABqUAAAAAwAAAAAAAAAIAAAACAAQAA UAAAAAAgAalAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACZQAAAADAAAAAAAAAAgAAAAIABAABU AAAAACAAqUAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKlAAAAAMAAAAAAAAACAAAAAgAEAAFAA AAAAIACpQAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAqUAAAAAwAAAAAAAAAIAAAACAAQAAUAAA AAAgAalAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIAGpQAAAADAAAAAAAAAAgAAAAIABAABQAAAA ACAAmUAAAAAwAAAAAAAAAIAAAACAAQAAVAAAAAAgAKlAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAA IACpQAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAqUAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAg AKlAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIAGpQAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAB qUAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAJlAAAAAMAAAAAAAAACAAAAAgAEAAFQAAAAAIACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAiAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAACAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAA AAAwAAAAAAAAAIAAAACAAAAAIAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAA ADAAAAAAAAAAgAAAAIAAAACIAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAKkAAAAA MAAAAAAAAACAAAAAgAEAAFAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAqQAAAAAw AAAAAAAAAIAAAACAAQAAUAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIAGZAAAAADAA AAAAAAAAgAAAAIABAABUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKkAAAAAMAAA AAAAAACAAAAAgAEAAFAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAqQAAAAAwAAAA AAAAAIAAAACAAQAAUAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAAFQAAAAAIACpAAAAADAAAAAA AAAAgAAAAIABAABQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKkAAAAAMAAAAAAA AACAAAAAgAEAAFAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAmQAAAAAwAAAAAAAA AIAAAACAAQAAVAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACpAAAAADAAAAAAAAAA gAAAAIABAABQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKkAAAAAMAAAAAAAAACA AAAAgAEAAFAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAABUAAAAACAAqQAAAAAwAAAAAAAAAIAA AACAAQAAUAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACpAAAAADAAAAAAAAAAgAAA AIABAABQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAJkAAAAAMAAAAAAAAACAAAAA gAEAAFQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACA AQAAUAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIAB AABQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAAVAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEA AFAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA UAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAABU AAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAFAA AAAAIACpAAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAUAAA AAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAAFQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAABQAAAA ACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAA IACpAAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAAVAAAAAAg AKkAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAA qQAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACZ AAAAADAAAAAAAAAAgAAAAIABAABUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKkA AAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAqQAA AAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAAFQAAAAAIACpAAAA ADAAAAAAAAAAgAAAAIABAABQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKkAAAAA MAAAAAAAAACAAAAAgAEAAFAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAmQAAAAAw AAAAAAAAAIAAAACAAQAAVAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACpAAAAADAA AAAAAAAAgAAAAIABAABQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKkAAAAAMAAA AAAAAACAAAAAgAEAAFAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAABUAAAAACAAqQAAAAAwAAAA AAAAAIAAAACAAQAAUAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACpAAAAADAAAAAA AAAAgAAAAIABAABQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAJkAAAAAMAAAAAAA AACAAAAAgAEAAFQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAqQAAAAAwAAAAAAAA AIAAAACAAQAAUAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACpAAAAADAAAAAAAAAA gAAAAIABAABQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAAVAAAAAAgAKkAAAAAMAAAAAAAAACA AAAAgAEAAFAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAqQAAAAAwAAAAAAAAAIAA AACAAQAAUAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIAGZAAAAADAAAAAAAAAAgAAA AIABAABUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKkAAAAAMAAAAAAAAACAAAAA gAEAAFAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACA AQAAUAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAAFQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIAB AABQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEA AFAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA VAAAAAAgAJgAAAAAMAAAAAAAAACAAAAAgAAAAPgAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAAAAAAAEAAAAPAAAAFwAAACAAAAAlAAAA JwAAACkAAAArAAAALAAAADQAAABMAAAAUQAAAFMAAABVAAAAVwAAAFgAAABgAAAAdwAAAHwAAAB+ AAAAgQAAAIQAAACFAAAAjQAAALEAAAC2AAAAuAAAALoAAAC8AAAAvQAAAMUAAADaAAAA3wAAAOEA AADkAAAA5wAAAOgAAADuAAAABAEAAAkBAAAMAQAADgEAABEBAAASAQAAGgEAAD8BAABEAQAARgEA AEgBAABKAQAASwEAAFIBAABwAQAAdQEAAHgBAAB7AQAAfQEAAH4BAACFAQAAkgEAAJcBAACaAQAA nQEAAJ8BAACgAQAApwEAAMoBAADPAQAA0gEAANUBAADXAQAA2AEAAO8BAAAGAgAADgIAAD0CAAA+ AgAAUAIAAFgCAABgAgAAZQIAAHoCAACDAgAAogIAAKgCAACqAgAAswIAANQCAADZAgAA2wIAAOQC AAAFAwAACwMAAA0DAAAWAwAAOQMAAD4DAABAAwAASQMAAG0DAAByAwAAdAMAAH0DAACiAwAApwMA AKkDAACyAwAA0wMAANgDAADaAwAA4wMAAAUEAAAKBAAADAQAABUEAABABAAARgQAAEgEAABRBAAA fQQAAIIEAACEBAAAjQQAALIEAAC3BAAAuQQAAMIEAADlBAAA6wQAAO0EAAD2BAAAHQUAACIFAAAk BQAALQUAAFMFAABYBQAAWgUAAGMFAABzBQAAeAUAAI4FAACXBQAAsgUAALgFAAC6BQAAwwUAAM0F AADTBQAA1QUAANcFAADYBQAA2QUAANoFAADdBQAAmgAAAAAwAAAAAAAAAIAAAACAAAAAIAAAAACA B5gAAAAAMAAAAAAAAACAAAAAgAAAACAAAAAAgACpAAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAA qQAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACp AAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKkA AAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAABUAAAAACAAqQAA AAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACpAAAA ADAAAAAAAAAAgAAAAIABAABQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKkAAAAA MAAAAAAAAACAAAAAgAEAAFAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAmQAAAAAw AAAAAAAAAIAAAACAAQAAVAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACpAAAAADAA AAAAAAAAgAAAAIABAABQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKkAAAAAMAAA AAAAAACAAAAAgAEAAFAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAqQAAAAAwAAAA AAAAAIAAAACAAQAAUAAAAAAgAZkAAAAAMAAAAAAAAACAAAAAgAEAAFQAAAAAIACpAAAAADAAAAAA AAAAgAAAAIABAABQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKkAAAAAMAAAAAAA AACAAAAAgAEAAFAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAqQAAAAAwAAAAAAAA AIAAAACAAQAAUAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACZAAAAADAAAAAAAAAA gAAAAIABAABUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKkAAAAAMAAAAAAAAACA AAAAgAEAAFAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAqQAAAAAwAAAAAAAAAIAA AACAAQAAUAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIAGpAAAAADAAAAAAAAAAgAAA AIABAABQAAAAACABmQAAAAAwAAAAAAAAAIAAAACAAQAAVAAAAAAgAKkAAAAAMAAAAAAAAACAAAAA gAEAAFAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACA AQAAUAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIAGrAAAAADAAAAAAAAAAgAAAAIAB AABQAAAAACAHqQAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAZkAAAAAMAAAAAAAAACAAAAAgAEA AFQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA UAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAABQ AAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAFAA AAAAIACZAAAAADAAAAAAAAAAgAAAAIABAABUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAUAAA AAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAABQAAAA ACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAakAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAA IAGpAAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAAVAAAAAAg AKkAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAA qQAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIAGp AAAAADAAAAAAAAAAgAAAAIABAABQAAAAACABqQAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAJkA AAAAMAAAAAAAAACAAAAAgAEAAFQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAqQAA AAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACpAAAA ADAAAAAAAAAAgAAAAIABAABQAAAAACABqQAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAakAAAAA MAAAAAAAAACAAAAAgAEAAFAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAABUAAAAACAAmgAAAAAw AAAAAAAAAIAAAACAAAAAiAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAANAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAACIAAAAAAAAmgAAAAAwAAAAAAAAAIAAAACAAAAA6AAAAAAAB5gAAAAAMAAA AAAAAACAAAAAgAAAAIgAAAAAAACaAAAAADAAAAAAAAAAgAAAAIAAAACIAAAAAAAHq0AAAAAwAAAA AAAAAIAAAACAAQAAUAAAAAAgAKlAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACpQAAAADAAAAAA AAAAgAAAAIABAABQAAAAACAAq0AAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgB6NAAAAAMAAAAAAA AACAAAAAgAEAAFAAAAAAIAChQAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAoUAAAAAwAAAAAAAA AIAAAACAAQAAUAAAAAAgAKFAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACjQAAAADAAAAAAAAAA gAAAAIABAABQAAAAACAAoUAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKFAAAAAMAAAAAAAAACA AAAAgAEAAFAAAAAAIAChQAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAo0AAAAAwAAAAAAAAAIAA AACAAQAAUAAAAAAgAKFAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIAChQAAAADAAAAAAAAAAgAAA AIABAABQAAAAACAAoUAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKNAAAAAMAAAAAAAAACAAAAA gAEAAFAAAAAAIAChQAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAoUAAAAAwAAAAAAAAAIAAAACA AQAAUAAAAAAgAKFAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACjQAAAADAAAAAAAAAAgAAAAIAB AABQAAAAACAAoUAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKFAAAAAMAAAAAAAAACAAAAAgAEA AFAAAAAAIAChQAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAo0AAAAAwAAAAAAAAAIAAAACAAQAA UAAAAAAgAKFAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIAChQAAAADAAAAAAAAAAgAAAAIABAABQ AAAAACAAoUAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKNAAAAAMAAAAAAAAACAAAAAgAEAAFAA AAAAIAChQAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAoUAAAAAwAAAAAAAAAIAAAACAAQAAUAAA AAAgAKFAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACjQAAAADAAAAAAAAAAgAAAAIABAABQAAAA ACAAoUAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKFAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAA IAChQAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAo0AAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAg AKFAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIAChQAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAA oUAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKNAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACh QAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAoUAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKFA AAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIACjQAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAoUAA AAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKFAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIAChQAAA ADAAAAAAAAAAgAAAAIABAABQAAAAACAAo0AAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKFAAAAA MAAAAAAAAACAAAAAgAEAAFAAAAAAIAChQAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAoUAAAAAw AAAAAAAAAIAAAACAAQAAUAAAAAAgAKNAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIAChQAAAADAA AAAAAAAAgAAAAIABAABQAAAAACAAoUAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKFAAAAAMAAA AAAAAACAAAAAgAEAAFAAAAAAIACjQAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAoUAAAAAwAAAA AAAAAIAAAACAAQAAUAAAAAAgAKFAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIAChQAAAADAAAAAA AAAAgAAAAIABAABQAAAAACAAo0AAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKFAAAAAMAAAAAAA AACAAAAAgAEAAFAAAAAAIAChQAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAo0AAAAAwAAAAAAAA AIAAAACAAQAAUAAAAAAgB6NAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIAChQAAAADAAAAAAAAAA gAAAAIABAABQAAAAACAAoUAAAAAwAAAAAAAAAIAAAACAAQAAUAAAAAAgAKFAAAAAMAAAAAAAAACA AAAAgAEAAFAAAAAAIAGjQAAAADAAAAAAAAAAgAAAAIABAABQAAAAACAAoUAAAAAwAAAAAAAAAIAA AACAAQAAUAAAAAAgAKFAAAAAMAAAAAAAAACAAAAAgAEAAFAAAAAAIAChQAAAADAAAAAAAAAAgAAA AIABAABQAAAAACAAkgAAAAAwAAAAAAAAAIAAAACAAAAA+AAAAACAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAAABgAA5QkAAPALAADbDQAABwAA AB0AAAAnAAAAAAYAACsIAABMCAAAVwgAAHcIAACECAAAsQgAALwIAADaCAAA5wgAAAQJAAARCQAA PwkAAEoJAABwCQAAfQkAAJIJAACfCQAAygkAANcJAAAcCgAAegoAAKoKAADbCgAADQsAAEALAAB0 CwAAqQsAANoLAAAMDAAASAwAAIQMAAC5DAAA7QwAACQNAABaDQAAjg0AALoNAADVDQAA2w0AAAgA AAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAA ABgAAAAZAAAAGgAAABsAAAAcAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAA KAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAAMQAAAAAGAADbDQAACQAAAP//AQAA AAYAzXqmEAAAAQAEFiAAngUAAN0FAAAAAAAAAQCiBQAA3QUAAAAAAAABAAAAOQAAAAEAAAAqgHVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncwWAcGxhY2UAgAwAAAEBAAAA AAAAAAEAAAAAAAAAAADYAQAA7gEAACkCAAArAgAA3QUAAAcABAAHADMABwAAAAAADwAAACsAAAAs AAAAVwAAAFgAAACNAAAAsQAAALwAAAC9AAAAGgEAAD8BAABKAQAASwEAAH0BAAB+AQAAnwEAAKAB AACnAQAAygEAANcBAADYAQAA7gEAAO8BAAAOAgAAPgIAAFACAABYAgAAZQIAAIMCAACoAgAAqgIA AKsCAACzAgAA1AIAANsCAADcAgAA5AIAAAUDAAANAwAADgMAABYDAAA5AwAAQAMAAEEDAABJAwAA bQMAAHQDAAB1AwAAfQMAAKIDAACpAwAAqgMAALIDAADTAwAA2gMAANsDAADjAwAABQQAAAwEAAAN BAAAFQQAAEAEAABIBAAASQQAAFEEAAB9BAAAhAQAAIUEAAC5BAAAugQAAO0EAADuBAAAJAUAACUF AABaBQAAWwUAAHgFAACPBQAAlwUAALsFAADDBQAA3QUAAAcABQAHAAUABwAFAAcABQAHAAUABwAF AAcABQAHAAUABwAFAAcABQAHAAQABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcA BQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAF AAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcAAAAAAOUBAADuAQAA3QUAAAcABAAHAAwAAAAEAAAA CAAAAOUAAAAAAAAACwAAAOgaIgD7FzoASHpOALEMXABWd1wAaDpiAJlUcwBDApMAVVeaABEhywDS Is0AhzjgAAAAAAAPAAAAFwAAACAAAAAlAAAAJwAAACkAAAArAAAALAAAADQAAABMAAAAUQAAAFMA AABVAAAAVwAAAFgAAABgAAAAdwAAAHwAAAB+AAAAgQAAAIQAAACFAAAAjQAAALEAAAC2AAAAuAAA ALoAAAC8AAAAvQAAAMUAAADaAAAA3wAAAOEAAADkAAAA5wAAAOgAAADuAAAABAEAAAkBAAAMAQAA DgEAABEBAAASAQAAGgEAAD8BAABEAQAARgEAAEgBAABKAQAASwEAAFIBAABwAQAAdQEAAHgBAAB7 AQAAfQEAAH4BAACFAQAAkgEAAJcBAACaAQAAnQEAAJ8BAACgAQAApwEAAMoBAADPAQAA0gEAANUB AADXAQAA2AEAAFACAABYAgAAYAIAAGUCAAB6AgAAewIAAIMCAACiAgAAqAIAAKoCAACrAgAAswIA ANQCAADZAgAA2wIAANwCAADkAgAABQMAAAsDAAANAwAADgMAABYDAAA5AwAAPgMAAEADAABBAwAA SQMAAG0DAAByAwAAdAMAAHUDAAB9AwAAogMAAKcDAACpAwAAqgMAALIDAADTAwAA2AMAANoDAADb AwAA4wMAAAUEAAAKBAAADAQAAA0EAAAVBAAAQAQAAEYEAABIBAAASQQAAFEEAAB9BAAAggQAAIQE AACFBAAAjQQAALIEAAC3BAAAuQQAALoEAADCBAAA5QQAAOsEAADtBAAA7gQAAPYEAAAdBQAAIgUA ACQFAAAlBQAALQUAAFMFAABYBQAAWgUAAFsFAABjBQAAcwUAAHgFAACOBQAAjwUAAJcFAACyBQAA uAUAALoFAAC7BQAAwwUAAM0FAADTBQAA1QUAANYFAADdBQAAAAAAAAgAAAACAQAAAgEAAAIBAAAC AQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIB AAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEA AAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAA AgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAAC AQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAACWAQAACAAAAAIBAAACAQAAAgEAAAIB AACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEA AAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAA AgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAAC AQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIB AAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEA AAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAA lgEAAP9AAYABAOYBAADmAQAAiFfNAQEAAQDmAQAAAAAAAOYBAAACH7olAhAAAAAAAAAA2wUAAFAA ABAAQAAA//8BAAAABwBVAG4AawBuAG8AdwBuAP//AQAIAAAAAAAAAAAAAAD//wEAAAAAAP//AAAC AP//AAAAAP//AAACAP//AAAAAAMAAABHFpABAAACAgYDBQQFAgMEh3oAIAAAAIAIAAAAAAAAAP8B AAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAA AAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpABAAACCwYEAgICAgIEh3oAIAAA AIAIAAAAAAAAAP8BAAAAAAAAQQByAGkAYQBsAAAAIgAEADEIiBgA8MQCAACpAQAAAAA3wsSGWMPE hgAAAAAIAAAAAADNAAAADgUAAAEAAgAAAAQAAxAKAAAAzQAAAA4FAAABAAIAAAAKAAAAAAAAAMQD APAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG4EigW0ALQAgYEyNAAAAAAAAAAAAAAAAAAA 2QUAANkFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAACAAAAAAAAAAAACQEAAADwEAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABIAAAAAAAo8P8PAAABPwAA5AQAAP///3////9/////f////3////9/////f////39DApMA//8S AAAAAAAAAAAAAAAAAAAADgBNAGkAYwBoAGEAZQBsACAAQgB1AHMAcwBlAHIADgBNAGkAYwBoAGEA ZQBsACAAQgB1AHMAcwBlAHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y +U9oEKuRCAArJ7PZMAAAAFABAAAPAAAAAQAAAIAAAAACAAAAiAAAAAMAAACUAAAABAAAAKAAAAAF AAAAuAAAAAcAAADEAAAACAAAANgAAAAJAAAA8AAAABIAAAD8AAAADAAAABgBAAANAAAAJAEAAA4A AAAwAQAADwAAADgBAAAQAAAAQAEAABMAAABIAQAAAgAAAOQEAAAeAAAABAAAAAAAAAAeAAAABAAA AAAAAAAeAAAAEAAAAE1pY2hhZWwgQnVzc2VyAAAeAAAABAAAAAAAAAAeAAAADAAAAE5vcm1hbC5k b3QAAB4AAAAQAAAATWljaGFlbCBCdXNzZXIAAB4AAAAEAAAAOAAAAB4AAAAUAAAATWljcm9zb2Z0 IFdvcmQgMTAuMABAAAAAALocHdilyAFAAAAAAEhNsf2lyAEDAAAAAQAAAAMAAADNAAAAAwAAAA4F AAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN1ZwuGxCTlwgA Kyz5rjAAAADwAAAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAhAAAAAYAAACMAAAAEQAAAJQAAAAX AAAAnAAAAAsAAACkAAAAEAAAAKwAAAATAAAAtAAAABYAAAC8AAAADQAAAMQAAAAMAAAA0QAAAAIA AADkBAAAHgAAAAwAAABULVN5c3RlbXMAAAADAAAACgAAAAMAAAACAAAAAwAAANkFAAADAAAAtxoK AAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAEAAAABAAAAAAwQAAACAAAAHgAA AAYAAABUaXRlbAADAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAA DQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAb AAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkA AAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAD+////NAAAADUAAAA2AAAANwAA ADgAAAA5AAAAOgAAAP7///88AAAAPQAAAD4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAEQAAABFAAAA RgAAAEcAAABIAAAASQAAAEoAAABLAAAATAAAAE0AAABOAAAATwAAAFAAAABRAAAAUgAAAFMAAABU AAAAVQAAAFYAAABXAAAA/v///1kAAABaAAAAWwAAAFwAAABdAAAAXgAAAF8AAAD+////YQAAAGIA AABjAAAAZAAAAGUAAABmAAAAZwAAAP7////9////agAAAP7////+/////v////////////////// //////////////////////////////////////////////////////////////////////////// //////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAA AADgBkfD/aXIAWwAAACAAAAAAAAAAEQAYQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAIB////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMwAAAAAQAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgEBAAAABgAAAP// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7AAAAfjgAAAAAAABXAG8AcgBk AEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA GgACAQIAAAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3 ZAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAoAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAWAAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4A ZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgEEAAAA//////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAP////////////// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAQAAAP7///////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3JkLURva3Vt ZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAFIAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAAAAAAAAAAAAAAAMBR Qi8CpsgBcgAAAMADAAAAAAAARABhAHQAYQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAgH///////////////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAzAAAAABAAAAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAQEAAAAGAAAA/////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADsAAAB+OAAAAAAAAFcAbwByAGQARABv AGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIB AgAAAAUAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADdkAAAA AAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4A AAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAA AB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAA KwAAACwAAAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAD+////NAAAADUAAAA2AAAANwAAADgAAAA5 AAAAOgAAAP7///88AAAAPQAAAD4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAEQAAABFAAAARgAAAEcA AABIAAAASQAAAEoAAABLAAAATAAAAE0AAABOAAAATwAAAFAAAABRAAAAUgAAAFMAAABUAAAAVQAA AFYAAABXAAAA/v///1kAAABaAAAAWwAAAFwAAABdAAAAXgAAAF8AAAD+//////////////////// /////////////////////////////////////////////////////3EAAAD9/////v////7////+ ////cAAAAP////////////////////////////////////////////////////////////////// //8BAAAA/v///wMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAA AP7///////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /18AQQBkAEgAbwBjAFIAZQB2AGkAZQB3AEMAeQBjAGwAZQBJAEQAAAADAAAADgAAAF8ARQBtAGEA aQBsAFMAdQBiAGoAZQBjAHQAAAAEAAAADQAAAF8AQQB1AHQAaABvAHIARQBtAGEAaQBsAAAAAAAF AAAAGAAAAF8AQQB1AHQAaABvAHIARQBtAGEAaQBsAEQAaQBzAHAAbABhAHkATgBhAG0AZQAAAAIA AACwBAAAEwAAAAcEAAADAAAAvY5CKR8AAAA7AAAAWwBBAE4AQwBQAF0AIABNAGEAbgBkAGEAdABv AHIAeQAgAFQATABWAHMAIABpAG4AIABkAHIAYQBmAHQALQBpAGUAdABmAC0AYQBuAGMAcAAtAHAA cgBvAHQAbwBjAG8AbAAgAHAAcgBvAHAAbwBzAGEAbAAAAAAAHwAAABQAAABNAC4AQgB1AHMAcwBl AHIAQAB0AGUAbABlAGsAbwBtAC4AZABlAAAAHwAAABAAAABCAHUAcwBzAGUAcgAsACAATQBpAGMA aABhAGUAbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA BQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAACgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABYAAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBt AGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAQQAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAIAAAAYAwAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIA////////////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB AP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3JkLURva3VtZW50AAoA AABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOXCAArLPmu RAAAAAXVzdWcLhsQk5cIACss+a40AQAA8AAAAAwAAAABAAAAaAAAAA8AAABwAAAABQAAAIQAAAAG AAAAjAAAABEAAACUAAAAFwAAAJwAAAALAAAApAAAABAAAACsAAAAEwAAALQAAAAWAAAAvAAAAA0A AADEAAAADAAAANEAAAACAAAA5AQAAB4AAAAMAAAAVC1TeXN0ZW1zAAAAAwAAAAoAAAADAAAAAgAA AAMAAADZBQAAAwAAALcaCgALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAA AQAAAAAMEAAAAgAAAB4AAAAGAAAAVGl0ZWwAAwAAAAEAAAAA5AEAAAcAAAAAAAAAQAAAAAEAAAD0 AAAAAAAAgPwAAAACAAAABAEAAAMAAAAMAQAABAAAAIwBAAAFAAAAvAEAAAQAAAACAAAAFAAAAA== ------_=_NextPart_001_01C8A602.30033CE1 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp ------_=_NextPart_001_01C8A602.30033CE1-- From ancp-bounces@ietf.org Thu Apr 24 05:19:10 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 066F828C12A; Thu, 24 Apr 2008 05:19:10 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B4C63A69F6 for ; Thu, 24 Apr 2008 05:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rV1AbQ-MoAhJ for ; Thu, 24 Apr 2008 05:19:06 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C04DE3A6AE9 for ; Thu, 24 Apr 2008 05:19:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,704,1199660400"; d="scan'208,217";a="7214986" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 24 Apr 2008 14:19:08 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3OCJ8Ee001238; Thu, 24 Apr 2008 14:19:08 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3OCJ82X008616; Thu, 24 Apr 2008 12:19:08 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Apr 2008 14:19:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Apr 2008 14:19:03 +0200 Message-ID: In-Reply-To: <1B6169C658325341A3B8066E23919E1CFBC5C4@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal thread-index: AcilQRMfK4kdawUKQOWs5fdBngS8QQAAr04QACRhApAAC0ujAA== References: <1B6169C658325341A3B8066E23919E1C01230DC1@S4DE8PSAANK.mitte.t-com.de> <1B6169C658325341A3B8066E23919E1CFBC5C4@S4DE8PSAANK.mitte.t-com.de> From: "Wojciech Dec (wdec)" To: "Busser, M" , X-OriginalArrivalTime: 24 Apr 2008 12:19:08.0885 (UTC) FILETIME=[658D1050:01C8A605] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=38039; t=1209039548; x=1209903548; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20[ANCP]=20Mandatory=20TLVs=20in=20draft- ietf-ancp-protocol=20proposal |Sender:=20; bh=S50OdBYiebtdLSpfvxutfi3g1PmsNcpjk33NLIfCFyk=; b=I9NnceZtGqwhquET8YKGaxTAC8buG6mxzx2vAAdKZtTUq3vSphzM69z3Zf 9k778eoFdG92k7YByojoPznJb6zAubgvhicrbKilxFpV8m/vOvrkGmflshdO 7FwdN1TMVE; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: "Haag, T" Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0467079566==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0467079566== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A605.652E5432" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A605.652E5432 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Michael, =20 inline... ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = Busser, M Sent: 24 April 2008 13:13 To: ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal =09 =09 Hi Woi, all =20 I see the problem but i can not see, how an additional flag will help = solving this problem. =20 Lets assume your first proposal. If an implementation does not send the complete TLV, even it is defined = to be mandatory, I would call this a bug and I can not see, how an = additional flag can help here.=20 =20 Woj> The way it helps, and other protocols bear proof of this scheme, = is that it is easier for implementations to reconcile errors resulting = out of "Mandatory" and "Optional" TLV sets. The key to this lies on a = per application basis. One application may mandate TLV A for operation, = while another might not. Resolving such issues when implementing or = troubleshooting multiple applications is not always trivial.=20 =20 Your second proposal seems obviously be required to keep existing = things working, if we agree on your first proposal.=20 But from my point of view it also assumes, that all existing = implementations are using the same set of TLVs now.=20 And I am not sure about that. =20 =20 Woj> This would be a good thing for the WG to discuss. There most = evidently is a fair amount of "dead wood" in the current spec, ie stuff = that nobody yet implements or cares about. In the former case, we could = re-cast that material using the new notions/extensions, in the latter = case simply chop it out. =20 Therefore I disagree with your first proposal. I recommend, the better = way will be to be more precise in definitions.=20 In my mind, it is a bug, if a mandatory TLV is missing. It is up to the = robustness of the implementation to deal with this situation. Is it really neccesary to define the behavior of a network element in = this case of failure in the ancp protocol itself? =20 =20 Woj> Other people have faced this problem before, and I would rather go = with the lessons they learned, rather than clinging to hopes of perfect = textual definitions and implementations. Other than backwards = compatibility, I do not see in your statements a valid reason to object = to the 1st proposal, particularly for new applications since it can only = make things more robust. The counter argument of being precise in the = definitions, as evidenced by the current spec, is admirable and needs to = be there, with this proposal providing an extra level of robustness and = visibility of any problems.=20 =20 Thanks, Woj. =20 If optional TLVs are not present in a message, we should describe some = kind of default behaviour, as you already stated. =20 =20 =20 =20 =09 Comments on draft-ietf-ancp-protocol-02.txt: =20 It is not clearly stated, if the TLV "DSL Line Attributes " is = mandatory or optional.=20 In fact it is mandatory because some of its SubTLVs are mandatory.=20 We should spent a sentence to make this clear. =20 It is not clearly stated, if the TLV "Service-Profile-Name" is = mandatory or optional. I prefer mandatory because it is essetial for the use case Line Config. = =09 =20 Section 5.4.3 Line Config, where the TLVs are mentioned (page 35): ...defined in section 5.4.1.... must be corrected to ...defined = in section 5.4.2........ =20 =09 Section 5.4.4 OAM, where the TLVs are mentioned (page 36 and page 38): ...defined in section 5.4.1.... must be corrected to ...defined = in section 5.4.2........ =20 =20 =20 =20 Best Regards; Freundliche Gr=FC=DFe=20 Michael Busser =09 T-Systems Enterprise Services GmbH=20 Production Line Network Centric Systems ICT-Systems Integration Network Integration Services =20 Br=FCckes 2 -8, 55545 Bad Kreuznach Postfach 9100, 55541 Bad Kreuznach +49 671 8333 8911 (Phone) +49 521 9210 3859 (Fax) +49 151 1211 9689 (Mobile) E-Mail: michael.busser@t-systems.com =09 Internet: http://www.t-systems.com =20 =09 =20 T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Reinhard Clemens (Vorsitzender)*, Helmut Binder, = Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Wilfried = Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG =20 Notice: This transmittal and/or attachments may be privileged or = confidential. If you are not the intended recipient, you are hereby = notified that you have received this transmittal in error; any review, = dissemination, or copying is strictly prohibited. If you received this = transmittal in error, please notify us immediately by reply and = immediately delete this message and all its attachments. Thank you.=20 T-Systems - Business flexibility=20 =20 =09 =09 ________________________________ Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag = von Wojciech Dec (wdec) Gesendet: Mittwoch, 23. April 2008 14:54 An: ancp@ietf.org Betreff: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal =20 Hi All,=20 Continuing with the series of e-mails regarding basic protocol issues = still to be addressed, I now would now like to ask your feedback = regarding the distinction the protocol places on mandatory TLVs. Given = the length of this mail I'll first cut to the proposal, and after it you = can find the problem description. The proposal which I am putting in front of the WG is to define a new = TLV format which contains at a minimum a Mandatory flag (much like = Radius VSAs do). We could have this TLV Flag be defined only for new = applications. A second proposal would be try to make this flag work with existing = ones by for example defining the highest order bit of the TLV# field to = mean "Mandatory" when set to "0". This would be invisible to exiting = implementations, but newer ones may have problems in communicating with = older ones when the latter do not send all TLVs. But that can also be = addressed by simply forming the set of mandatory TLVs to be the ones = that all implementations currently send by default. Without additional feedback, I will assume that the WG is fine with = the first proposal, and also with the 2nd one conditional on deriving a = suitable "commonly used" TLV set. The problem in more detail:=20 Currently the situation is that Mandatory TLVs are only stated to be = as such in the body of the protocol draft spec, with an implementer = having to scour fairly attentively the text. Eg "Type = (Access-Loop-Circuit-ID =3D 0x01): This is a mandatory TLV", etc. The behaviour of an implementation that receives a message with a = missing mandatory TLV is not defined at all, and the opposite is handled = but not very robustly, i.e. when receiving a TLV but not recognizing it, = and implementation is free to discard it (even if it is mandatory!). = This is a recipe for interoperability problems and an implementation = mine field. This problem is complicated by different applications. For example the = current OAM section states the following regarding TLVs that are to be = carried in the request message (my italics): "=20 Following TLVs can appear in this message:=20 o Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section = 5.4.1 =20 o Type (Access-Aggregation-Circuit-ID-Binary =3D 0x06): defined = in=20 section 5.4.1.=20 =20 o Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03): defined = in section=20 5.4.1. =20 o Type (OAM-Loopback-Test-Parameters =3D 0x07): Parameters = related to =20 loopback test. This is an optional TLV. If this TLV is not = present=20 in the request message, the DSLAM SHOULD use locally = determined=20 default values for the test parameters. =20 "=20 (NOTE: The last "SHOULD" appears to be inappropriate. If the TLV is = missing, the DSLAM MUST have some default parameters, or return an = error) The "can" above indicates that they're all optional, while clearly the = application cannot run its course without one or more of these fields. = Here we have a case where one could have a perfectly compliant = implementation that ignores all these TLVs... -Woj.=20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 ------_=_NextPart_001_01C8A605.652E5432 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nachricht</TIT= LE> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2900.3314" name=3DGENERATOR><!--[if !mso]> <STYLE>v\:* { BEHAVIOR: url(#default#VML) } o\:* { BEHAVIOR: url(#default#VML) } w\:* { BEHAVIOR: url(#default#VML) } .shape { BEHAVIOR: url(#default#VML) } </STYLE> <![endif]--> <STYLE>@font-face { font-family: Tahoma; } @page Section1 {size: 595.3pt 841.9pt; margin: 70.85pt 70.85pt 2.0cm = 70.85pt; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline } A:visited { COLOR: purple; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline } P { FONT-SIZE: 12pt; MARGIN-LEFT: 0cm; MARGIN-RIGHT: 0cm; FONT-FAMILY: = "Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto } SPAN.E-MailFormatvorlage18 { COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply } DIV.Section1 { page: Section1 } </STYLE> </HEAD> <BODY lang=3DDE vLink=3Dpurple link=3Dblue> <DIV dir=3Dltr align=3Dleft><SPAN class=3D709295811-24042008><FONT = face=3DArial=20 size=3D2>Hi Michael,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D709295811-24042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D709295811-24042008><FONT = face=3DArial=20 size=3D2>inline...</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>Busser, = M<BR><B>Sent:</B>=20 24 April 2008 13:13<BR><B>To:</B> ancp@ietf.org<BR><B>Cc:</B> Haag,=20 T<BR><B>Subject:</B> Re: [ANCP] Mandatory TLVs in = draft-ietf-ancp-protocol=20 proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>Hi = Woi,=20 all</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>I = see the problem=20 but i can not see, how an additional flag will help solving this=20 problem.</FONT></SPAN></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>Lets = assume your=20 first proposal.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2>If an=20 implementation does not send the complete TLV, even it is = defined to=20 be mandatory, I would call this a bug and I can not = see, how an=20 additional flag can help here.<SPAN=20 class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Woj> The way it helps, and other = protocols bear=20 proof of this scheme, is that it is easier for implementations to = reconcile=20 errors resulting out of "Mandatory" and "Optional" TLV sets. The = key to=20 this lies on a per application basis. One application may mandate TLV = A for=20 operation, while another might not. Resolving such issues when = implementing or=20 troubleshooting multiple applications is not always trivial.=20 </SPAN></FONT></FONT></SPAN><SPAN class=3D364043506-24042008><FONT=20 face=3DArial><FONT size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>Your = second=20 proposal seems obviously be required to keep existing things = working, if=20 we agree on your first proposal. </FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>But = from my point=20 of view it also assumes, that all existing implementations are = using the=20 same set of TLVs now. </FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2>And I=20 am not sure about that. <SPAN=20 class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Woj> This would be a good thing for the = WG to=20 discuss. There most evidently is a fair amount of "dead wood" in = the=20 current spec, ie stuff that nobody yet implements or cares about. =  In the former case, we could re-cast that material using the new = notions/extensions, in the latter case simply chop it=20 out.</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2><SPAN=20 class=3D364043506-24042008><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV></FONT></SPAN> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2>Therefore I=20 disagree with your first proposal. I recommend, the better = way will be to=20 be more precise in definitions.<SPAN=20 class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>In = my mind, it is=20 a bug, if a mandatory TLV is missing. It is up to the robustness of = the=20 implementation to deal with this situation.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2>Is it really=20 neccesary to define the behavior of a network element in this case of = failure=20 in the ancp protocol itself? <SPAN=20 class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Woj> Other people have faced this = problem before,=20 and I would rather go with the lessons they learned, rather than = clinging to=20 hopes of perfect textual definitions and implementations. Other than = backwards=20 compatibility, I do not see in your statements a valid reason to = object=20 to the 1st proposal, particularly for new applications since it = can only=20 make things more robust. The counter argument of being precise in the=20 definitions, as evidenced by the current spec, is admirable and needs = to be=20 there, with this proposal providing an extra level of robustness and=20 visibility of any problems. </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Thanks,</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Woj.</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>If = optional TLVs=20 are not present in a message, we should describe some kind of default=20 behaviour, as you already stated.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Comments on=20 = draft-ietf-ancp-protocol-02.txt:</FONT></SPAN></DIV></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT = face=3DArial>It is not=20 clearly stated, if the TLV  "<SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA">DSL=20 Line Attributes "<FONT face=3DArial> is mandatory or optional.=20 </FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT = face=3DArial><SPAN=20 lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>In fact it is mandatory because some of its SubTLVs are = mandatory.=20 </FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT = face=3DArial><SPAN=20 lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>We should spent a sentence to make this=20 clear.</FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2><SPAN=20 class=3D364043506-24042008><FONT size=3D2><FONT face=3DArial>It is not = clearly=20 stated, if the TLV  "<SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: = AR-SA">Service-Profile-Name"<FONT=20 face=3DArial> is mandatory or=20 optional.</FONT></SPAN></FONT></FONT></SPAN></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2><SPAN=20 class=3D364043506-24042008><FONT size=3D2><FONT face=3DArial><SPAN = lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>I prefer mandatory because it is essetial for the use = case Line=20 = Config. </FONT></SPAN></FONT></FONT></SPAN></DIV></FONT></SPAN><SPAN= =20 class=3D364043506-24042008><FONT face=3DArial size=3D2></FONT></SPAN> <DIV><SPAN class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008><FONT face=3DArial = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Section 5.4.3 Line=20 Config, where the TLVs are mentioned (page 35):</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>  ...defined=20 in section 5.4.1....    must be corrected = to   =20 ...defined in section 5.4.2........</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Section=20 5.4.4 OAM, where the TLVs are mentioned (page 36 and page=20 38):</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>  ...defined=20 in section 5.4.1....    must be corrected = to   =20 ...defined in section 5.4.2........</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV></FONT></SPAN><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2></FONT></SPAN> </DIV></DIV> <DIV><SPAN class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN = class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN = class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV align=3Dleft><FONT color=3D#000080 size=3D2> <P align=3Dleft>Best Regards; Freundliche Gr=FC=DFe = </P></FONT><B><FONT=20 color=3D#000080> <P>Michael Busser</P></B></FONT><FONT size=3D1> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt">T-Systems=20 Enterprise Services GmbH </SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1>Production Line Network Centric Systems</FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1>ICT-Systems Integration</FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1>Network Integration Services</FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1></FONT><SPAN style=3D"COLOR: navy"></SPAN><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy"><FONT face=3DArial = color=3D#000000=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy"><FONT color=3D#000000 = size=3D1>Br=FCckes 2 -8,=20 55545 Bad Kreuznach<BR>Postfach 9100, 55541 Bad Kreuznach<BR>+49 671 = 8333 8911=20 (Phone)<BR>+49 521 9210 3859 (Fax)<BR>+49 151 1211 9689 = (Mobile)<BR>E-Mail: <A=20 = href=3D"mailto:michael.busser@t-systems.com">michael.busser@t-systems.com= </A></FONT></SPAN></DIV></SPAN> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN></DIV><SPAN style=3D"FONT-SIZE: = 8pt">Internet:=20 </SPAN><SPAN style=3D"FONT-SIZE: 8pt"><p:onmouseclick = hyperlinktype=3D"url"=20 href=3D"http://www.t-systems.com/"></p:onmouseclick><A=20 onclick=3Dwindow.event.cancelBubble=3Dtrue; = href=3D"http://www.t-systems.com/"=20 target=3D_parent><FONT=20 color=3D#6699ff>http://www.t-systems.com</FONT></A></SPAN><SPAN=20 style=3D"FONT-SIZE: 8pt"> </SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN> </DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D3><FONT size=3D1><SPAN=20 style=3D"FONT-SIZE: 7.5pt; COLOR: black; FONT-FAMILY: Arial">T-Systems = Enterprise Services GmbH<BR>Aufsichtsrat: Ren=E9 Obermann=20 (Vorsitzender)<BR>Executive Committee: Reinhard Clemens = (Vorsitzender)*,=20 Helmut Binder, Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich = Kemp,=20 Wilfried Peters*,<BR>Dr. Herbert Schaaff*, Zvezdana=20 Seeger*<BR>Handelsregister: Amtsgericht Frankfurt am Main HRB = 55933<BR>Sitz=20 der Gesellschaft: Frankfurt am Main<BR>WEEE-Reg.-Nr.=20 DE87523644<BR>*Gesch=E4ftsf=FChrer gem. =A7 35=20 GmbHG</SPAN></FONT></FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT face=3DArial=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT size=3D1>Notice: This transmittal = and/or=20 attachments may be privileged or confidential. If you are not the = intended=20 recipient, you are hereby notified that you have received this = transmittal in=20 error; any review, dissemination, or copying is strictly prohibited. = If you=20 received this transmittal in error, please notify us immediately by = reply and=20 immediately delete this message and all its attachments. Thank you.=20 </FONT><FONT size=3D1><BR>T-Systems =96 Business flexibility=20 </FONT></DIV></SPAN></SPAN> <DIV><FONT face=3DArial size=3D2></FONT> </DIV></FONT></DIV> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"> <DIV></DIV> <DIV class=3DOutlookMessageHeader lang=3Dde dir=3Dltr align=3Dleft> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: = Arial"><o:p></o:p></SPAN></FONT></P><FONT=20 face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: = 12pt"><FONT face=3DArial=20 size=3D2></FONT> <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2> </SPAN></FONT></DIV> <DIV class=3DSection1> <DIV> <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: = Tahoma">Von:</SPAN></FONT></B><FONT=20 face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Tahoma">=20 ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] <B><SPAN=20 style=3D"FONT-WEIGHT: bold">Im Auftrag von </SPAN></B>Wojciech Dec=20 (wdec)<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Gesendet:</SPAN></B> = Mittwoch,=20 23. April 2008 14:54<BR><B><SPAN style=3D"FONT-WEIGHT: = bold">An:</SPAN></B>=20 ancp@ietf.org<BR><B><SPAN style=3D"FONT-WEIGHT: = bold">Betreff:</SPAN></B>=20 [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol=20 proposal</SPAN></FONT><o:p></o:p></P></DIV> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi = All,</SPAN></FONT><SPAN=20 lang=3DEN-GB> </SPAN><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Continuing with the = series of=20 e-mails regarding basic protocol issues still to be addressed, I now = would=20 now like to ask your feedback regarding the distinction the protocol = places=20 on mandatory TLVs. Given the length of this mail I'll first cut to = the=20 proposal, and after it you can find the problem=20 description.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The proposal which I = am putting=20 in front of the WG is to define a new TLV format which contains at a = minimum=20 a Mandatory flag (much like Radius VSAs do). We could have this TLV = Flag be=20 defined only for new applications.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">A second proposal = would be try=20 to make this flag work with existing ones by for example defining = the=20 highest order bit of the TLV# field to mean "Mandatory" when set to = "0".=20 This would be invisible to exiting implementations, but newer ones = may have=20 problems in communicating with older ones when the latter do not = send all=20 TLVs. But that can also be addressed by simply forming the set of = mandatory=20 TLVs to be the ones that all implementations currently send by=20 default.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Without additional = feedback, I=20 will assume that the WG is fine with the first proposal, and also = with the=20 2nd one conditional on deriving a suitable "commonly used" TLV=20 set.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The problem in more = detail:=20 </SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Currently the = situation is that=20 Mandatory TLVs are only stated to be as such in the body of the = protocol=20 draft spec, with an implementer having to scour fairly attentively = the text.=20 Eg "Type (Access-Loop-Circuit-ID =3D 0x01): This is a mandatory = TLV",=20 etc.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The behaviour of an=20 implementation that receives a message with a missing mandatory TLV = is not=20 defined at all, and the opposite is handled but not very robustly, = i.e. when=20 receiving a TLV but not recognizing it, and implementation is free = to=20 discard it (even if it is mandatory!). This is a recipe for = interoperability=20 problems and an implementation mine = field.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">This problem is = complicated by=20 different applications. For example the current OAM section states = the=20 following regarding TLVs that are to be carried in the request = message (my=20 italics):</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">"</SPAN></FONT> = <BR><FONT=20 face=3D"Courier New" color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">Following=20 TLVs<B><I><SPAN style=3D"FONT-WEIGHT: bold; FONT-STYLE: italic">=20 can</SPAN></I></B> appear in this message: = </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section=20 5.4.1    </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (Access-Aggregation-Circuit-ID-Binary =3D 0x06): defined in=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 section 5.4.1. </SPAN></FONT><BR><FONT face=3D"Courier New" = color=3Dblack=20 size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'"> </SPAN></FONT>=20 <BR><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03): defined in = section=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 5.4.1.  </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (OAM-Loopback-Test-Parameters =3D 0x07): Parameters related = to =20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 loopback test. This is an optional TLV. If this TLV is not present=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 in the request message, the DSLAM SHOULD use locally determined=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 default values for the test parameters.  = </SPAN></FONT><BR><FONT=20 face=3D"Courier New" color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">"</SPAN></FONT>=20 <BR><FONT face=3DArial color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">(NOTE: = The last=20 "SHOULD" appears to be inappropriate. If the TLV is missing, the = DSLAM MUST=20 have some default parameters, or return an=20 error)</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">The = "can" above=20 indicates that they're all optional, while clearly the application = cannot=20 run its course without one or more of these fields. Here we have a = case=20 where one could have a perfectly compliant implementation that = ignores all=20 these TLVs=85</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = Arial">-Woj.</SPAN></FONT><SPAN=20 lang=3DEN-US> </SPAN><o:p></o:p></P> <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><FONT = face=3D"Times New Roman"=20 size=3D3><SPAN=20 style=3D"FONT-SIZE: = 12pt"><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><o:p></o:p></SPAN></FONT></= P></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C8A605.652E5432-- --===============0467079566== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============0467079566==-- From ancp-bounces@ietf.org Thu Apr 24 05:21:37 2008 Return-Path: <ancp-bounces@ietf.org> X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AF0828C13B; Thu, 24 Apr 2008 05:21:37 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEE5128C1F4 for <ancp@core3.amsl.com>; Thu, 24 Apr 2008 05:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbGAt8nQw3Sq for <ancp@core3.amsl.com>; Thu, 24 Apr 2008 05:21:33 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2DBAF28C13B for <ancp@ietf.org>; Thu, 24 Apr 2008 05:21:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,704,1199660400"; d="scan'208,217";a="7215312" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 24 Apr 2008 14:21:36 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3OCLaqI002119; Thu, 24 Apr 2008 14:21:36 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3OCLaO5009736; Thu, 24 Apr 2008 12:21:36 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Apr 2008 14:21:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Apr 2008 14:21:32 +0200 Message-ID: <D9872168DBD43A41BD71FFC4713274D404FA6ACF@xmb-ams-33b.emea.cisco.com> In-Reply-To: <1B6169C658325341A3B8066E23919E1CFBC5C5@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal thread-index: AcimAi8p7t9nyaObSuqCLEf2fY/H5gAAzbTA References: <1B6169C658325341A3B8066E23919E1CFBC5C5@S4DE8PSAANK.mitte.t-com.de> From: "Wojciech Dec (wdec)" <wdec@cisco.com> To: "Busser, M" <Michael.Busser@t-systems.com>, <ancp@ietf.org> X-OriginalArrivalTime: 24 Apr 2008 12:21:36.0646 (UTC) FILETIME=[BD9F9A60:01C8A605] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12205; t=1209039696; x=1209903696; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20<wdec@cisco.com> |Subject:=20RE=3A=20[ANCP]=20=20Mandatory=20TLVs=20in=20dra ft-ietf-ancp-protocol=20proposal |Sender:=20; bh=/BuLZEJrpnBzTI+IQJ5Xsx17fmoUvBLaHghas6R2lKw=; b=jR3TPtq5exoFtHQMjYsB4bM9BlWTx2l2oNUlB1/q2ZT3CBx2WI7Vahn5MM 448rctl6f/kvxu5OEkQlpv3NwwttUIO0psoQEhp7GrV4ABhnl031U4uFj8uM G6jF2p9HDt; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list <ancp.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/ancp> List-Post: <mailto:ancp@ietf.org> List-Help: <mailto:ancp-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0742130977==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0742130977== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A605.BD6362B8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A605.BD6362B8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Michael, =20 inline... ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = Busser, M Sent: 24 April 2008 13:56 To: ancp@ietf.org Subject: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal =09 =09 Hi all =20 At the actual ANCP draft most of the Sub-TLVs in "DSL Line Attributes" = are optional. At the DSL Forum, this TLVs are mandatory. =20 I suggest to set them mandatory in ANCP as well to be in line with the = DSL Forum.=20 =20 Woj> Existing implementations seem to work fine with them being = precisely optional. Why should they be mandatory?=20 =20 Another suggestion is to have a small table somewhere in the draft = (maybe an appendix) where all the TLVs are listed with their encodings an if they are = mandatory or optional.=20 =20 Woj> I second this suggestion, adding that it should be done on a per = application basis. =20 Regards, Woj Please see attachement as an example. =20 =20 Best Regards; Freundliche Gr=FC=DFe=20 Michael Busser =09 T-Systems Enterprise Services GmbH=20 Production Line Network Centric Systems ICT-Systems Integration Network Integration Services =20 Br=FCckes 2 -8, 55545 Bad Kreuznach Postfach 9100, 55541 Bad Kreuznach +49 671 8333 8911 (Phone) +49 521 9210 3859 (Fax) +49 151 1211 9689 (Mobile) E-Mail: michael.busser@t-systems.com =09 Internet: http://www.t-systems.com <http://www.t-systems.com/> =20 =09 =20 T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Reinhard Clemens (Vorsitzender)*, Helmut Binder, = Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Wilfried = Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG =20 Notice: This transmittal and/or attachments may be privileged or = confidential. If you are not the intended recipient, you are hereby = notified that you have received this transmittal in error; any review, = dissemination, or copying is strictly prohibited. If you received this = transmittal in error, please notify us immediately by reply and = immediately delete this message and all its attachments. Thank you.=20 T-Systems - Business flexibility=20 =20 =20 ------_=_NextPart_001_01C8A605.BD6362B8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns:p =3D = "urn:schemas-microsoft-com:office:powerpoint"><HEAD><TITLE>Nachricht</TIT= LE> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2900.3314" name=3DGENERATOR></HEAD> <BODY> <DIV dir=3Dltr align=3Dleft><SPAN class=3D627091912-24042008><FONT = face=3DArial=20 size=3D2>Hi Michael,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D627091912-24042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D627091912-24042008><FONT = face=3DArial=20 size=3D2>inline...</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>Busser, = M<BR><B>Sent:</B>=20 24 April 2008 13:56<BR><B>To:</B> ancp@ietf.org<BR><B>Subject:</B> = [ANCP]=20 Mandatory TLVs in draft-ietf-ancp-protocol = proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV><SPAN class=3D733181711-24042008><FONT face=3DArial size=3D2>Hi=20 all</FONT></SPAN></DIV> <DIV><SPAN class=3D733181711-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D733181711-24042008><FONT face=3DArial size=3D2>At = the actual=20 ANCP draft most of the Sub-TLVs in "DSL Line Attributes"  are=20 optional.</FONT></SPAN></DIV> <DIV><SPAN class=3D733181711-24042008><FONT face=3DArial size=3D2>At = the DSL Forum,=20 this TLVs are mandatory.</FONT></SPAN></DIV> <DIV><SPAN class=3D733181711-24042008></SPAN> </DIV> <DIV><SPAN class=3D733181711-24042008><FONT face=3DArial><FONT = size=3D2>I suggest to=20 set them mandatory in ANCP as well to be in line with the DSL = Forum.<SPAN=20 class=3D627091912-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D733181711-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D627091912-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D733181711-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D627091912-24042008>Woj> Existing implementations seem to = work fine=20 with them being precisely optional. Why should they be=20 mandatory? </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D733181711-24042008><FONT face=3DArial = size=3D2></FONT><FONT=20 face=3DArial size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D733181711-24042008><FONT face=3DArial = size=3D2>Another suggestion=20 is to have a small table somewhere in the draft (maybe an=20 appendix)</FONT></SPAN></DIV> <DIV><SPAN class=3D733181711-24042008><FONT face=3DArial><FONT = size=3D2>where all=20 the TLVs are listed with their encodings an if they are = mandatory or=20 optional.<SPAN=20 class=3D627091912-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D733181711-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D627091912-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D733181711-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D627091912-24042008>Woj> I second this suggestion, = adding that it=20 should be done on a per application = basis.</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D733181711-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D627091912-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D733181711-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D627091912-24042008>Regards,</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D733181711-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D627091912-24042008>Woj</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D733181711-24042008><FONT face=3DArial = size=3D2>Please see=20 attachement as an example.</FONT>  </SPAN></DIV> <DIV><SPAN class=3D733181711-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV align=3Dleft><FONT color=3D#000080 size=3D2> <P align=3Dleft>Best Regards; Freundliche Gr=FC=DFe = </P></FONT><B><FONT=20 color=3D#000080> <P>Michael Busser</P></B></FONT><FONT size=3D1> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt">T-Systems=20 Enterprise Services GmbH </SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1>Production Line Network Centric Systems</FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1>ICT-Systems Integration</FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1>Network Integration Services</FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1></FONT><SPAN style=3D"COLOR: navy"></SPAN><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy"><FONT face=3DArial = color=3D#000000=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy"><FONT color=3D#000000 = size=3D1>Br=FCckes 2 -8,=20 55545 Bad Kreuznach<BR>Postfach 9100, 55541 Bad Kreuznach<BR>+49 671 = 8333 8911=20 (Phone)<BR>+49 521 9210 3859 (Fax)<BR>+49 151 1211 9689 = (Mobile)<BR>E-Mail: <A=20 = href=3D"mailto:michael.busser@t-systems.com">michael.busser@t-systems.com= </A></FONT></SPAN></DIV></SPAN> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN></DIV><SPAN style=3D"FONT-SIZE: = 8pt">Internet:=20 </SPAN><SPAN style=3D"FONT-SIZE: 8pt"><p:onmouseclick=20 href=3D"http://www.t-systems.com/" = hyperlinktype=3D"url"></p:onmouseclick><A=20 onclick=3Dwindow.event.cancelBubble=3Dtrue; = href=3D"http://www.t-systems.com/"=20 target=3D_parent><FONT=20 color=3D#6699ff>http://www.t-systems.com</FONT></A></SPAN><SPAN=20 style=3D"FONT-SIZE: 8pt"> </SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN> </DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D3><FONT size=3D1><SPAN=20 style=3D"FONT-SIZE: 7.5pt; COLOR: black; FONT-FAMILY: Arial">T-Systems = Enterprise Services GmbH<BR>Aufsichtsrat: Ren=E9 Obermann=20 (Vorsitzender)<BR>Executive Committee: Reinhard Clemens = (Vorsitzender)*,=20 Helmut Binder, Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich = Kemp,=20 Wilfried Peters*,<BR>Dr. Herbert Schaaff*, Zvezdana=20 Seeger*<BR>Handelsregister: Amtsgericht Frankfurt am Main HRB = 55933<BR>Sitz=20 der Gesellschaft: Frankfurt am Main<BR>WEEE-Reg.-Nr.=20 DE87523644<BR>*Gesch=E4ftsf=FChrer gem. =A7 35=20 GmbHG</SPAN></FONT></FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT face=3DArial=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT size=3D1>Notice: This transmittal = and/or=20 attachments may be privileged or confidential. If you are not the = intended=20 recipient, you are hereby notified that you have received this = transmittal in=20 error; any review, dissemination, or copying is strictly prohibited. = If you=20 received this transmittal in error, please notify us immediately by = reply and=20 immediately delete this message and all its attachments. Thank you.=20 </FONT><FONT size=3D1><BR>T-Systems =96 Business flexibility=20 </FONT></DIV></SPAN></SPAN> <DIV><FONT face=3DArial size=3D2></FONT> </DIV></FONT></DIV> <DIV> </DIV></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C8A605.BD6362B8-- --===============0742130977== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============0742130977==-- From ancp-bounces@ietf.org Thu Apr 24 10:13:59 2008 Return-Path: <ancp-bounces@ietf.org> X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3B9428C269; Thu, 24 Apr 2008 10:13:59 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0001228C24B for <ancp@core3.amsl.com>; Thu, 24 Apr 2008 10:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bg6Wwdw66Q6Q for <ancp@core3.amsl.com>; Thu, 24 Apr 2008 10:13:53 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B807A28C269 for <ancp@ietf.org>; Thu, 24 Apr 2008 10:13:52 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 24 Apr 2008 10:13:57 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m3OHDvQ8016536; Thu, 24 Apr 2008 10:13:57 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m3OHDv1D023639; Thu, 24 Apr 2008 17:13:57 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Apr 2008 10:13:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Apr 2008 10:14:08 -0700 Message-ID: <48214755113BB04F84D958B4F0DE261C0593011A@xmb-sjc-222.amer.cisco.com> In-Reply-To: <A1F769BC58A8B146B2EEA818EAE052A20121E8248C@GRFMBX702RM001.griffon.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: question regarding Labels in ANCP port up messages Thread-Index: AcigmA/KomZRxzutR3KVCt4iUapYhQEdac+QAAJNLMAADUINAAAvT/GQAADkesAAAvMysAAAjrywAAGWHyA= References: <A1F769BC58A8B146B2EEA818EAE052A279468D4F@GRFMBX702RM001.griffon.local> <A1F769BC58A8B146B2EEA818EAE052A27B09701A@GRFMBX702RM001.griffon.local> <D9872168DBD43A41BD71FFC4713274D404F5E0F1@xmb-ams-33b.emea.cisco.com> <A1F769BC58A8B146B2EEA818EAE052A27B097025@GRFMBX702RM001.griffon.local> <D9872168DBD43A41BD71FFC4713274D404FA6B20@xmb-ams-33b.emea.cisco.com> <A1F769BC58A8B146B2EEA818EAE052A20121E8248B@GRFMBX702RM001.griffon.local> <48214755113BB04F84D958B4F0DE261C0593001F@xmb-sjc-222.amer.cisco.com> <A1F769BC58A8B146B2EEA818EAE052A20121E8248C@GRFMBX702RM001.griffon.local> From: "Philippe Champagne (pchamp)" <pchamp@cisco.com> To: "Sanjay Wadhwa" <swadhwa@juniper.net> X-OriginalArrivalTime: 24 Apr 2008 17:13:57.0473 (UTC) FILETIME=[94C56510:01C8A62E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=23401; t=1209057237; x=1209921237; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pchamp@cisco.com; z=From:=20=22Philippe=20Champagne=20(pchamp)=22=20<pchamp@ci sco.com> |Subject:=20question=20regarding=20=20Labels=20in=20ANCP=20 port=20up=20messages |Sender:=20; bh=wq4zjkTAWJnR1rDK9ZDziSZLTv3VZ0KIl4YHEc+/Q5U=; b=oaoC2uBFewXlZNuZFhJ+3StrrrVCl3iWLRX4mGfDaWPpTN+0LKetLUHYoU uQT42O76AOJmx60180nzkcFIi371e7yT3qB8Cm/5+0zI93Le6iB8tYuPklju xhLljdSyta; Authentication-Results: sj-dkim-4; header.From=pchamp@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: ancp@ietf.org Subject: [ANCP] question regarding Labels in ANCP port up messages X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list <ancp.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/ancp> List-Post: <mailto:ancp@ietf.org> List-Help: <mailto:ancp-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1499854300==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1499854300== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A62E.94A83C90" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A62E.94A83C90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sanjay =20 In section 5.4.2 of the draft, we have: =20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Vers | Sub | Message Type | Result| Code |=20 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Partition ID | Transaction Identifier | =20 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |I| SubMessage Number | Length |=20 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Port |=20 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Port Session Number |=20 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Event Sequence Number |=20 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |x|S|x|x| |=20 +-+-+-+-+ Label |=20 ~ ~=20 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length |=20 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ Extension Value ~=20 | |=20 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 Where Label I suppose is taken from the RFC 3292, section 3.1.3: (well, I'm guessing) =20 A summary of TLV labels supported in this version of the protocol is listed below: TLV Label Type Section Title --------- ---- ------------- ATM Label 0x100 ATM TLV Labels FR Label 0x101 Frame Relay TLV Labels MPLS Gen Label 0x102 MPLS Generic TLV Labels FEC Label 0x103 FEC TLV Labels All Labels will be designated as follow: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|S|x|x| Label Type | Label Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Label Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ x: Reserved Flags. These are generally used by specific messages and will be defined in those messages. S: Stacked Label Indicator Label Stacking is discussed below in section 3.1.3.5 Label Type A 12-bit field indicating the type of label. Label Length A 16-bit field indicating the length of the Label Value field in bytes. Label Value A variable length field that is an integer number of 32 bit words long. The Label Value field is interpreted according to the Label Type as described in the following sections. =20 =20 The draft is a bit obscure about this and since it doesn't specify much, it can lead to misinterpretation for the unused part. Moreover, it would appear that several implementations currently use another format for the label field. Can you explain? I mean, how come what's in the current draft doesn't match what's known to be implemented? =20 I'm still wondering why we carried over pieces from GSMP that we do not intend to use.=20 =20 I would recommend that if we are to keep them but not use them, we should mention precisely how we intend not to use them: that is how many 0 filled bytes this is expected to use =20 The rfc 3292 doesn't cover the case where this field is not used.=20 =20 Can you shed some ligths on this? =20 Thanks Regards Phil =20 =20 =20 ------_=_NextPart_001_01C8A62E.94A83C90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20 "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word" xmlns:p =3D=20 "urn:schemas-microsoft-com:office:powerpoint" xmlns:oa =3D=20 "urn:schemas-microsoft-com:office:activation" xmlns:st1 =3D=20 "urn:schemas-microsoft-com:office:smarttags"><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.2900.3314" name=3DGENERATOR><!--[if !mso]> <STYLE>v\:* { BEHAVIOR: url(#default#VML) } o\:* { BEHAVIOR: url(#default#VML) } w\:* { BEHAVIOR: url(#default#VML) } .shape { BEHAVIOR: url(#default#VML) } </STYLE> <![endif]--><o:SmartTagType name=3D"PlaceName"=20 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT= ype><o:SmartTagType=20 name=3D"PlaceType"=20 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT= ype><o:SmartTagType=20 name=3D"place"=20 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT= ype><o:SmartTagType=20 name=3D"PersonName"=20 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT= ype><!--[if !mso]> <STYLE>st1\:* { BEHAVIOR: url(#default#ieooui) } </STYLE> <![endif]--> <STYLE>@font-face { font-family: Wingdings; } @font-face { font-family: MS Mincho; } @font-face { font-family: Tahoma; } @font-face { font-family: @MS Mincho; } @page Section1 {size: 595.3pt 841.9pt; margin: 70.85pt 107.65pt 2.0cm = 107.65pt; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline } A:visited { COLOR: purple; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline } P.MsoPlainText { FONT-SIZE: 10pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: Arial } LI.MsoPlainText { FONT-SIZE: 10pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: Arial } DIV.MsoPlainText { FONT-SIZE: 10pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: Arial } P { FONT-SIZE: 12pt; MARGIN-LEFT: 0cm; MARGIN-RIGHT: 0cm; FONT-FAMILY: = "Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto } SPAN.EmailStyle19 { COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal } SPAN.EmailStyle20 { COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply } DIV.Section1 { page: Section1 } </STYLE> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></HEAD> <BODY lang=3DIT vLink=3Dpurple link=3Dblue> <DIV dir=3Dltr align=3Dleft><SPAN class=3D843473715-24042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Hi Sanjay</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D843473715-24042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D843473715-24042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>In section 5.4.2 of the draft, we = have:</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D843473715-24042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D843473715-24042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D843473715-24042008><FONT=20 face=3D"Courier New">        =20 0            =       =20 1            =       =20 2            =       =20 3 <BR>         0 1 2 3 4 5 6 7 8 = 9 0 1 2=20 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 <BR>       =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 <BR>        | Vers  |  = Sub  |=20 Message Type  | Result|       =20 Code           |=20 <BR>       =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 <BR>        | Partition ID =20 |            = Transaction=20 Identifier          &nb= sp; =20 |     <BR>        = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 <BR>        = |I|     =20 SubMessage Number     =20 |          =20 Length           &= nbsp; =20 | <BR>       =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 <BR>       =20 |            =             &= nbsp;   =20 Port           &nb= sp;           &nbs= p;     =20 | <BR>       =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 <BR>       =20 |            =          =20 Port Session=20 Number           &= nbsp;         =20 | <BR>       =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 <BR>       =20 |            =         =20 Event Sequence=20 Number           &= nbsp;        =20 | <BR>       =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 <BR>       =20 |x|S|x|x|          &nbs= p;            = ;            =             &= nbsp;      =20 | <BR>       =20 +-+-+-+-+          &nbs= p;         =20 Label           &n= bsp;           &nb= sp;    =20 | <BR>       =20 ~            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p; =20 ~ <BR>       =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 <BR>        |x|x|x|x|x|x|x|x| Message = Type  |   Tech Type   | Block Length  |=20 <BR>       =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 <BR>       =20 |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p; =20 | <BR>       =20 ~            =              = Extension=20 Value           &n= bsp;          =20 ~ <BR>       =20 |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p; =20 | <BR>       =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 <BR></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D843473715-24042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Where Label I suppose is taken from the RFC = 3292, section=20 3.1.3: (well, I'm guessing)</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D843473715-24042008><FONT=20 face=3D"Courier New"></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D843473715-24042008><FONT = color=3D#0000ff=20 size=3D2><FONT face=3D"Courier New" color=3D#000000 = size=3D3>   A summary of=20 TLV labels supported in this version of the protocol is<BR>   = listed=20 below:<BR><BR>      TLV=20 Label      = Type      =20 Section Title<BR>     =20 ---------      = ----      =20 -------------<BR>      ATM=20 Label      0x100      = ATM TLV=20 Labels<BR>      FR=20 Label       = 0x101     =20 Frame Relay TLV Labels<BR>      MPLS Gen Label=20 0x102      MPLS Generic TLV=20 Labels<BR>      FEC = Label     =20 0x103      FEC TLV Labels<BR><BR>   = All=20 Labels will be designated as follow:<BR><BR>   =20 0            =       =20 1            =       =20 2            =       =20 3<BR>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7=20 8 9 0 1<BR>  =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbs= p; =20 |x|S|x|x|       Label=20 Type     =20 |          Label=20 Length         |<BR>   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbs= p; =20 |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p; =20 |<BR>  =20 ~            =             &= nbsp;=20 Label=20 Value           &n= bsp;           &nb= sp; =20 ~<BR>  =20 |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p; =20 |<BR>  =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR><BR>=      =20 x: Reserved Flags.<BR>         = These are=20 generally used by specific messages and will=20 be<BR>         defined in those=20 messages.<BR><BR>      S: Stacked Label=20 Indicator<BR>         Label = Stacking is=20 discussed below in section 3.1.3.5<BR><BR>      = Label=20 Type<BR>         A 12-bit field=20 indicating the type of label.<BR><BR>      = Label=20 Length<BR>         A 16-bit = field=20 indicating the length of the Label Value=20 field<BR>         in=20 bytes.<BR><BR></FONT><FONT face=3D"Courier New" color=3D#000000=20 size=3D3>      Label=20 Value<BR>         A variable = length=20 field that is an integer number of 32=20 bit<BR>         words = long.  The=20 Label Value field is interpreted according=20 to<BR>         the Label Type as = described in the following sections.<BR></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D843473715-24042008><FONT = color=3D#0000ff=20 size=3D2><FONT face=3D"Courier New" color=3D#000000 size=3D3><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></FONT></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D843473715-24042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D843473715-24042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>The draft is a bit obscure about this and since = it doesn't=20 specify much, it can lead to misinterpretation for the unused part. = Moreover, it=20 would appear that several implementations currently use another format = for the=20 label field. Can you explain?  I mean, how come what's in the = current draft=20 doesn't match what's known to be implemented?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D843473715-24042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D843473715-24042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>I'm still wondering why we carried over pieces = from GSMP=20 that we do not intend to use. </FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D843473715-24042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D843473715-24042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>I would recommend that if we are to keep them = but not use=20 them, we should mention precisely how we intend not to use them: that is = how=20 many 0 filled bytes this is expected to use</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D843473715-24042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D843473715-24042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>The rfc 3292 doesn't cover the case where this = field is not=20 used. </FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D843473715-24042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D843473715-24042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Can you shed some ligths on = this?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D843473715-24042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D843473715-24042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Thanks</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D843473715-24042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Regards</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D843473715-24042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Phil</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D843473715-24042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D843473715-24042008><FONT = color=3D#0000ff=20 size=3D2><FONT face=3D"Courier New" color=3D#000000 size=3D3><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></FONT></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D843473715-24042008><FONT = color=3D#0000ff=20 size=3D2><FONT face=3D"Courier New" color=3D#000000 size=3D3><FONT = face=3DArial=20 color=3D#0000ff = size=3D2></FONT> </DIV></FONT></FONT></SPAN></BODY></HTML> ------_=_NextPart_001_01C8A62E.94A83C90-- --===============1499854300== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============1499854300==-- From ancp-bounces@ietf.org Mon Apr 28 07:03:45 2008 Return-Path: <ancp-bounces@ietf.org> X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16B8628C0E7; Mon, 28 Apr 2008 07:03:45 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E4A028C0E7 for <ancp@core3.amsl.com>; Mon, 28 Apr 2008 07:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFq5uQwsT2QM for <ancp@core3.amsl.com>; Mon, 28 Apr 2008 07:03:42 -0700 (PDT) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id 473F23A699B for <ancp@ietf.org>; Mon, 28 Apr 2008 07:03:40 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m3SDtPxg032223; Mon, 28 Apr 2008 15:55:25 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 28 Apr 2008 16:03:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Apr 2008 16:03:38 +0200 Message-ID: <7A6D4815C5E8F74988784FEBD50F2F1E01ABAA16@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <D9872168DBD43A41BD71FFC4713274D404FA6ACC@xmb-ams-33b.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal Thread-Index: AcilQRMfK4kdawUKQOWs5fdBngS8QQAAr04QACRhApAAC0ujAADNHRyw References: <1B6169C658325341A3B8066E23919E1C01230DC1@S4DE8PSAANK.mitte.t-com.de><1B6169C658325341A3B8066E23919E1CFBC5C4@S4DE8PSAANK.mitte.t-com.de> <D9872168DBD43A41BD71FFC4713274D404FA6ACC@xmb-ams-33b.emea.cisco.com> From: "DE CNODDER Stefaan" <stefaan.de_cnodder@alcatel-lucent.be> To: "Wojciech Dec (wdec)" <wdec@cisco.com>, "Busser, M" <Michael.Busser@t-systems.com>, <ancp@ietf.org> X-OriginalArrivalTime: 28 Apr 2008 14:03:40.0424 (UTC) FILETIME=[A954F880:01C8A938] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: "Haag, T" <Thomas.Haag@t-systems.com> Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list <ancp.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/ancp> List-Post: <mailto:ancp@ietf.org> List-Help: <mailto:ancp-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============2134997131==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============2134997131== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A938.A914A6E0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A938.A914A6E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Hi, =20 This new mandatory flag, what is exactly its meaning? =20 (1) if flag set to "mandatory", then the *receiver* of this TLV MUST = process it, and if unrecognized must drop the message =20 OR =20 (2) if flag is set to"mandatory", then the *sender* MUST include it in = the message for which it is defined =20 The current protocols draft says for certain TLVs that they are = mandatory, but that applies to the sender of it (interpretation 2). The = flag would indicate interpretation 1 (like for Radius VSAs?)? =20 If the higher order bit is set to "0" means that it is mandatory, then = currently defined optional defined TLVs suddenly become mandatory which = is not good. =20 But I would first to understand the exact meaning of this mandatory = flag. Defining such a flag indeed looks useful but then as = interpretation 1, and I would say that if flag set to 1, then it is = mandatory and actually, it is possible that a TLV is sent sometimes as = optional and sometimes as mandatory. =20 regards, Stefaan =20 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = Wojciech Dec (wdec) Sent: donderdag 24 april 2008 14:19 To: Busser, M; ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal Hi Michael, =20 inline... ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = Busser, M Sent: 24 April 2008 13:13 To: ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal =09 =09 Hi Woi, all =20 I see the problem but i can not see, how an additional flag will help = solving this problem. =20 Lets assume your first proposal. If an implementation does not send the complete TLV, even it is defined = to be mandatory, I would call this a bug and I can not see, how an = additional flag can help here.=20 =20 Woj> The way it helps, and other protocols bear proof of this scheme, = is that it is easier for implementations to reconcile errors resulting = out of "Mandatory" and "Optional" TLV sets. The key to this lies on a = per application basis. One application may mandate TLV A for operation, = while another might not. Resolving such issues when implementing or = troubleshooting multiple applications is not always trivial.=20 =20 Your second proposal seems obviously be required to keep existing = things working, if we agree on your first proposal.=20 But from my point of view it also assumes, that all existing = implementations are using the same set of TLVs now.=20 And I am not sure about that. =20 =20 Woj> This would be a good thing for the WG to discuss. There most = evidently is a fair amount of "dead wood" in the current spec, ie stuff = that nobody yet implements or cares about. In the former case, we could = re-cast that material using the new notions/extensions, in the latter = case simply chop it out. =20 Therefore I disagree with your first proposal. I recommend, the better = way will be to be more precise in definitions.=20 In my mind, it is a bug, if a mandatory TLV is missing. It is up to the = robustness of the implementation to deal with this situation. Is it really neccesary to define the behavior of a network element in = this case of failure in the ancp protocol itself? =20 =20 Woj> Other people have faced this problem before, and I would rather go = with the lessons they learned, rather than clinging to hopes of perfect = textual definitions and implementations. Other than backwards = compatibility, I do not see in your statements a valid reason to object = to the 1st proposal, particularly for new applications since it can only = make things more robust. The counter argument of being precise in the = definitions, as evidenced by the current spec, is admirable and needs to = be there, with this proposal providing an extra level of robustness and = visibility of any problems.=20 =20 Thanks, Woj. =20 If optional TLVs are not present in a message, we should describe some = kind of default behaviour, as you already stated. =20 =20 =20 =20 =09 Comments on draft-ietf-ancp-protocol-02.txt: =20 It is not clearly stated, if the TLV "DSL Line Attributes " is = mandatory or optional.=20 In fact it is mandatory because some of its SubTLVs are mandatory.=20 We should spent a sentence to make this clear. =20 It is not clearly stated, if the TLV "Service-Profile-Name" is = mandatory or optional. I prefer mandatory because it is essetial for the use case Line Config. = =09 =20 Section 5.4.3 Line Config, where the TLVs are mentioned (page 35): ...defined in section 5.4.1.... must be corrected to ...defined = in section 5.4.2........ =20 =09 Section 5.4.4 OAM, where the TLVs are mentioned (page 36 and page 38): ...defined in section 5.4.1.... must be corrected to ...defined = in section 5.4.2........ =20 =20 =20 =20 Best Regards; Freundliche Gr=FC=DFe=20 Michael Busser =09 T-Systems Enterprise Services GmbH=20 Production Line Network Centric Systems ICT-Systems Integration Network Integration Services =20 Br=FCckes 2 -8, 55545 Bad Kreuznach Postfach 9100, 55541 Bad Kreuznach +49 671 8333 8911 (Phone) +49 521 9210 3859 (Fax) +49 151 1211 9689 (Mobile) E-Mail: michael.busser@t-systems.com =09 Internet: http://www.t-systems.com <http://www.t-systems.com/> =20 =09 =20 T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Reinhard Clemens (Vorsitzender)*, Helmut Binder, = Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Wilfried = Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG =20 Notice: This transmittal and/or attachments may be privileged or = confidential. If you are not the intended recipient, you are hereby = notified that you have received this transmittal in error; any review, = dissemination, or copying is strictly prohibited. If you received this = transmittal in error, please notify us immediately by reply and = immediately delete this message and all its attachments. Thank you.=20 T-Systems - Business flexibility=20 =20 =09 =09 ________________________________ Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag = von Wojciech Dec (wdec) Gesendet: Mittwoch, 23. April 2008 14:54 An: ancp@ietf.org Betreff: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal =20 Hi All,=20 Continuing with the series of e-mails regarding basic protocol issues = still to be addressed, I now would now like to ask your feedback = regarding the distinction the protocol places on mandatory TLVs. Given = the length of this mail I'll first cut to the proposal, and after it you = can find the problem description. The proposal which I am putting in front of the WG is to define a new = TLV format which contains at a minimum a Mandatory flag (much like = Radius VSAs do). We could have this TLV Flag be defined only for new = applications. A second proposal would be try to make this flag work with existing = ones by for example defining the highest order bit of the TLV# field to = mean "Mandatory" when set to "0". This would be invisible to exiting = implementations, but newer ones may have problems in communicating with = older ones when the latter do not send all TLVs. But that can also be = addressed by simply forming the set of mandatory TLVs to be the ones = that all implementations currently send by default. Without additional feedback, I will assume that the WG is fine with = the first proposal, and also with the 2nd one conditional on deriving a = suitable "commonly used" TLV set. The problem in more detail:=20 Currently the situation is that Mandatory TLVs are only stated to be = as such in the body of the protocol draft spec, with an implementer = having to scour fairly attentively the text. Eg "Type = (Access-Loop-Circuit-ID =3D 0x01): This is a mandatory TLV", etc. The behaviour of an implementation that receives a message with a = missing mandatory TLV is not defined at all, and the opposite is handled = but not very robustly, i.e. when receiving a TLV but not recognizing it, = and implementation is free to discard it (even if it is mandatory!). = This is a recipe for interoperability problems and an implementation = mine field. This problem is complicated by different applications. For example the = current OAM section states the following regarding TLVs that are to be = carried in the request message (my italics): "=20 Following TLVs can appear in this message:=20 o Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section = 5.4.1 =20 o Type (Access-Aggregation-Circuit-ID-Binary =3D 0x06): defined = in=20 section 5.4.1.=20 =20 o Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03): defined = in section=20 5.4.1. =20 o Type (OAM-Loopback-Test-Parameters =3D 0x07): Parameters = related to =20 loopback test. This is an optional TLV. If this TLV is not = present=20 in the request message, the DSLAM SHOULD use locally = determined=20 default values for the test parameters. =20 "=20 (NOTE: The last "SHOULD" appears to be inappropriate. If the TLV is = missing, the DSLAM MUST have some default parameters, or return an = error) The "can" above indicates that they're all optional, while clearly the = application cannot run its course without one or more of these fields. = Here we have a case where one could have a perfectly compliant = implementation that ignores all these TLVs... -Woj.=20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 ------_=_NextPart_001_01C8A938.A914A6E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns:v =3D "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word" xmlns:p =3D=20 "urn:schemas-microsoft-com:office:powerpoint"><HEAD><TITLE>Nachricht</TIT= LE> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2900.3314" name=3DGENERATOR><!--[if !mso]> <STYLE>v\:* { BEHAVIOR: url(#default#VML) } o\:* { BEHAVIOR: url(#default#VML) } w\:* { BEHAVIOR: url(#default#VML) } .shape { BEHAVIOR: url(#default#VML) } </STYLE> <![endif]--> <STYLE>@font-face { font-family: Tahoma; } @page Section1 {size: 595.3pt 841.9pt; margin: 70.85pt 70.85pt 2.0cm = 70.85pt; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline } A:visited { COLOR: purple; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline } P { FONT-SIZE: 12pt; MARGIN-LEFT: 0cm; MARGIN-RIGHT: 0cm; FONT-FAMILY: = "Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto } SPAN.E-MailFormatvorlage18 { COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply } DIV.Section1 { page: Section1 } </STYLE> </HEAD> <BODY lang=3DDE vLink=3Dpurple link=3Dblue> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Hi,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>This new mandatory flag, what is exactly its=20 meaning?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>(1) if flag set to "mandatory", then the = *receiver* of=20 this TLV MUST process it, and if unrecognized must drop the=20 message</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>OR</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>(2) if flag is set to"mandatory", then the = *sender*=20 MUST include it in the message for which it is = defined</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>The current protocols draft says for certain = TLVs that they=20 are mandatory, but that applies to the sender of it (interpretation = 2). =20 The flag would indicate interpretation 1 (like for Radius=20 VSAs?)?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>If the higher order bit is set to "0" means = that it is=20 mandatory, then currently defined optional defined TLVs suddenly become=20 mandatory which is not good.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>But I would first to understand the exact = meaning of this=20 mandatory flag.  Defining such a flag indeed looks useful but then = as=20 interpretation 1, and I would say that if flag set to 1, then it is = mandatory=20 and actually, it is possible that a TLV is sent sometimes as optional = and=20 sometimes as mandatory.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Stefaan</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT> </DIV><BR> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>Wojciech Dec=20 (wdec)<BR><B>Sent:</B> donderdag 24 april 2008 14:19<BR><B>To:</B> = Busser, M;=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> Re: [ANCP] = Mandatory TLVs=20 in draft-ietf-ancp-protocol proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D709295811-24042008><FONT = face=3DArial=20 size=3D2>Hi Michael,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D709295811-24042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D709295811-24042008><FONT = face=3DArial=20 size=3D2>inline...</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>Busser, = M<BR><B>Sent:</B>=20 24 April 2008 13:13<BR><B>To:</B> ancp@ietf.org<BR><B>Cc:</B> Haag,=20 T<BR><B>Subject:</B> Re: [ANCP] Mandatory TLVs in = draft-ietf-ancp-protocol=20 proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>Hi = Woi,=20 all</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>I = see the problem=20 but i can not see, how an additional flag will help solving this=20 problem.</FONT></SPAN></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>Lets = assume your=20 first proposal.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2>If an=20 implementation does not send the complete TLV, even it is = defined to=20 be mandatory, I would call this a bug and I can not = see, how an=20 additional flag can help here.<SPAN=20 class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Woj> The way it helps, and other = protocols bear=20 proof of this scheme, is that it is easier for implementations to = reconcile=20 errors resulting out of "Mandatory" and "Optional" TLV sets. The = key to=20 this lies on a per application basis. One application may mandate TLV = A for=20 operation, while another might not. Resolving such issues when = implementing or=20 troubleshooting multiple applications is not always trivial.=20 </SPAN></FONT></FONT></SPAN><SPAN class=3D364043506-24042008><FONT=20 face=3DArial><FONT size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>Your = second=20 proposal seems obviously be required to keep existing things = working, if=20 we agree on your first proposal. </FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>But = from my point=20 of view it also assumes, that all existing implementations are = using the=20 same set of TLVs now. </FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2>And I=20 am not sure about that. <SPAN=20 class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Woj> This would be a good thing for the = WG to=20 discuss. There most evidently is a fair amount of "dead wood" in = the=20 current spec, ie stuff that nobody yet implements or cares about. =  In the former case, we could re-cast that material using the new = notions/extensions, in the latter case simply chop it=20 out.</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2><SPAN=20 class=3D364043506-24042008><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV></FONT></SPAN> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2>Therefore I=20 disagree with your first proposal. I recommend, the better = way will be to=20 be more precise in definitions.<SPAN=20 class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>In = my mind, it is=20 a bug, if a mandatory TLV is missing. It is up to the robustness of = the=20 implementation to deal with this situation.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2>Is it really=20 neccesary to define the behavior of a network element in this case of = failure=20 in the ancp protocol itself? <SPAN=20 class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Woj> Other people have faced this = problem before,=20 and I would rather go with the lessons they learned, rather than = clinging to=20 hopes of perfect textual definitions and implementations. Other than = backwards=20 compatibility, I do not see in your statements a valid reason to = object=20 to the 1st proposal, particularly for new applications since it = can only=20 make things more robust. The counter argument of being precise in the=20 definitions, as evidenced by the current spec, is admirable and needs = to be=20 there, with this proposal providing an extra level of robustness and=20 visibility of any problems. </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Thanks,</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Woj.</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>If = optional TLVs=20 are not present in a message, we should describe some kind of default=20 behaviour, as you already stated.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Comments on=20 = draft-ietf-ancp-protocol-02.txt:</FONT></SPAN></DIV></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT = face=3DArial>It is not=20 clearly stated, if the TLV  "<SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA">DSL=20 Line Attributes "<FONT face=3DArial> is mandatory or optional.=20 </FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT = face=3DArial><SPAN=20 lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>In fact it is mandatory because some of its SubTLVs are = mandatory.=20 </FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT = face=3DArial><SPAN=20 lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>We should spent a sentence to make this=20 clear.</FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2><SPAN=20 class=3D364043506-24042008><FONT size=3D2><FONT face=3DArial>It is not = clearly=20 stated, if the TLV  "<SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: = AR-SA">Service-Profile-Name"<FONT=20 face=3DArial> is mandatory or=20 optional.</FONT></SPAN></FONT></FONT></SPAN></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2><SPAN=20 class=3D364043506-24042008><FONT size=3D2><FONT face=3DArial><SPAN = lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>I prefer mandatory because it is essetial for the use = case Line=20 = Config. </FONT></SPAN></FONT></FONT></SPAN></DIV></FONT></SPAN><SPAN= =20 class=3D364043506-24042008><FONT face=3DArial size=3D2></FONT></SPAN> <DIV><SPAN class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008><FONT face=3DArial = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Section 5.4.3 Line=20 Config, where the TLVs are mentioned (page 35):</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>  ...defined=20 in section 5.4.1....    must be corrected = to   =20 ...defined in section 5.4.2........</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Section=20 5.4.4 OAM, where the TLVs are mentioned (page 36 and page=20 38):</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>  ...defined=20 in section 5.4.1....    must be corrected = to   =20 ...defined in section 5.4.2........</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV></FONT></SPAN><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2></FONT></SPAN> </DIV></DIV> <DIV><SPAN class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN = class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN = class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV align=3Dleft><FONT color=3D#000080 size=3D2> <P align=3Dleft>Best Regards; Freundliche Gr=FC=DFe = </P></FONT><B><FONT=20 color=3D#000080> <P>Michael Busser</P></B></FONT><FONT size=3D1> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt">T-Systems=20 Enterprise Services GmbH </SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1>Production Line Network Centric Systems</FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1>ICT-Systems Integration</FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1>Network Integration Services</FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1></FONT><SPAN style=3D"COLOR: navy"></SPAN><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy"><FONT face=3DArial = color=3D#000000=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy"><FONT color=3D#000000 = size=3D1>Br=FCckes 2 -8,=20 55545 Bad Kreuznach<BR>Postfach 9100, 55541 Bad Kreuznach<BR>+49 671 = 8333 8911=20 (Phone)<BR>+49 521 9210 3859 (Fax)<BR>+49 151 1211 9689 = (Mobile)<BR>E-Mail: <A=20 = href=3D"mailto:michael.busser@t-systems.com">michael.busser@t-systems.com= </A></FONT></SPAN></DIV></SPAN> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN></DIV><SPAN style=3D"FONT-SIZE: = 8pt">Internet:=20 </SPAN><SPAN style=3D"FONT-SIZE: 8pt"><p:onmouseclick=20 href=3D"http://www.t-systems.com/" = hyperlinktype=3D"url"></p:onmouseclick><A=20 onclick=3Dwindow.event.cancelBubble=3Dtrue; = href=3D"http://www.t-systems.com/"=20 target=3D_parent><FONT=20 color=3D#6699ff>http://www.t-systems.com</FONT></A></SPAN><SPAN=20 style=3D"FONT-SIZE: 8pt"> </SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN> </DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D3><FONT size=3D1><SPAN=20 style=3D"FONT-SIZE: 7.5pt; COLOR: black; FONT-FAMILY: Arial">T-Systems = Enterprise Services GmbH<BR>Aufsichtsrat: Ren=E9 Obermann=20 (Vorsitzender)<BR>Executive Committee: Reinhard Clemens = (Vorsitzender)*,=20 Helmut Binder, Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich = Kemp,=20 Wilfried Peters*,<BR>Dr. Herbert Schaaff*, Zvezdana=20 Seeger*<BR>Handelsregister: Amtsgericht Frankfurt am Main HRB = 55933<BR>Sitz=20 der Gesellschaft: Frankfurt am Main<BR>WEEE-Reg.-Nr.=20 DE87523644<BR>*Gesch=E4ftsf=FChrer gem. =A7 35=20 GmbHG</SPAN></FONT></FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT face=3DArial=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT size=3D1>Notice: This transmittal = and/or=20 attachments may be privileged or confidential. If you are not the = intended=20 recipient, you are hereby notified that you have received this = transmittal in=20 error; any review, dissemination, or copying is strictly prohibited. = If you=20 received this transmittal in error, please notify us immediately by = reply and=20 immediately delete this message and all its attachments. Thank you.=20 </FONT><FONT size=3D1><BR>T-Systems =96 Business flexibility=20 </FONT></DIV></SPAN></SPAN> <DIV><FONT face=3DArial size=3D2></FONT> </DIV></FONT></DIV> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"> <DIV></DIV> <DIV class=3DOutlookMessageHeader lang=3Dde dir=3Dltr align=3Dleft> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: = Arial"><o:p></o:p></SPAN></FONT></P><FONT=20 face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: = 12pt"><FONT face=3DArial=20 size=3D2></FONT> <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2> </SPAN></FONT></DIV> <DIV class=3DSection1> <DIV> <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: = Tahoma">Von:</SPAN></FONT></B><FONT=20 face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Tahoma">=20 ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] <B><SPAN=20 style=3D"FONT-WEIGHT: bold">Im Auftrag von </SPAN></B>Wojciech Dec=20 (wdec)<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Gesendet:</SPAN></B> = Mittwoch,=20 23. April 2008 14:54<BR><B><SPAN style=3D"FONT-WEIGHT: = bold">An:</SPAN></B>=20 ancp@ietf.org<BR><B><SPAN style=3D"FONT-WEIGHT: = bold">Betreff:</SPAN></B>=20 [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol=20 proposal</SPAN></FONT><o:p></o:p></P></DIV> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi = All,</SPAN></FONT><SPAN=20 lang=3DEN-GB> </SPAN><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Continuing with the = series of=20 e-mails regarding basic protocol issues still to be addressed, I now = would=20 now like to ask your feedback regarding the distinction the protocol = places=20 on mandatory TLVs. Given the length of this mail I'll first cut to = the=20 proposal, and after it you can find the problem=20 description.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The proposal which I = am putting=20 in front of the WG is to define a new TLV format which contains at a = minimum=20 a Mandatory flag (much like Radius VSAs do). We could have this TLV = Flag be=20 defined only for new applications.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">A second proposal = would be try=20 to make this flag work with existing ones by for example defining = the=20 highest order bit of the TLV# field to mean "Mandatory" when set to = "0".=20 This would be invisible to exiting implementations, but newer ones = may have=20 problems in communicating with older ones when the latter do not = send all=20 TLVs. But that can also be addressed by simply forming the set of = mandatory=20 TLVs to be the ones that all implementations currently send by=20 default.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Without additional = feedback, I=20 will assume that the WG is fine with the first proposal, and also = with the=20 2nd one conditional on deriving a suitable "commonly used" TLV=20 set.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The problem in more = detail:=20 </SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Currently the = situation is that=20 Mandatory TLVs are only stated to be as such in the body of the = protocol=20 draft spec, with an implementer having to scour fairly attentively = the text.=20 Eg "Type (Access-Loop-Circuit-ID =3D 0x01): This is a mandatory = TLV",=20 etc.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The behaviour of an=20 implementation that receives a message with a missing mandatory TLV = is not=20 defined at all, and the opposite is handled but not very robustly, = i.e. when=20 receiving a TLV but not recognizing it, and implementation is free = to=20 discard it (even if it is mandatory!). This is a recipe for = interoperability=20 problems and an implementation mine = field.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">This problem is = complicated by=20 different applications. For example the current OAM section states = the=20 following regarding TLVs that are to be carried in the request = message (my=20 italics):</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">"</SPAN></FONT> = <BR><FONT=20 face=3D"Courier New" color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">Following=20 TLVs<B><I><SPAN style=3D"FONT-WEIGHT: bold; FONT-STYLE: italic">=20 can</SPAN></I></B> appear in this message: = </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section=20 5.4.1    </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (Access-Aggregation-Circuit-ID-Binary =3D 0x06): defined in=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 section 5.4.1. </SPAN></FONT><BR><FONT face=3D"Courier New" = color=3Dblack=20 size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'"> </SPAN></FONT>=20 <BR><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03): defined in = section=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 5.4.1.  </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (OAM-Loopback-Test-Parameters =3D 0x07): Parameters related = to =20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 loopback test. This is an optional TLV. If this TLV is not present=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 in the request message, the DSLAM SHOULD use locally determined=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 default values for the test parameters.  = </SPAN></FONT><BR><FONT=20 face=3D"Courier New" color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">"</SPAN></FONT>=20 <BR><FONT face=3DArial color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">(NOTE: = The last=20 "SHOULD" appears to be inappropriate. If the TLV is missing, the = DSLAM MUST=20 have some default parameters, or return an=20 error)</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">The = "can" above=20 indicates that they're all optional, while clearly the application = cannot=20 run its course without one or more of these fields. Here we have a = case=20 where one could have a perfectly compliant implementation that = ignores all=20 these TLVs=85</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = Arial">-Woj.</SPAN></FONT><SPAN=20 lang=3DEN-US> </SPAN><o:p></o:p></P> <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><FONT = face=3D"Times New Roman"=20 size=3D3><SPAN=20 style=3D"FONT-SIZE: = 12pt"><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><o:p></o:p></SPAN></FONT></= P></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C8A938.A914A6E0-- --===============2134997131== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============2134997131==-- From ancp-bounces@ietf.org Mon Apr 28 07:28:27 2008 Return-Path: <ancp-bounces@ietf.org> X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2313E3A6CC6; Mon, 28 Apr 2008 07:28:27 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E67F3A6C46 for <ancp@core3.amsl.com>; Mon, 28 Apr 2008 07:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.298 X-Spam-Level: X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OS7gDBPpBBA0 for <ancp@core3.amsl.com>; Mon, 28 Apr 2008 07:28:23 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2D3DD3A67AE for <ancp@ietf.org>; Mon, 28 Apr 2008 07:28:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,716,1199660400"; d="scan'208,217";a="7525346" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 28 Apr 2008 16:28:24 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3SESO1o018957; Mon, 28 Apr 2008 16:28:24 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3SESODs011532; Mon, 28 Apr 2008 14:28:24 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Apr 2008 16:28:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Apr 2008 16:28:16 +0200 Message-ID: <D9872168DBD43A41BD71FFC4713274D404FF10C1@xmb-ams-33b.emea.cisco.com> In-Reply-To: <7A6D4815C5E8F74988784FEBD50F2F1E01ABAA16@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal thread-index: AcilQRMfK4kdawUKQOWs5fdBngS8QQAAr04QACRhApAAC0ujAADNHRywAADiEXA= References: <1B6169C658325341A3B8066E23919E1C01230DC1@S4DE8PSAANK.mitte.t-com.de><1B6169C658325341A3B8066E23919E1CFBC5C4@S4DE8PSAANK.mitte.t-com.de><D9872168DBD43A41BD71FFC4713274D404FA6ACC@xmb-ams-33b.emea.cisco.com> <7A6D4815C5E8F74988784FEBD50F2F1E01ABAA16@FRVELSMBS22.ad2.ad.alcatel.com> From: "Wojciech Dec (wdec)" <wdec@cisco.com> To: "DE CNODDER Stefaan" <stefaan.de_cnodder@alcatel-lucent.be>, "Busser, M" <Michael.Busser@t-systems.com>, <ancp@ietf.org> X-OriginalArrivalTime: 28 Apr 2008 14:28:24.0316 (UTC) FILETIME=[1DCCEBC0:01C8A93C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=51298; t=1209392904; x=1210256904; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20<wdec@cisco.com> |Subject:=20RE=3A=20[ANCP]=20Mandatory=20TLVs=20in=20draft- ietf-ancp-protocol=20proposal |Sender:=20; bh=7SApJbXj7WF4Jq5rVYbSAMy4bvZpqE4pgPzs8nSvI3I=; b=b+G01lGaMMHsL8qcFl9QxOMk5hVaODRASKdn2VjURstNde+yG9XcN3nOyf leDmggPXlgNXiivv/vN0cHXGMJ8Jp5j5JTQsgpyvISFl7PedYtBU3YJSX837 3PASOS4DAu; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: "Haag, T" <Thomas.Haag@t-systems.com> Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list <ancp.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/ancp> List-Post: <mailto:ancp@ietf.org> List-Help: <mailto:ancp-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0829159406==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0829159406== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A93C.1BD2AB97" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A93C.1BD2AB97 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It's actually a mix of both. Inline... ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = DE CNODDER Stefaan Sent: 28 April 2008 16:04 To: Wojciech Dec (wdec); Busser, M; ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal =09 =09 =20 Hi, =20 This new mandatory flag, what is exactly its meaning? =20 (1) if flag set to "mandatory", then the *receiver* of this TLV MUST = process it, and if unrecognized must drop the message=20 =20 If a received TLV is has the "mandatory" flag set then the receiver = MUST drop the message and report an error to the sender if it doesn't = recognize the TLV.=20 If a the receiver expects a "mandatory" TLV but doesn't receive it, the = message MUST be droped and an error report sent to the sender.=20 =20 OR =20 (2) if flag is set to"mandatory", then the *sender* MUST include it in = the message for which it is defined=20 =20 The sender MUST include mandatory TLVs as defined by the = protocol-spec/applications. =20 The current protocols draft says for certain TLVs that they are = mandatory, but that applies to the sender of it (interpretation 2). The = flag would indicate interpretation 1 (like for Radius VSAs?)? =20 If the higher order bit is set to "0" means that it is mandatory, then = currently defined optional defined TLVs suddenly become mandatory which = is not good.=20 =20 Woj> Only the currently used TLVs become mandatory. If they are not = used/implemented we can re-define them as optional (set flag to 1) at no = cost.=20 =20 But I would first to understand the exact meaning of this mandatory = flag. Defining such a flag indeed looks useful but then as = interpretation 1, and I would say that if flag set to 1, then it is = mandatory and actually, it is possible that a TLV is sent sometimes as = optional and sometimes as mandatory.=20 =20 Woj> Precisely, that is possible on a per application basis. Having the = flag would make troubleshooting of a message flow much more explicit = (today, with any problem one has to browse the drafts to figure out what = MUST be there vs what SHOULD be there all while looking what is actually = there) =20 Regards, Woj. =20 regards, Stefaan =20 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = Wojciech Dec (wdec) Sent: donderdag 24 april 2008 14:19 To: Busser, M; ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal =09 =09 Hi Michael, =20 inline... ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = Of Busser, M Sent: 24 April 2008 13:13 To: ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 Hi Woi, all =20 I see the problem but i can not see, how an additional flag will help = solving this problem. =20 Lets assume your first proposal. If an implementation does not send the complete TLV, even it is = defined to be mandatory, I would call this a bug and I can not see, how = an additional flag can help here.=20 =20 Woj> The way it helps, and other protocols bear proof of this scheme, = is that it is easier for implementations to reconcile errors resulting = out of "Mandatory" and "Optional" TLV sets. The key to this lies on a = per application basis. One application may mandate TLV A for operation, = while another might not. Resolving such issues when implementing or = troubleshooting multiple applications is not always trivial.=20 =20 Your second proposal seems obviously be required to keep existing = things working, if we agree on your first proposal.=20 But from my point of view it also assumes, that all existing = implementations are using the same set of TLVs now.=20 And I am not sure about that. =20 =20 Woj> This would be a good thing for the WG to discuss. There most = evidently is a fair amount of "dead wood" in the current spec, ie stuff = that nobody yet implements or cares about. In the former case, we could = re-cast that material using the new notions/extensions, in the latter = case simply chop it out. =20 Therefore I disagree with your first proposal. I recommend, the better = way will be to be more precise in definitions.=20 In my mind, it is a bug, if a mandatory TLV is missing. It is up to = the robustness of the implementation to deal with this situation. Is it really neccesary to define the behavior of a network element in = this case of failure in the ancp protocol itself? =20 =20 Woj> Other people have faced this problem before, and I would rather = go with the lessons they learned, rather than clinging to hopes of = perfect textual definitions and implementations. Other than backwards = compatibility, I do not see in your statements a valid reason to object = to the 1st proposal, particularly for new applications since it can only = make things more robust. The counter argument of being precise in the = definitions, as evidenced by the current spec, is admirable and needs to = be there, with this proposal providing an extra level of robustness and = visibility of any problems.=20 =20 Thanks, Woj. =20 If optional TLVs are not present in a message, we should describe some = kind of default behaviour, as you already stated. =20 =20 =20 =20 =09 Comments on draft-ietf-ancp-protocol-02.txt: =20 It is not clearly stated, if the TLV "DSL Line Attributes " is = mandatory or optional.=20 In fact it is mandatory because some of its SubTLVs are mandatory.=20 We should spent a sentence to make this clear. =20 It is not clearly stated, if the TLV "Service-Profile-Name" is = mandatory or optional. I prefer mandatory because it is essetial for the use case Line = Config.=20 =09 =20 Section 5.4.3 Line Config, where the TLVs are mentioned (page 35): ...defined in section 5.4.1.... must be corrected to = ...defined in section 5.4.2........ =20 =09 Section 5.4.4 OAM, where the TLVs are mentioned (page 36 and page 38): ...defined in section 5.4.1.... must be corrected to = ...defined in section 5.4.2........ =20 =20 =20 =20 Best Regards; Freundliche Gr=FC=DFe=20 Michael Busser =09 T-Systems Enterprise Services GmbH=20 Production Line Network Centric Systems ICT-Systems Integration Network Integration Services =20 Br=FCckes 2 -8, 55545 Bad Kreuznach Postfach 9100, 55541 Bad Kreuznach +49 671 8333 8911 (Phone) +49 521 9210 3859 (Fax) +49 151 1211 9689 (Mobile) E-Mail: michael.busser@t-systems.com =09 Internet: http://www.t-systems.com <http://www.t-systems.com/> =20 =09 =20 T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Reinhard Clemens (Vorsitzender)*, Helmut Binder, = Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Wilfried = Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG =20 Notice: This transmittal and/or attachments may be privileged or = confidential. If you are not the intended recipient, you are hereby = notified that you have received this transmittal in error; any review, = dissemination, or copying is strictly prohibited. If you received this = transmittal in error, please notify us immediately by reply and = immediately delete this message and all its attachments. Thank you.=20 T-Systems - Business flexibility=20 =20 =09 =09 ________________________________ Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag = von Wojciech Dec (wdec) Gesendet: Mittwoch, 23. April 2008 14:54 An: ancp@ietf.org Betreff: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal =20 Hi All,=20 Continuing with the series of e-mails regarding basic protocol issues = still to be addressed, I now would now like to ask your feedback = regarding the distinction the protocol places on mandatory TLVs. Given = the length of this mail I'll first cut to the proposal, and after it you = can find the problem description. The proposal which I am putting in front of the WG is to define a new = TLV format which contains at a minimum a Mandatory flag (much like = Radius VSAs do). We could have this TLV Flag be defined only for new = applications. A second proposal would be try to make this flag work with existing = ones by for example defining the highest order bit of the TLV# field to = mean "Mandatory" when set to "0". This would be invisible to exiting = implementations, but newer ones may have problems in communicating with = older ones when the latter do not send all TLVs. But that can also be = addressed by simply forming the set of mandatory TLVs to be the ones = that all implementations currently send by default. Without additional feedback, I will assume that the WG is fine with = the first proposal, and also with the 2nd one conditional on deriving a = suitable "commonly used" TLV set. The problem in more detail:=20 Currently the situation is that Mandatory TLVs are only stated to be = as such in the body of the protocol draft spec, with an implementer = having to scour fairly attentively the text. Eg "Type = (Access-Loop-Circuit-ID =3D 0x01): This is a mandatory TLV", etc. The behaviour of an implementation that receives a message with a = missing mandatory TLV is not defined at all, and the opposite is handled = but not very robustly, i.e. when receiving a TLV but not recognizing it, = and implementation is free to discard it (even if it is mandatory!). = This is a recipe for interoperability problems and an implementation = mine field. This problem is complicated by different applications. For example = the current OAM section states the following regarding TLVs that are to = be carried in the request message (my italics): "=20 Following TLVs can appear in this message:=20 o Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section = 5.4.1 =20 o Type (Access-Aggregation-Circuit-ID-Binary =3D 0x06): = defined in=20 section 5.4.1.=20 =20 o Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03): defined = in section=20 5.4.1. =20 o Type (OAM-Loopback-Test-Parameters =3D 0x07): Parameters = related to =20 loopback test. This is an optional TLV. If this TLV is not = present=20 in the request message, the DSLAM SHOULD use locally = determined=20 default values for the test parameters. =20 "=20 (NOTE: The last "SHOULD" appears to be inappropriate. If the TLV is = missing, the DSLAM MUST have some default parameters, or return an = error) The "can" above indicates that they're all optional, while clearly = the application cannot run its course without one or more of these = fields. Here we have a case where one could have a perfectly compliant = implementation that ignores all these TLVs... -Woj.=20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 ------_=_NextPart_001_01C8A93C.1BD2AB97 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns:v =3D "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word" xmlns:p =3D=20 "urn:schemas-microsoft-com:office:powerpoint"><HEAD><TITLE>Nachricht</TIT= LE> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2900.3314" name=3DGENERATOR><!--[if !mso]> <STYLE>v\:* { BEHAVIOR: url(#default#VML) } o\:* { BEHAVIOR: url(#default#VML) } w\:* { BEHAVIOR: url(#default#VML) } .shape { BEHAVIOR: url(#default#VML) } </STYLE> <![endif]--> <STYLE>@font-face { font-family: Tahoma; } @page Section1 {size: 595.3pt 841.9pt; margin: 70.85pt 70.85pt 2.0cm = 70.85pt; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline } A:visited { COLOR: purple; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline } P { FONT-SIZE: 12pt; MARGIN-LEFT: 0cm; MARGIN-RIGHT: 0cm; FONT-FAMILY: = "Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto } SPAN.E-MailFormatvorlage18 { COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply } DIV.Section1 { page: Section1 } </STYLE> </HEAD> <BODY lang=3DDE vLink=3Dpurple link=3Dblue> <DIV dir=3Dltr align=3Dleft><SPAN class=3D560491614-28042008><FONT = face=3DArial=20 size=3D2>It's actually a mix of both. Inline...</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>DE CNODDER=20 Stefaan<BR><B>Sent:</B> 28 April 2008 16:04<BR><B>To:</B> Wojciech Dec = (wdec);=20 Busser, M; ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> Re: = [ANCP]=20 Mandatory TLVs in draft-ietf-ancp-protocol = proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Hi,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>This new mandatory flag, what is exactly its=20 meaning?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>(1) if flag set = to=20 "mandatory", then the *receiver* of this TLV MUST process it, and if=20 unrecognized must drop the message<SPAN = class=3D560491614-28042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>If a received TLV is = has=20 the "mandatory" flag set then the receiver MUST drop the = message and=20 report an error to the sender if it doesn't recognize the=20 TLV.</FONT> </SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>If a the receiver = expects=20 a "mandatory" TLV but doesn't receive it, the message MUST=20 be droped and an error report sent to=20 = the sender.</FONT> </SPAN></FONT></FONT></FONT></SPAN></SPAN></= FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>OR</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>(2) if flag is = set=20 to"mandatory", then the *sender* MUST include it in the message for = which it=20 is defined<SPAN class=3D560491614-28042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>The sender MUST = include mandatory=20 TLVs as defined by the=20 = protocol-spec/applications.</FONT></SPAN></FONT></FONT></FONT></SPAN></DI= V> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>The current protocols draft says for certain = TLVs that=20 they are mandatory, but that applies to the sender of it = (interpretation=20 2).  The flag would indicate interpretation 1 (like for Radius=20 VSAs?)?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>If the higher order = bit is set to=20 "0" means that it is mandatory, then currently defined optional = defined TLVs=20 suddenly become mandatory which is not good.<SPAN=20 class=3D560491614-28042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>Woj> Only the = currently used=20 TLVs become mandatory. If they are not used/implemented we can = re-define=20 them as optional (set flag to 1) at no cost.=20 </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>But I would first to = understand=20 the exact meaning of this mandatory flag.  Defining such a flag = indeed=20 looks useful but then as interpretation 1, and I would say that if = flag set to=20 1, then it is mandatory and actually, it is possible that a TLV is = sent=20 sometimes as optional and sometimes as mandatory.<SPAN=20 class=3D560491614-28042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>Woj> Precisely, = that is=20 possible on a per application basis.</FONT> <FONT = color=3D#000000>Having=20 the flag would make troubleshooting of a message flow much more = explicit=20 (today, with any problem one has to browse the drafts to figure = out what=20 MUST be there vs what SHOULD be there all while looking what = is=20 actually there)</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 = size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 = size=3D2><SPAN=20 = class=3D560491614-28042008>Regards,</SPAN></FONT></FONT></FONT></SPAN></D= IV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 = size=3D2><SPAN=20 = class=3D560491614-28042008>Woj.</SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 = size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Stefaan</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT> </DIV><BR> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>Wojciech Dec=20 (wdec)<BR><B>Sent:</B> donderdag 24 april 2008 14:19<BR><B>To:</B> = Busser, M;=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> Re: [ANCP] = Mandatory=20 TLVs in draft-ietf-ancp-protocol proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D709295811-24042008><FONT = face=3DArial=20 size=3D2>Hi Michael,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D709295811-24042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D709295811-24042008><FONT = face=3DArial=20 size=3D2>inline...</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>Busser, = M<BR><B>Sent:</B>=20 24 April 2008 13:13<BR><B>To:</B> ancp@ietf.org<BR><B>Cc:</B> Haag,=20 T<BR><B>Subject:</B> Re: [ANCP] Mandatory TLVs in = draft-ietf-ancp-protocol=20 proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>Hi = Woi,=20 all</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>I = see the=20 problem but i can not see, how an additional flag will help solving = this=20 problem.</FONT></SPAN></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Lets assume your=20 first proposal.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2>If an=20 implementation does not send the complete TLV, even it is=20 defined to be mandatory, I would call this a bug = and I=20 can not see, how an additional flag can help here.<SPAN=20 class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Woj> The way it helps, and other = protocols bear=20 proof of this scheme, is that it is easier for implementations to = reconcile=20 errors resulting out of "Mandatory" and "Optional" TLV sets. = The key to=20 this lies on a per application basis. One application may mandate = TLV A for=20 operation, while another might not. Resolving such issues when = implementing=20 or troubleshooting multiple applications is not always trivial.=20 </SPAN></FONT></FONT></SPAN><SPAN class=3D364043506-24042008><FONT=20 face=3DArial><FONT size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Your second=20 proposal seems obviously be required to keep existing things = working,=20 if we agree on your first proposal. </FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>But from my=20 point of view it also assumes, that all existing = implementations are=20 using the same set of TLVs now. </FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2>And I=20 am not sure about that. <SPAN=20 class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Woj> This would be a good thing for = the WG to=20 discuss. There most evidently is a fair amount of "dead wood" = in the=20 current spec, ie stuff that nobody yet implements or cares = about.=20  In the former case, we could re-cast that material using the = new=20 notions/extensions, in the latter case simply chop it=20 out.</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2><SPAN=20 class=3D364043506-24042008><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV></FONT></SPAN> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2>Therefore=20 I disagree with your first proposal. I recommend, the better = way will=20 be to be more precise in definitions.<SPAN=20 class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>In = my mind, it=20 is a bug, if a mandatory TLV is missing. It is up to the robustness = of the=20 implementation to deal with this situation.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2>Is it=20 really neccesary to define the behavior of a network element in this = case of=20 failure in the ancp protocol itself? <SPAN=20 class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Woj> Other people have faced this = problem=20 before, and I would rather go with the lessons they learned, rather = than=20 clinging to hopes of perfect textual definitions and = implementations. Other=20 than backwards compatibility, I do not see in your statements a = valid=20 reason to object to the 1st proposal, particularly for new = applications since it can only make things more robust. The counter = argument=20 of being precise in the definitions, as evidenced by the current = spec, is=20 admirable and needs to be there, with this proposal providing an = extra level=20 of robustness and visibility of any problems.=20 </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Thanks,</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Woj.</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>If = optional TLVs=20 are not present in a message, we should describe some kind of = default=20 behaviour, as you already stated.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Comments on=20 = draft-ietf-ancp-protocol-02.txt:</FONT></SPAN></DIV></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT = face=3DArial>It is not=20 clearly stated, if the TLV  "<SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA">DSL=20 Line Attributes "<FONT face=3DArial> is mandatory or optional.=20 </FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT = face=3DArial><SPAN=20 lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>In fact it is mandatory because some of its SubTLVs are = mandatory. </FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT = face=3DArial><SPAN=20 lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>We should spent a sentence to make this=20 clear.</FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2><SPAN=20 class=3D364043506-24042008><FONT size=3D2><FONT face=3DArial>It is = not clearly=20 stated, if the TLV  "<SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: = AR-SA">Service-Profile-Name"<FONT=20 face=3DArial> is mandatory or=20 optional.</FONT></SPAN></FONT></FONT></SPAN></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2><SPAN=20 class=3D364043506-24042008><FONT size=3D2><FONT face=3DArial><SPAN = lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>I prefer mandatory because it is essetial for the use = case Line=20 = Config. </FONT></SPAN></FONT></FONT></SPAN></DIV></FONT></SPAN><SPAN= =20 class=3D364043506-24042008><FONT face=3DArial = size=3D2></FONT></SPAN> <DIV><SPAN class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008><FONT face=3DArial = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Section 5.4.3=20 Line Config, where the TLVs are mentioned (page = 35):</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2> =20 ...defined in section 5.4.1....    must be corrected=20 to    ...defined in section = 5.4.2........</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Section=20 5.4.4 OAM, where the TLVs are mentioned (page 36 and page=20 38):</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2> =20 ...defined in section 5.4.1....    must be corrected=20 to    ...defined in section = 5.4.2........</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV></FONT></SPAN><SPAN class=3D364043506-24042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV></DIV> <DIV><SPAN class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN = class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN = class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV align=3Dleft><FONT color=3D#000080 size=3D2> <P align=3Dleft>Best Regards; Freundliche Gr=FC=DFe = </P></FONT><B><FONT=20 color=3D#000080> <P>Michael Busser</P></B></FONT><FONT size=3D1> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt">T-Systems=20 Enterprise Services GmbH </SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1>Production Line Network Centric Systems</FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1>ICT-Systems Integration</FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1>Network Integration Services</FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1></FONT><SPAN style=3D"COLOR: navy"></SPAN><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy"><FONT face=3DArial = color=3D#000000=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy"><FONT color=3D#000000 = size=3D1>Br=FCckes 2=20 -8, 55545 Bad Kreuznach<BR>Postfach 9100, 55541 Bad Kreuznach<BR>+49 = 671=20 8333 8911 (Phone)<BR>+49 521 9210 3859 (Fax)<BR>+49 151=20 1211 9689 (Mobile)<BR>E-Mail: <A=20 = href=3D"mailto:michael.busser@t-systems.com">michael.busser@t-systems.com= </A></FONT></SPAN></DIV></SPAN> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN></DIV><SPAN style=3D"FONT-SIZE: = 8pt">Internet:=20 </SPAN><SPAN style=3D"FONT-SIZE: 8pt"><p:onmouseclick = hyperlinktype=3D"url"=20 href=3D"http://www.t-systems.com/"></p:onmouseclick><A=20 onclick=3Dwindow.event.cancelBubble=3Dtrue; = href=3D"http://www.t-systems.com/"=20 target=3D_parent><FONT=20 color=3D#6699ff>http://www.t-systems.com</FONT></A></SPAN><SPAN=20 style=3D"FONT-SIZE: 8pt"> </SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN> </DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D3><FONT size=3D1><SPAN=20 style=3D"FONT-SIZE: 7.5pt; COLOR: black; FONT-FAMILY: = Arial">T-Systems=20 Enterprise Services GmbH<BR>Aufsichtsrat: Ren=E9 Obermann=20 (Vorsitzender)<BR>Executive Committee: Reinhard Clemens = (Vorsitzender)*,=20 Helmut Binder, Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich = Kemp,=20 Wilfried Peters*,<BR>Dr. Herbert Schaaff*, Zvezdana=20 Seeger*<BR>Handelsregister: Amtsgericht Frankfurt am Main HRB = 55933<BR>Sitz=20 der Gesellschaft: Frankfurt am Main<BR>WEEE-Reg.-Nr.=20 DE87523644<BR>*Gesch=E4ftsf=FChrer gem. =A7 35=20 GmbHG</SPAN></FONT></FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT face=3DArial=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT size=3D1>Notice: This transmittal = and/or=20 attachments may be privileged or confidential. If you are not the = intended=20 recipient, you are hereby notified that you have received this = transmittal=20 in error; any review, dissemination, or copying is strictly = prohibited. If=20 you received this transmittal in error, please notify us immediately = by=20 reply and immediately delete this message and all its attachments. = Thank=20 you. </FONT><FONT size=3D1><BR>T-Systems =96 Business flexibility=20 </FONT></DIV></SPAN></SPAN> <DIV><FONT face=3DArial size=3D2></FONT> </DIV></FONT></DIV> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"> <DIV></DIV> <DIV class=3DOutlookMessageHeader lang=3Dde dir=3Dltr = align=3Dleft> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy = size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: = Arial"><o:p></o:p></SPAN></FONT></P><FONT=20 face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: = 12pt"><FONT=20 face=3DArial size=3D2></FONT> <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2> </SPAN></FONT></DIV> <DIV class=3DSection1> <DIV> <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: = Tahoma">Von:</SPAN></FONT></B><FONT=20 face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; = FONT-FAMILY: Tahoma">=20 ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] <B><SPAN=20 style=3D"FONT-WEIGHT: bold">Im Auftrag von </SPAN></B>Wojciech Dec = (wdec)<BR><B><SPAN style=3D"FONT-WEIGHT: = bold">Gesendet:</SPAN></B>=20 Mittwoch, 23. April 2008 14:54<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">An:</SPAN></B> = ancp@ietf.org<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Betreff:</SPAN></B> [ANCP] Mandatory = TLVs in=20 draft-ietf-ancp-protocol = proposal</SPAN></FONT><o:p></o:p></P></DIV> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN = style=3D"FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi = All,</SPAN></FONT><SPAN=20 lang=3DEN-GB> </SPAN><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Continuing with the = series of=20 e-mails regarding basic protocol issues still to be addressed, I = now would=20 now like to ask your feedback regarding the distinction the = protocol=20 places on mandatory TLVs. Given the length of this mail I'll first = cut to=20 the proposal, and after it you can find the problem=20 description.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The proposal which I = am=20 putting in front of the WG is to define a new TLV format which = contains at=20 a minimum a Mandatory flag (much like Radius VSAs do). We could = have this=20 TLV Flag be defined only for new=20 applications.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">A second proposal = would be try=20 to make this flag work with existing ones by for example defining = the=20 highest order bit of the TLV# field to mean "Mandatory" when set = to "0".=20 This would be invisible to exiting implementations, but newer ones = may=20 have problems in communicating with older ones when the latter do = not send=20 all TLVs. But that can also be addressed by simply forming the set = of=20 mandatory TLVs to be the ones that all implementations currently = send by=20 default.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Without additional = feedback, I=20 will assume that the WG is fine with the first proposal, and also = with the=20 2nd one conditional on deriving a suitable "commonly used" TLV=20 set.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The problem in more = detail:=20 </SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Currently the = situation is=20 that Mandatory TLVs are only stated to be as such in the body of = the=20 protocol draft spec, with an implementer having to scour fairly=20 attentively the text. Eg "Type (Access-Loop-Circuit-ID =3D 0x01): = This is a=20 mandatory TLV", etc.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The behaviour of an=20 implementation that receives a message with a missing mandatory = TLV is not=20 defined at all, and the opposite is handled but not very robustly, = i.e.=20 when receiving a TLV but not recognizing it, and implementation is = free to=20 discard it (even if it is mandatory!). This is a recipe for=20 interoperability problems and an implementation mine=20 field.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">This problem is = complicated by=20 different applications. For example the current OAM section states = the=20 following regarding TLVs that are to be carried in the request = message (my=20 italics):</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">"</SPAN></FONT> = <BR><FONT=20 face=3D"Courier New" color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">Following=20 TLVs<B><I><SPAN style=3D"FONT-WEIGHT: bold; FONT-STYLE: italic">=20 can</SPAN></I></B> appear in this message: = </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section=20 5.4.1    </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (Access-Aggregation-Circuit-ID-Binary =3D 0x06): defined in = </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 section 5.4.1. </SPAN></FONT><BR><FONT face=3D"Courier New" = color=3Dblack=20 size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'"> </SPAN></FONT>=20 <BR><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03): defined in = section=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 5.4.1.  </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (OAM-Loopback-Test-Parameters =3D 0x07): Parameters related = to =20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 loopback test. This is an optional TLV. If this TLV is not present = </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 in the request message, the DSLAM SHOULD use locally determined=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 default values for the test parameters.  = </SPAN></FONT><BR><FONT=20 face=3D"Courier New" color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">"</SPAN></FONT>=20 <BR><FONT face=3DArial color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">(NOTE: = The last=20 "SHOULD" appears to be inappropriate. If the TLV is missing, the = DSLAM=20 MUST have some default parameters, or return an=20 error)</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">The = "can" above=20 indicates that they're all optional, while clearly the application = cannot=20 run its course without one or more of these fields. Here we have a = case=20 where one could have a perfectly compliant implementation that = ignores all=20 these TLVs=85</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = Arial">-Woj.</SPAN></FONT><SPAN=20 lang=3DEN-US> </SPAN><o:p></o:p></P> <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><FONT=20 face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: = 12pt"><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><o:p></o:p></SPAN></FONT></= P></DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C8A93C.1BD2AB97-- --===============0829159406== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============0829159406==-- From ancp-bounces@ietf.org Mon Apr 28 08:15:00 2008 Return-Path: <ancp-bounces@ietf.org> X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4854B28C2B0; Mon, 28 Apr 2008 08:15:00 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC7AE28C297 for <ancp@core3.amsl.com>; Mon, 28 Apr 2008 08:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.948 X-Spam-Level: X-Spam-Status: No, score=-0.948 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHtZSmGwcIfd for <ancp@core3.amsl.com>; Mon, 28 Apr 2008 08:14:57 -0700 (PDT) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id 8991528C2B8 for <ancp@ietf.org>; Mon, 28 Apr 2008 08:14:54 -0700 (PDT) Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m3SF6clh024839; Mon, 28 Apr 2008 17:06:38 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS07.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 28 Apr 2008 17:14:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Apr 2008 17:14:51 +0200 Message-ID: <7A6D4815C5E8F74988784FEBD50F2F1E01ABAAA4@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <D9872168DBD43A41BD71FFC4713274D404FF10C1@xmb-ams-33b.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal Thread-Index: AcilQRMfK4kdawUKQOWs5fdBngS8QQAAr04QACRhApAAC0ujAADNHRywAADiEXAAAbhxoA== References: <1B6169C658325341A3B8066E23919E1C01230DC1@S4DE8PSAANK.mitte.t-com.de><1B6169C658325341A3B8066E23919E1CFBC5C4@S4DE8PSAANK.mitte.t-com.de><D9872168DBD43A41BD71FFC4713274D404FA6ACC@xmb-ams-33b.emea.cisco.com> <7A6D4815C5E8F74988784FEBD50F2F1E01ABAA16@FRVELSMBS22.ad2.ad.alcatel.com> <D9872168DBD43A41BD71FFC4713274D404FF10C1@xmb-ams-33b.emea.cisco.com> From: "DE CNODDER Stefaan" <stefaan.de_cnodder@alcatel-lucent.be> To: "Wojciech Dec (wdec)" <wdec@cisco.com>, "Busser, M" <Michael.Busser@t-systems.com>, <ancp@ietf.org> X-OriginalArrivalTime: 28 Apr 2008 15:14:53.0437 (UTC) FILETIME=[9C3F02D0:01C8A942] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: "Haag, T" <Thomas.Haag@t-systems.com> Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list <ancp.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/ancp> List-Post: <mailto:ancp@ietf.org> List-Help: <mailto:ancp-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0546723925==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0546723925== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A942.9BE97707" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A942.9BE97707 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Take the bandwidth sub-TLV in port up messages as example. The current = protocol spec says that it is mandatory to be sent in port up messages. = that's ok. But it is not mandatory for the receiver to process the = bandwidth sub-TLV. What is done with this information by the NAS is not = specified by ANCP, so you cannot make it mandatory for the receiver = side. =20 So it looks to me that the flag can only indicate what the receiver = should do. Then the flag makes sense. =20 If the receiver knows what is mandatory, then I do not see a reason why = this has to be made explicit in the protocol. It would only complicate = the protocol. As already said by Michael: if a mandatory TLV is not = there, then it is just a bug. =20 regards, Stefaan =20 =20 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: maandag 28 april 2008 16:28 To: DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal It's actually a mix of both. Inline... ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = DE CNODDER Stefaan Sent: 28 April 2008 16:04 To: Wojciech Dec (wdec); Busser, M; ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal =09 =09 =20 Hi, =20 This new mandatory flag, what is exactly its meaning? =20 (1) if flag set to "mandatory", then the *receiver* of this TLV MUST = process it, and if unrecognized must drop the message=20 =20 If a received TLV is has the "mandatory" flag set then the receiver = MUST drop the message and report an error to the sender if it doesn't = recognize the TLV.=20 If a the receiver expects a "mandatory" TLV but doesn't receive it, the = message MUST be droped and an error report sent to the sender.=20 =20 OR =20 (2) if flag is set to"mandatory", then the *sender* MUST include it in = the message for which it is defined=20 =20 The sender MUST include mandatory TLVs as defined by the = protocol-spec/applications. =20 The current protocols draft says for certain TLVs that they are = mandatory, but that applies to the sender of it (interpretation 2). The = flag would indicate interpretation 1 (like for Radius VSAs?)? =20 If the higher order bit is set to "0" means that it is mandatory, then = currently defined optional defined TLVs suddenly become mandatory which = is not good.=20 =20 Woj> Only the currently used TLVs become mandatory. If they are not = used/implemented we can re-define them as optional (set flag to 1) at no = cost.=20 =20 But I would first to understand the exact meaning of this mandatory = flag. Defining such a flag indeed looks useful but then as = interpretation 1, and I would say that if flag set to 1, then it is = mandatory and actually, it is possible that a TLV is sent sometimes as = optional and sometimes as mandatory.=20 =20 Woj> Precisely, that is possible on a per application basis. Having the = flag would make troubleshooting of a message flow much more explicit = (today, with any problem one has to browse the drafts to figure out what = MUST be there vs what SHOULD be there all while looking what is actually = there) =20 Regards, Woj. =20 regards, Stefaan =20 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = Wojciech Dec (wdec) Sent: donderdag 24 april 2008 14:19 To: Busser, M; ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal =09 =09 Hi Michael, =20 inline... ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = Of Busser, M Sent: 24 April 2008 13:13 To: ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 Hi Woi, all =20 I see the problem but i can not see, how an additional flag will help = solving this problem. =20 Lets assume your first proposal. If an implementation does not send the complete TLV, even it is = defined to be mandatory, I would call this a bug and I can not see, how = an additional flag can help here.=20 =20 Woj> The way it helps, and other protocols bear proof of this scheme, = is that it is easier for implementations to reconcile errors resulting = out of "Mandatory" and "Optional" TLV sets. The key to this lies on a = per application basis. One application may mandate TLV A for operation, = while another might not. Resolving such issues when implementing or = troubleshooting multiple applications is not always trivial.=20 =20 Your second proposal seems obviously be required to keep existing = things working, if we agree on your first proposal.=20 But from my point of view it also assumes, that all existing = implementations are using the same set of TLVs now.=20 And I am not sure about that. =20 =20 Woj> This would be a good thing for the WG to discuss. There most = evidently is a fair amount of "dead wood" in the current spec, ie stuff = that nobody yet implements or cares about. In the former case, we could = re-cast that material using the new notions/extensions, in the latter = case simply chop it out. =20 Therefore I disagree with your first proposal. I recommend, the better = way will be to be more precise in definitions.=20 In my mind, it is a bug, if a mandatory TLV is missing. It is up to = the robustness of the implementation to deal with this situation. Is it really neccesary to define the behavior of a network element in = this case of failure in the ancp protocol itself? =20 =20 Woj> Other people have faced this problem before, and I would rather = go with the lessons they learned, rather than clinging to hopes of = perfect textual definitions and implementations. Other than backwards = compatibility, I do not see in your statements a valid reason to object = to the 1st proposal, particularly for new applications since it can only = make things more robust. The counter argument of being precise in the = definitions, as evidenced by the current spec, is admirable and needs to = be there, with this proposal providing an extra level of robustness and = visibility of any problems.=20 =20 Thanks, Woj. =20 If optional TLVs are not present in a message, we should describe some = kind of default behaviour, as you already stated. =20 =20 =20 =20 =09 Comments on draft-ietf-ancp-protocol-02.txt: =20 It is not clearly stated, if the TLV "DSL Line Attributes " is = mandatory or optional.=20 In fact it is mandatory because some of its SubTLVs are mandatory.=20 We should spent a sentence to make this clear. =20 It is not clearly stated, if the TLV "Service-Profile-Name" is = mandatory or optional. I prefer mandatory because it is essetial for the use case Line = Config.=20 =09 =20 Section 5.4.3 Line Config, where the TLVs are mentioned (page 35): ...defined in section 5.4.1.... must be corrected to = ...defined in section 5.4.2........ =20 =09 Section 5.4.4 OAM, where the TLVs are mentioned (page 36 and page 38): ...defined in section 5.4.1.... must be corrected to = ...defined in section 5.4.2........ =20 =20 =20 =20 Best Regards; Freundliche Gr=FC=DFe=20 Michael Busser =09 T-Systems Enterprise Services GmbH=20 Production Line Network Centric Systems ICT-Systems Integration Network Integration Services =20 Br=FCckes 2 -8, 55545 Bad Kreuznach Postfach 9100, 55541 Bad Kreuznach +49 671 8333 8911 (Phone) +49 521 9210 3859 (Fax) +49 151 1211 9689 (Mobile) E-Mail: michael.busser@t-systems.com =09 Internet: http://www.t-systems.com <http://www.t-systems.com/> =20 =09 =20 T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Reinhard Clemens (Vorsitzender)*, Helmut Binder, = Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Wilfried = Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG =20 Notice: This transmittal and/or attachments may be privileged or = confidential. If you are not the intended recipient, you are hereby = notified that you have received this transmittal in error; any review, = dissemination, or copying is strictly prohibited. If you received this = transmittal in error, please notify us immediately by reply and = immediately delete this message and all its attachments. Thank you.=20 T-Systems - Business flexibility=20 =20 =09 =09 ________________________________ Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag = von Wojciech Dec (wdec) Gesendet: Mittwoch, 23. April 2008 14:54 An: ancp@ietf.org Betreff: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal =20 Hi All,=20 Continuing with the series of e-mails regarding basic protocol issues = still to be addressed, I now would now like to ask your feedback = regarding the distinction the protocol places on mandatory TLVs. Given = the length of this mail I'll first cut to the proposal, and after it you = can find the problem description. The proposal which I am putting in front of the WG is to define a new = TLV format which contains at a minimum a Mandatory flag (much like = Radius VSAs do). We could have this TLV Flag be defined only for new = applications. A second proposal would be try to make this flag work with existing = ones by for example defining the highest order bit of the TLV# field to = mean "Mandatory" when set to "0". This would be invisible to exiting = implementations, but newer ones may have problems in communicating with = older ones when the latter do not send all TLVs. But that can also be = addressed by simply forming the set of mandatory TLVs to be the ones = that all implementations currently send by default. Without additional feedback, I will assume that the WG is fine with = the first proposal, and also with the 2nd one conditional on deriving a = suitable "commonly used" TLV set. The problem in more detail:=20 Currently the situation is that Mandatory TLVs are only stated to be = as such in the body of the protocol draft spec, with an implementer = having to scour fairly attentively the text. Eg "Type = (Access-Loop-Circuit-ID =3D 0x01): This is a mandatory TLV", etc. The behaviour of an implementation that receives a message with a = missing mandatory TLV is not defined at all, and the opposite is handled = but not very robustly, i.e. when receiving a TLV but not recognizing it, = and implementation is free to discard it (even if it is mandatory!). = This is a recipe for interoperability problems and an implementation = mine field. This problem is complicated by different applications. For example = the current OAM section states the following regarding TLVs that are to = be carried in the request message (my italics): "=20 Following TLVs can appear in this message:=20 o Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section = 5.4.1 =20 o Type (Access-Aggregation-Circuit-ID-Binary =3D 0x06): = defined in=20 section 5.4.1.=20 =20 o Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03): defined = in section=20 5.4.1. =20 o Type (OAM-Loopback-Test-Parameters =3D 0x07): Parameters = related to =20 loopback test. This is an optional TLV. If this TLV is not = present=20 in the request message, the DSLAM SHOULD use locally = determined=20 default values for the test parameters. =20 "=20 (NOTE: The last "SHOULD" appears to be inappropriate. If the TLV is = missing, the DSLAM MUST have some default parameters, or return an = error) The "can" above indicates that they're all optional, while clearly = the application cannot run its course without one or more of these = fields. Here we have a case where one could have a perfectly compliant = implementation that ignores all these TLVs... -Woj.=20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 ------_=_NextPart_001_01C8A942.9BE97707 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns:v =3D "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word" xmlns:p =3D=20 "urn:schemas-microsoft-com:office:powerpoint"><HEAD><TITLE>Nachricht</TIT= LE> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2900.3314" name=3DGENERATOR><!--[if !mso]> <STYLE>v\:* { BEHAVIOR: url(#default#VML) } o\:* { BEHAVIOR: url(#default#VML) } w\:* { BEHAVIOR: url(#default#VML) } .shape { BEHAVIOR: url(#default#VML) } </STYLE> <![endif]--> <STYLE>@font-face { font-family: Tahoma; } @page Section1 {size: 595.3pt 841.9pt; margin: 70.85pt 70.85pt 2.0cm = 70.85pt; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline } A:visited { COLOR: purple; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline } P { FONT-SIZE: 12pt; MARGIN-LEFT: 0cm; MARGIN-RIGHT: 0cm; FONT-FAMILY: = "Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto } SPAN.E-MailFormatvorlage18 { COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply } DIV.Section1 { page: Section1 } </STYLE> </HEAD> <BODY lang=3DDE vLink=3Dpurple link=3Dblue> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Take the bandwidth sub-TLV in port up messages = as=20 example.  The current protocol spec says that it is = mandatory to be=20 sent in port up messages.  that's ok.  But it is not mandatory = for the=20 receiver to process the bandwidth sub-TLV.  What is done with this=20 information by the NAS is not specified by ANCP, so you cannot make it = mandatory=20 for the receiver side.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>So it looks to me that the flag can only = indicate what the=20 receiver should do.  Then the flag makes sense.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>If the receiver knows what is mandatory, then I = do not see=20 a reason why this has to be made explicit in the protocol.  It = would only=20 complicate the protocol.  As already said by Michael: if a = mandatory TLV is=20 not there, then it is just a bug.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Stefaan</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV><BR> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com] <BR><B>Sent:</B> maandag 28 april 2008=20 16:28<BR><B>To:</B> DE CNODDER Stefaan; Busser, M; = ancp@ietf.org<BR><B>Cc:</B>=20 Haag, T<BR><B>Subject:</B> RE: [ANCP] Mandatory TLVs in = draft-ietf-ancp-protocol=20 proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D560491614-28042008><FONT = face=3DArial=20 size=3D2>It's actually a mix of both. Inline...</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>DE CNODDER=20 Stefaan<BR><B>Sent:</B> 28 April 2008 16:04<BR><B>To:</B> Wojciech Dec = (wdec);=20 Busser, M; ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> Re: = [ANCP]=20 Mandatory TLVs in draft-ietf-ancp-protocol = proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Hi,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>This new mandatory flag, what is exactly its=20 meaning?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>(1) if flag set = to=20 "mandatory", then the *receiver* of this TLV MUST process it, and if=20 unrecognized must drop the message<SPAN = class=3D560491614-28042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>If a received TLV is = has=20 the "mandatory" flag set then the receiver MUST drop the = message and=20 report an error to the sender if it doesn't recognize the=20 TLV.</FONT> </SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>If a the receiver = expects=20 a "mandatory" TLV but doesn't receive it, the message MUST=20 be droped and an error report sent to=20 = the sender.</FONT> </SPAN></FONT></FONT></FONT></SPAN></SPAN></= FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>OR</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>(2) if flag is = set=20 to"mandatory", then the *sender* MUST include it in the message for = which it=20 is defined<SPAN class=3D560491614-28042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>The sender MUST = include mandatory=20 TLVs as defined by the=20 = protocol-spec/applications.</FONT></SPAN></FONT></FONT></FONT></SPAN></DI= V> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>The current protocols draft says for certain = TLVs that=20 they are mandatory, but that applies to the sender of it = (interpretation=20 2).  The flag would indicate interpretation 1 (like for Radius=20 VSAs?)?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>If the higher order = bit is set to=20 "0" means that it is mandatory, then currently defined optional = defined TLVs=20 suddenly become mandatory which is not good.<SPAN=20 class=3D560491614-28042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>Woj> Only the = currently used=20 TLVs become mandatory. If they are not used/implemented we can = re-define=20 them as optional (set flag to 1) at no cost.=20 </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>But I would first to = understand=20 the exact meaning of this mandatory flag.  Defining such a flag = indeed=20 looks useful but then as interpretation 1, and I would say that if = flag set to=20 1, then it is mandatory and actually, it is possible that a TLV is = sent=20 sometimes as optional and sometimes as mandatory.<SPAN=20 class=3D560491614-28042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>Woj> Precisely, = that is=20 possible on a per application basis.</FONT> <FONT = color=3D#000000>Having=20 the flag would make troubleshooting of a message flow much more = explicit=20 (today, with any problem one has to browse the drafts to figure = out what=20 MUST be there vs what SHOULD be there all while looking what = is=20 actually there)</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 = size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 = size=3D2><SPAN=20 = class=3D560491614-28042008>Regards,</SPAN></FONT></FONT></FONT></SPAN></D= IV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 = size=3D2><SPAN=20 = class=3D560491614-28042008>Woj.</SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 = size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Stefaan</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT> </DIV><BR> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>Wojciech Dec=20 (wdec)<BR><B>Sent:</B> donderdag 24 april 2008 14:19<BR><B>To:</B> = Busser, M;=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> Re: [ANCP] = Mandatory=20 TLVs in draft-ietf-ancp-protocol proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D709295811-24042008><FONT = face=3DArial=20 size=3D2>Hi Michael,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D709295811-24042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D709295811-24042008><FONT = face=3DArial=20 size=3D2>inline...</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>Busser, = M<BR><B>Sent:</B>=20 24 April 2008 13:13<BR><B>To:</B> ancp@ietf.org<BR><B>Cc:</B> Haag,=20 T<BR><B>Subject:</B> Re: [ANCP] Mandatory TLVs in = draft-ietf-ancp-protocol=20 proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>Hi = Woi,=20 all</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>I = see the=20 problem but i can not see, how an additional flag will help solving = this=20 problem.</FONT></SPAN></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Lets assume your=20 first proposal.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2>If an=20 implementation does not send the complete TLV, even it is=20 defined to be mandatory, I would call this a bug = and I=20 can not see, how an additional flag can help here.<SPAN=20 class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Woj> The way it helps, and other = protocols bear=20 proof of this scheme, is that it is easier for implementations to = reconcile=20 errors resulting out of "Mandatory" and "Optional" TLV sets. = The key to=20 this lies on a per application basis. One application may mandate = TLV A for=20 operation, while another might not. Resolving such issues when = implementing=20 or troubleshooting multiple applications is not always trivial.=20 </SPAN></FONT></FONT></SPAN><SPAN class=3D364043506-24042008><FONT=20 face=3DArial><FONT size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Your second=20 proposal seems obviously be required to keep existing things = working,=20 if we agree on your first proposal. </FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>But from my=20 point of view it also assumes, that all existing = implementations are=20 using the same set of TLVs now. </FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2>And I=20 am not sure about that. <SPAN=20 class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Woj> This would be a good thing for = the WG to=20 discuss. There most evidently is a fair amount of "dead wood" = in the=20 current spec, ie stuff that nobody yet implements or cares = about.=20  In the former case, we could re-cast that material using the = new=20 notions/extensions, in the latter case simply chop it=20 out.</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2><SPAN=20 class=3D364043506-24042008><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV></FONT></SPAN> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2>Therefore=20 I disagree with your first proposal. I recommend, the better = way will=20 be to be more precise in definitions.<SPAN=20 class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>In = my mind, it=20 is a bug, if a mandatory TLV is missing. It is up to the robustness = of the=20 implementation to deal with this situation.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2>Is it=20 really neccesary to define the behavior of a network element in this = case of=20 failure in the ancp protocol itself? <SPAN=20 class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Woj> Other people have faced this = problem=20 before, and I would rather go with the lessons they learned, rather = than=20 clinging to hopes of perfect textual definitions and = implementations. Other=20 than backwards compatibility, I do not see in your statements a = valid=20 reason to object to the 1st proposal, particularly for new = applications since it can only make things more robust. The counter = argument=20 of being precise in the definitions, as evidenced by the current = spec, is=20 admirable and needs to be there, with this proposal providing an = extra level=20 of robustness and visibility of any problems.=20 </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Thanks,</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Woj.</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2>If = optional TLVs=20 are not present in a message, we should describe some kind of = default=20 behaviour, as you already stated.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Comments on=20 = draft-ietf-ancp-protocol-02.txt:</FONT></SPAN></DIV></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT = face=3DArial>It is not=20 clearly stated, if the TLV  "<SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA">DSL=20 Line Attributes "<FONT face=3DArial> is mandatory or optional.=20 </FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT = face=3DArial><SPAN=20 lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>In fact it is mandatory because some of its SubTLVs are = mandatory. </FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT = face=3DArial><SPAN=20 lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>We should spent a sentence to make this=20 clear.</FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2><SPAN=20 class=3D364043506-24042008><FONT size=3D2><FONT face=3DArial>It is = not clearly=20 stated, if the TLV  "<SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: = AR-SA">Service-Profile-Name"<FONT=20 face=3DArial> is mandatory or=20 optional.</FONT></SPAN></FONT></FONT></SPAN></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2><SPAN=20 class=3D364043506-24042008><FONT size=3D2><FONT face=3DArial><SPAN = lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>I prefer mandatory because it is essetial for the use = case Line=20 = Config. </FONT></SPAN></FONT></FONT></SPAN></DIV></FONT></SPAN><SPAN= =20 class=3D364043506-24042008><FONT face=3DArial = size=3D2></FONT></SPAN> <DIV><SPAN class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008><FONT face=3DArial = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Section 5.4.3=20 Line Config, where the TLVs are mentioned (page = 35):</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2> =20 ...defined in section 5.4.1....    must be corrected=20 to    ...defined in section = 5.4.2........</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Section=20 5.4.4 OAM, where the TLVs are mentioned (page 36 and page=20 38):</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2> =20 ...defined in section 5.4.1....    must be corrected=20 to    ...defined in section = 5.4.2........</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV></FONT></SPAN><SPAN class=3D364043506-24042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV></DIV> <DIV><SPAN class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN = class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN = class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV align=3Dleft><FONT color=3D#000080 size=3D2> <P align=3Dleft>Best Regards; Freundliche Gr=FC=DFe = </P></FONT><B><FONT=20 color=3D#000080> <P>Michael Busser</P></B></FONT><FONT size=3D1> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt">T-Systems=20 Enterprise Services GmbH </SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1>Production Line Network Centric Systems</FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1>ICT-Systems Integration</FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1>Network Integration Services</FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1></FONT><SPAN style=3D"COLOR: navy"></SPAN><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy"><FONT face=3DArial = color=3D#000000=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy"><FONT color=3D#000000 = size=3D1>Br=FCckes 2=20 -8, 55545 Bad Kreuznach<BR>Postfach 9100, 55541 Bad Kreuznach<BR>+49 = 671=20 8333 8911 (Phone)<BR>+49 521 9210 3859 (Fax)<BR>+49 151=20 1211 9689 (Mobile)<BR>E-Mail: <A=20 = href=3D"mailto:michael.busser@t-systems.com">michael.busser@t-systems.com= </A></FONT></SPAN></DIV></SPAN> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN></DIV><SPAN style=3D"FONT-SIZE: = 8pt">Internet:=20 </SPAN><SPAN style=3D"FONT-SIZE: 8pt"><p:onmouseclick=20 href=3D"http://www.t-systems.com/" = hyperlinktype=3D"url"></p:onmouseclick><A=20 onclick=3Dwindow.event.cancelBubble=3Dtrue; = href=3D"http://www.t-systems.com/"=20 target=3D_parent><FONT=20 color=3D#6699ff>http://www.t-systems.com</FONT></A></SPAN><SPAN=20 style=3D"FONT-SIZE: 8pt"> </SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN> </DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D3><FONT size=3D1><SPAN=20 style=3D"FONT-SIZE: 7.5pt; COLOR: black; FONT-FAMILY: = Arial">T-Systems=20 Enterprise Services GmbH<BR>Aufsichtsrat: Ren=E9 Obermann=20 (Vorsitzender)<BR>Executive Committee: Reinhard Clemens = (Vorsitzender)*,=20 Helmut Binder, Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich = Kemp,=20 Wilfried Peters*,<BR>Dr. Herbert Schaaff*, Zvezdana=20 Seeger*<BR>Handelsregister: Amtsgericht Frankfurt am Main HRB = 55933<BR>Sitz=20 der Gesellschaft: Frankfurt am Main<BR>WEEE-Reg.-Nr.=20 DE87523644<BR>*Gesch=E4ftsf=FChrer gem. =A7 35=20 GmbHG</SPAN></FONT></FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT face=3DArial=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT size=3D1>Notice: This transmittal = and/or=20 attachments may be privileged or confidential. If you are not the = intended=20 recipient, you are hereby notified that you have received this = transmittal=20 in error; any review, dissemination, or copying is strictly = prohibited. If=20 you received this transmittal in error, please notify us immediately = by=20 reply and immediately delete this message and all its attachments. = Thank=20 you. </FONT><FONT size=3D1><BR>T-Systems =96 Business flexibility=20 </FONT></DIV></SPAN></SPAN> <DIV><FONT face=3DArial size=3D2></FONT> </DIV></FONT></DIV> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"> <DIV></DIV> <DIV class=3DOutlookMessageHeader lang=3Dde dir=3Dltr = align=3Dleft> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy = size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: = Arial"><o:p></o:p></SPAN></FONT></P><FONT=20 face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: = 12pt"><FONT=20 face=3DArial size=3D2></FONT> <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2> </SPAN></FONT></DIV> <DIV class=3DSection1> <DIV> <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: = Tahoma">Von:</SPAN></FONT></B><FONT=20 face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; = FONT-FAMILY: Tahoma">=20 ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] <B><SPAN=20 style=3D"FONT-WEIGHT: bold">Im Auftrag von </SPAN></B>Wojciech Dec = (wdec)<BR><B><SPAN style=3D"FONT-WEIGHT: = bold">Gesendet:</SPAN></B>=20 Mittwoch, 23. April 2008 14:54<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">An:</SPAN></B> = ancp@ietf.org<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Betreff:</SPAN></B> [ANCP] Mandatory = TLVs in=20 draft-ietf-ancp-protocol = proposal</SPAN></FONT><o:p></o:p></P></DIV> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN = style=3D"FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi = All,</SPAN></FONT><SPAN=20 lang=3DEN-GB> </SPAN><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Continuing with the = series of=20 e-mails regarding basic protocol issues still to be addressed, I = now would=20 now like to ask your feedback regarding the distinction the = protocol=20 places on mandatory TLVs. Given the length of this mail I'll first = cut to=20 the proposal, and after it you can find the problem=20 description.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The proposal which I = am=20 putting in front of the WG is to define a new TLV format which = contains at=20 a minimum a Mandatory flag (much like Radius VSAs do). We could = have this=20 TLV Flag be defined only for new=20 applications.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">A second proposal = would be try=20 to make this flag work with existing ones by for example defining = the=20 highest order bit of the TLV# field to mean "Mandatory" when set = to "0".=20 This would be invisible to exiting implementations, but newer ones = may=20 have problems in communicating with older ones when the latter do = not send=20 all TLVs. But that can also be addressed by simply forming the set = of=20 mandatory TLVs to be the ones that all implementations currently = send by=20 default.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Without additional = feedback, I=20 will assume that the WG is fine with the first proposal, and also = with the=20 2nd one conditional on deriving a suitable "commonly used" TLV=20 set.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The problem in more = detail:=20 </SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Currently the = situation is=20 that Mandatory TLVs are only stated to be as such in the body of = the=20 protocol draft spec, with an implementer having to scour fairly=20 attentively the text. Eg "Type (Access-Loop-Circuit-ID =3D 0x01): = This is a=20 mandatory TLV", etc.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The behaviour of an=20 implementation that receives a message with a missing mandatory = TLV is not=20 defined at all, and the opposite is handled but not very robustly, = i.e.=20 when receiving a TLV but not recognizing it, and implementation is = free to=20 discard it (even if it is mandatory!). This is a recipe for=20 interoperability problems and an implementation mine=20 field.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">This problem is = complicated by=20 different applications. For example the current OAM section states = the=20 following regarding TLVs that are to be carried in the request = message (my=20 italics):</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">"</SPAN></FONT> = <BR><FONT=20 face=3D"Courier New" color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">Following=20 TLVs<B><I><SPAN style=3D"FONT-WEIGHT: bold; FONT-STYLE: italic">=20 can</SPAN></I></B> appear in this message: = </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section=20 5.4.1    </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (Access-Aggregation-Circuit-ID-Binary =3D 0x06): defined in = </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 section 5.4.1. </SPAN></FONT><BR><FONT face=3D"Courier New" = color=3Dblack=20 size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'"> </SPAN></FONT>=20 <BR><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03): defined in = section=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 5.4.1.  </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (OAM-Loopback-Test-Parameters =3D 0x07): Parameters related = to =20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 loopback test. This is an optional TLV. If this TLV is not present = </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 in the request message, the DSLAM SHOULD use locally determined=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 default values for the test parameters.  = </SPAN></FONT><BR><FONT=20 face=3D"Courier New" color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">"</SPAN></FONT>=20 <BR><FONT face=3DArial color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">(NOTE: = The last=20 "SHOULD" appears to be inappropriate. If the TLV is missing, the = DSLAM=20 MUST have some default parameters, or return an=20 error)</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">The = "can" above=20 indicates that they're all optional, while clearly the application = cannot=20 run its course without one or more of these fields. Here we have a = case=20 where one could have a perfectly compliant implementation that = ignores all=20 these TLVs=85</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = Arial">-Woj.</SPAN></FONT><SPAN=20 lang=3DEN-US> </SPAN><o:p></o:p></P> <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><FONT=20 face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: = 12pt"><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><o:p></o:p></SPAN></FONT></= P></DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C8A942.9BE97707-- --===============0546723925== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============0546723925==-- From ancp-bounces@ietf.org Mon Apr 28 10:03:43 2008 Return-Path: <ancp-bounces@ietf.org> X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBF3128C15B; Mon, 28 Apr 2008 10:03:43 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B16B3A6EA0 for <ancp@core3.amsl.com>; Mon, 28 Apr 2008 10:03:42 -0700 (PDT) X-Quarantine-ID: <J356iS3YUVe4> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat 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] X-Amavis-Modified: Mail body modified (defanged) by core3.amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J356iS3YUVe4 for <ancp@core3.amsl.com>; Mon, 28 Apr 2008 10:03:41 -0700 (PDT) Content-Type: multipart/mixed; boundary="----------=_1209402222-17926-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from eci-iron1.ecitele.com (eci-iron1.ecitele.com [147.234.242.117]) by core3.amsl.com (Postfix) with ESMTP id CE9CC3A68AF for <ancp@ietf.org>; Mon, 28 Apr 2008 10:03:39 -0700 (PDT) Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by eci-iron1.ecitele.com with ESMTP; 28 Apr 2008 20:49:19 +0300 Received: from ILPTEXCH02.ecitele.com ([147.234.245.181]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Apr 2008 20:03:41 +0300 Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Mon, 28 Apr 2008 20:03:41 +0300 From: Moti Morgenstern <Moti.Morgenstern@ecitele.com> To: "ancp@ietf.org" <ancp@ietf.org> Date: Mon, 28 Apr 2008 20:03:38 +0300 Message-ID: <741F3E4A466A1D439C616902C7F8A8C66B1369B8DB@ILPTMAIL02.ecitele.com> Subject: [ANCP] draft-ietf-ancp-mib-an-02 was uploaded X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list <ancp.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/ancp> List-Post: <mailto:ancp@ietf.org> List-Help: <mailto:ancp-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=subscribe> Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format... ------------=_1209402222-17926-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1209402222-17926-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Received: from eci-iron1.ecitele.com (eci-iron1.ecitele.com [147.234.242.117]) by core3.amsl.com (Postfix) with ESMTP id CE9CC3A68AF for <ancp@ietf.org>; Mon, 28 Apr 2008 10:03:39 -0700 (PDT) Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by eci-iron1.ecitele.com with ESMTP; 28 Apr 2008 20:49:19 +0300 Received: from ILPTEXCH02.ecitele.com ([147.234.245.181]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Apr 2008 20:03:41 +0300 Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Mon, 28 Apr 2008 20:03:41 +0300 Content-Type: multipart/mixed; boundary="_000_741F3E4A466A1D439C616902C7F8A8C66B1369B8DBILPTMAIL02eci_" From: Moti Morgenstern <Moti.Morgenstern@ecitele.com> To: "ancp@ietf.org" <ancp@ietf.org> CC: DE CNODDER Stefaan <stefaan.de_cnodder@alcatel-lucent.be>, BOCCI Matthew <Matthew.Bocci@alcatel-lucent.co.uk>, "Wojciech Dec (wdec)" <wdec@cisco.com> Date: Mon, 28 Apr 2008 20:03:38 +0300 Subject: draft-ietf-ancp-mib-an-02 was uploaded Thread-Topic: draft-ietf-ancp-mib-an-02 was uploaded Thread-Index: AcipUc17QY/HcHMOSGCnJEUaZXSdxQ== Message-ID: <741F3E4A466A1D439C616902C7F8A8C66B1369B8DB@ILPTMAIL02.ecitele.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: <741F3E4A466A1D439C616902C7F8A8C66B1369B8DB@ILPTMAIL02.ecitele.com> acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 28 Apr 2008 17:03:41.0729 (UTC) FILETIME=[CF695110:01C8A951] --_000_741F3E4A466A1D439C616902C7F8A8C66B1369B8DBILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've uploaded revision -02 of the ANCP AN MIB to the IETF site. Main changes from revision -01: 1) Added per session the option to define an association to a lower layer e= ntity, an ifIndex, C-Tag details, and/or S-tag details (6 parameters). This= required also importing few textual conventions from other RFCs and adding= text for describing those parameters. 2) AncpAnSessionCapabilities (Textual Convention) renamed to AncpSessionCap= abilities. It affects multiple locations in the MIB. 3) Divided the MIB into two parts. One that includes TCs (can be used also = for ANCP NAS MIB) and one that is the ANCP AN MIB. 4) Document structure was improved. E.g., Added a title to the section that= describes the relationship to the Interfaces Group MIB module 5) ANCP subtree under mib-2 with branches for the generic TCs, the ANCP AN = mib and (outside this document) the ANCP NAS mib. 6) Notifications are controlled as part of the session configuration. 7) Added ancpAnCurrentSessionDiscontinuityTime to session-down notification= . 8) More textual description of elements in the MIB, including the list of i= mported definitions from other MIB modules, description of notifications co= ntrol, etc. 9) Minor editorial changes Regards, Moti --_000_741F3E4A466A1D439C616902C7F8A8C66B1369B8DBILPTMAIL02eci_ Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 Content-Type: application/ms-tnef; name="winmail.dat" eJ8+IosRAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEJgAEAIQAAADhEOTVGODY2 RDc2NkUxNEU5NDYxMTMzNUUyRDAzRUU2ACgHAQ2ABAACAAAAAgACAAEFgAMADgAAANgHBAAcABEA AwAmAAEAOgEBIIADAA4AAADYBwQAHAARAAMAKQABAD0BAQiABwAYAAAASVBNLk1pY3Jvc29mdCBN YWlsLk5vdGUAMQgBBIABACcAAABkcmFmdC1pZXRmLWFuY3AtbWliLWFuLTAyIHdhcyB1cGxvYWRl ZAB+DQEDkAYApBcAADgAAAACAX8AAQAAAEQAAAA8NzQxRjNFNEE0NjZBMUQ0MzlDNjE2OTAyQzdG OEE4QzY2QjEzNjlCOERCQElMUFRNQUlMMDIuZWNpdGVsZS5jb20+AAIBExABAAAA4Q4AADwhRE9D VFlQRSBIVE1MIFBVQkxJQyAiLS8vVzNDLy9EVEQgSFRNTCA0LjAgVHJhbnNpdGlvbmFsLy9FTiI+ DQo8SFRNTD48SEVBRD4NCjxNRVRBIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRl eHQvaHRtbDsgY2hhcnNldD11cy1hc2NpaSI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4y OTAwLjMyNjgiIG5hbWU9R0VORVJBVE9SPjwvSEVBRD4NCjxCT0RZPg0KPERJVj48Rk9OVCBmYWNl PUFyaWFsIHNpemU9Mj48U1BBTiANCmNsYXNzPTA1NDMzMTAwNy0yODA0MjAwOD5IaSw8L1NQQU4+ PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCmNsYXNz PTA1NDMzMTAwNy0yODA0MjAwOD48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O VCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz0wNTQzMzEwMDctMjgwNDIwMDg+SSd2ZSB1 cGxvYWRlZCANCnJldmlzaW9uIC0wMiBvZiB0aGUgQU5DUCBBTiBNSUIgdG8gdGhlIElFVEYgc2l0 ZS48L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BB TiANCmNsYXNzPTA1NDMzMTAwNy0yODA0MjAwOD48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0K PERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz0wNTQzMzEwMDctMjgwNDIw MDg+TWFpbiBjaGFuZ2VzIGZyb20gDQpyZXZpc2lvbiAtMDE6PC9TUEFOPjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gY2xhc3M9MDU0MzMxMDA3LTI4MDQy MDA4PjEpJm5ic3A7QWRkZWQgcGVyIA0Kc2Vzc2lvbiB0aGUgb3B0aW9uIHRvIGRlZmluZSBhbiBh c3NvY2lhdGlvbiB0byBhIGxvd2VyIGxheWVyIGVudGl0eSwgYW4gaWZJbmRleCwgDQpDLVRhZyBk ZXRhaWxzLCBhbmQvb3IgUy10YWcgZGV0YWlscyAoNiBwYXJhbWV0ZXJzKS4gVGhpcyByZXF1aXJl ZCBhbHNvIGltcG9ydGluZyANCmZldyB0ZXh0dWFsIGNvbnZlbnRpb25zIGZyb20gb3RoZXIgUkZD cyBhbmQgYWRkaW5nIHRleHQgZm9yIGRlc2NyaWJpbmcgdGhvc2UgDQpwYXJhbWV0ZXJzLjwvU1BB Tj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KY2xh c3M9MDU0MzMxMDA3LTI4MDQyMDA4PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTA1NDMzMTAwNy0yODA0MjAwOD4yKSAN CkFuY3BBblNlc3Npb25DYXBhYmlsaXRpZXMgKFRleHR1YWwgQ29udmVudGlvbikgcmVuYW1lZCB0 byANCkFuY3BTZXNzaW9uQ2FwYWJpbGl0aWVzLiBJdCZuYnNwO2FmZmVjdHMmbmJzcDttdWx0aXBs ZSBsb2NhdGlvbnMgaW4gdGhlIA0KTUlCLiZuYnNwOzwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9MDU0MzMxMDA3LTI4MDQyMDA4 PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0y PjxTUEFOIGNsYXNzPTA1NDMzMTAwNy0yODA0MjAwOD4zKSBEaXZpZGVkIHRoZSBNSUIgDQppbnRv IHR3byBwYXJ0cy4gT25lIHRoYXQgaW5jbHVkZXMgVENzIChjYW4gYmUgdXNlZCBhbHNvIGZvciBB TkNQIE5BUyBNSUIpIGFuZCANCm9uZSB0aGF0IGlzIHRoZSBBTkNQIEFOIE1JQi48L1NQQU4+PC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCmNsYXNzPTA1 NDMzMTAwNy0yODA0MjAwOD48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBm YWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz0wNTQzMzEwMDctMjgwNDIwMDg+NCkgRG9jdW1l bnQgDQpzdHJ1Y3R1cmUgd2FzIGltcHJvdmVkLiBFLmcuLCBBZGRlZCBhIHRpdGxlIHRvIHRoZSBz ZWN0aW9uIHRoYXQgZGVzY3JpYmVzIHRoZSANCnJlbGF0aW9uc2hpcCB0byB0aGUgSW50ZXJmYWNl cyBHcm91cCBNSUIgbW9kdWxlPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1B cmlhbCBzaXplPTI+PFNQQU4gDQpjbGFzcz0wNTQzMzEwMDctMjgwNDIwMDg+PC9TUEFOPjwvRk9O VD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gY2xhc3M9 MDU0MzMxMDA3LTI4MDQyMDA4PjUpIEFOQ1Agc3VidHJlZSANCnVuZGVyIG1pYi0yIHdpdGggYnJh bmNoZXMgZm9yIHRoZSBnZW5lcmljIFRDcywgdGhlIEFOQ1AgQU4gbWliIGFuZCAob3V0c2lkZSB0 aGlzIA0KZG9jdW1lbnQpIHRoZSBBTkNQIE5BUyBtaWIuPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQpjbGFzcz0wNTQzMzEwMDctMjgwNDIw MDg+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXpl PTI+PFNQQU4gY2xhc3M9MDU0MzMxMDA3LTI4MDQyMDA4PjYpIE5vdGlmaWNhdGlvbnMgYXJlIA0K Y29udHJvbGxlZCBhcyBwYXJ0IG9mIHRoZSBzZXNzaW9uIGNvbmZpZ3VyYXRpb24uIDwvU1BBTj48 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9 MDU0MzMxMDA3LTI4MDQyMDA4PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTA1NDMzMTAwNy0yODA0MjAwOD43KSBBZGRl ZCZuYnNwOzxTUEFOIA0KbGFuZz1FTi1HQiBzdHlsZT0iRk9OVC1TSVpFOiAyOHB0OyBGT05ULUZB TUlMWTogJ1RpbWVzIE5ldyBSb21hbiciPjxGT05UIA0KZmFjZT1BcmlhbCBzaXplPTI+YW5jcEFu Q3VycmVudFNlc3Npb25EaXNjb250aW51aXR5VGltZSA8L0ZPTlQ+PEZPTlQgZmFjZT1BcmlhbCAN CnNpemU9Mj50byBzZXNzaW9uLWRvd24gbm90aWZpY2F0aW9uLjwvRk9OVD48L1NQQU4+PC9TUEFO PjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQpjbGFz cz0wNTQzMzEwMDctMjgwNDIwMDg+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gY2xhc3M9MDU0MzMxMDA3LTI4MDQyMDA4PjgpIE1v cmUgdGV4dHVhbCANCmRlc2NyaXB0aW9uIG9mIGVsZW1lbnRzIGluIHRoZSBNSUIsIGluY2x1ZGlu ZyB0aGUgbGlzdCBvZiBpbXBvcnRlZCBkZWZpbml0aW9ucyANCmZyb20gb3RoZXIgTUlCIG1vZHVs ZXMsIGRlc2NyaXB0aW9uIG9mIG5vdGlmaWNhdGlvbnMgY29udHJvbCwgDQpldGMuPC9TUEFOPjwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQpjbGFzcz0w NTQzMzEwMDctMjgwNDIwMDg+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gY2xhc3M9MDU0MzMxMDA3LTI4MDQyMDA4PjkpIE1pbm9y IGVkaXRvcmlhbCANCmNoYW5nZXM8L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNl PUFyaWFsIHNpemU9Mj48U1BBTiANCmNsYXNzPTA1NDMzMTAwNy0yODA0MjAwOD48L1NQQU4+PC9G T05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFz cz0wNTQzMzEwMDctMjgwNDIwMDg+UmVnYXJkcywgDQo8L1NQQU4+PC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCmNsYXNzPTA1NDMzMTAwNy0yODA0MjAw OD5Nb3RpPC9TUEFOPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0KAAAAHwBCAAEAAAAiAAAA TQBvAHQAaQAgAE0AbwByAGcAZQBuAHMAdABlAHIAbgAAAAAAHwBlAAEAAAA6AAAATQBvAHQAaQAu AE0AbwByAGcAZQBuAHMAdABlAHIAbgBAAGUAYwBpAHQAZQBsAGUALgBjAG8AbQAAAAAAHwBkAAEA AAAKAAAAUwBNAFQAUAAAAAAAAgFBAAEAAAB+AAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAGATQBv AHQAaQAgAE0AbwByAGcAZQBuAHMAdABlAHIAbgAAAFMATQBUAFAAAABNAG8AdABpAC4ATQBvAHIA ZwBlAG4AcwB0AGUAcgBuAEAAZQBjAGkAdABlAGwAZQAuAGMAbwBtAAAAAAAfABoMAQAAACIAAABN AG8AdABpACAATQBvAHIAZwBlAG4AcwB0AGUAcgBuAAAAAAAfAB8MAQAAADoAAABNAG8AdABpAC4A TQBvAHIAZwBlAG4AcwB0AGUAcgBuAEAAZQBjAGkAdABlAGwAZQAuAGMAbwBtAAAAAAAfAB4MAQAA AAoAAABTAE0AVABQAAAAAAACARkMAQAAAH4AAAAAAAAAgSsfpL6jEBmdbgDdAQ9UAgAAAYBNAG8A dABpACAATQBvAHIAZwBlAG4AcwB0AGUAcgBuAAAAUwBNAFQAUAAAAE0AbwB0AGkALgBNAG8AcgBn AGUAbgBzAHQAZQByAG4AQABlAGMAaQB0AGUAbABlAC4AYwBvAG0AAAAAAB8AGgABAAAAEgAAAEkA UABNAC4ATgBvAHQAZQAAAAAAAwDxPwkEAAALAEA6AQAAAAMA/T/kBAAAAgELMAEAAAAQAAAAjZX4 Ztdm4U6UYRM14tA+5gMAFwABAAAAQAA5AABRMM1RqcgBQAAIMK9FGs9RqcgBCwACAAEAAAALACMA AAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAAIBRwABAAAANgAAAGM9VVM7YT0gO3A9RUNJVGVs ZWNvbTtsPUlMUFRNQUlMMDItMDgwNDI4MTcwMzQxWi0xNzE1AAAAHwBwAAEAAABOAAAAZAByAGEA ZgB0AC0AaQBlAHQAZgAtAGEAbgBjAHAALQBtAGkAYgAtAGEAbgAtADAAMgAgAHcAYQBzACAAdQBw AGwAbwBhAGQAZQBkAAAAAAACAXEAAQAAABYAAAAByKlRzXtBj8dwcw5IYKckRRpldJ3FAAAfADUQ AQAAAIgAAAA8ADcANAAxAEYAMwBFADQAQQA0ADYANgBBADEARAA0ADMAOQBDADYAMQA2ADkAMAAy AEMANwBGADgAQQA4AEMANgA2AEIAMQAzADYAOQBCADgARABCAEAASQBMAFAAVABNAEEASQBMADAA MgAuAGUAYwBpAHQAZQBsAGUALgBjAG8AbQA+AAAAAwCAEP////8fAPMQAQAAAFYAAABkAHIAYQBm AHQALQBpAGUAdABmAC0AYQBuAGMAcAAtAG0AaQBiAC0AYQBuAC0AMAAyACAAdwBhAHMAIAB1AHAA bABvAGEAZABlAGQALgBFAE0ATAAAAAAACwD0EAAAAAALAPUQAAAAAAsA9hAAAAAAQAAHMGbAs85R qcgBAwDeP59OAAAfAPg/AQAAACIAAABNAG8AdABpACAATQBvAHIAZwBlAG4AcwB0AGUAcgBuAAAA AAACAfk/AQAAAFYAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089RUNJVEVMRUNPTS9P VT1JU1JBRUwvQ049UkVDSVBJRU5UUy9DTj1NT1RJLk1PUkdFTlNURVJOAAAAHwD6PwEAAAAiAAAA TQBvAHQAaQAgAE0AbwByAGcAZQBuAHMAdABlAHIAbgAAAAAAAgH7PwEAAABWAAAAAAAAANynQMjA QhAatLkIACsv4YIBAAAAAAAAAC9PPUVDSVRFTEVDT00vT1U9SVNSQUVML0NOPVJFQ0lQSUVOVFMv Q049TU9USS5NT1JHRU5TVEVSTgAAAAMAGUAAAAAAAwAaQAAAAAADAAJZAAAWAAMACVkCAAAAAwAA gAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAAfAACACCAGAAAAAADAAAAAAAAARgAAAACDhQAA AQAAACYAAAAwADUANAAzADMAMQAwADAANwAtADIAOAAwADQAMgAwADAAOAAAAAAACwAAgAggBgAA AAAAwAAAAAAAAEYAAAAAA4UAAAAAAAALAACACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMA AIAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAAAwAAgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUA AAAAAAALAACACCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAsAAIAIIAYAAAAAAMAAAAAAAABG AAAAAIKFAAAAAAAAAwANNPk/AAACARQ0AQAAABAAAABUlKHAKX8QG6WHCAArKiUXHwA9AAEAAAAC AAAAAAAAAB8ANwABAAAATgAAAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBhAG4AYwBwAC0AbQBpAGIA LQBhAG4ALQAwADIAIAB3AGEAcwAgAHUAcABsAG8AYQBkAGUAZAAAAAAAHwAAgIYDAgAAAAAAwAAA AAAAAEYBAAAAHgAAAGEAYwBjAGUAcAB0AGwAYQBuAGcAdQBhAGcAZQAAAAAAAQAAAAwAAABlAG4A LQBVAFMAAAAfAACAhgMCAAAAAADAAAAAAAAARgEAAAAgAAAAeAAtAG0AcwAtAGgAYQBzAC0AYQB0 AHQAYQBjAGgAAAABAAAAAgAAAAAAAAAcyQ== --_000_741F3E4A466A1D439C616902C7F8A8C66B1369B8DBILPTMAIL02eci_-- ------------=_1209402222-17926-1 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp ------------=_1209402222-17926-1-- From ancp-bounces@ietf.org Mon Apr 28 10:15:04 2008 Return-Path: <ancp-bounces@ietf.org> X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2282228C2BD; Mon, 28 Apr 2008 10:15:04 -0700 (PDT) X-Original-To: ancp@ietf.org Delivered-To: ancp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BCE2C3A6EB7; Mon, 28 Apr 2008 10:15:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080428171501.BCE2C3A6EB7@core3.amsl.com> Date: Mon, 28 Apr 2008 10:15:01 -0700 (PDT) Cc: ancp@ietf.org Subject: [ANCP] I-D Action:draft-ietf-ancp-mib-an-02.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list <ancp.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/ancp> List-Post: <mailto:ancp@ietf.org> List-Help: <mailto:ancp-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=subscribe> Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access Node Control Protocol Working Group of the IETF. Title : Access Node Control Protocol (ANCP) MIB module for Access Nodes Author(s) : S. Cnodder, M. Morgenstern Filename : draft-ietf-ancp-mib-an-02.txt Pages : 37 Date : 2008-04-28 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing access nodes that are using the Access Node Control Protocol (ANCP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-mib-an-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ancp-mib-an-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-28100246.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --NextPart-- From ancp-bounces@ietf.org Mon Apr 28 12:33:27 2008 Return-Path: <ancp-bounces@ietf.org> X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 527D83A6B6D; Mon, 28 Apr 2008 12:33:26 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C49B3A6B6D for <ancp@core3.amsl.com>; Mon, 28 Apr 2008 12:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.454 X-Spam-Level: X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rV-KAjuOsmwy for <ancp@core3.amsl.com>; Mon, 28 Apr 2008 12:33:22 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C51083A6ADC for <ancp@ietf.org>; Mon, 28 Apr 2008 12:33:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,717,1199660400"; d="scan'208,217";a="7552954" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 28 Apr 2008 21:33:13 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3SJXDUH032473; Mon, 28 Apr 2008 21:33:13 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3SJXDFY021386; Mon, 28 Apr 2008 19:33:13 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Apr 2008 21:33:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Apr 2008 21:33:06 +0200 Message-ID: <D9872168DBD43A41BD71FFC4713274D404FF1233@xmb-ams-33b.emea.cisco.com> In-Reply-To: <7A6D4815C5E8F74988784FEBD50F2F1E01ABAAA4@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal thread-index: AcilQRMfK4kdawUKQOWs5fdBngS8QQAAr04QACRhApAAC0ujAADNHRywAADiEXAAAbhxoAAAWwcQ References: <1B6169C658325341A3B8066E23919E1C01230DC1@S4DE8PSAANK.mitte.t-com.de><1B6169C658325341A3B8066E23919E1CFBC5C4@S4DE8PSAANK.mitte.t-com.de><D9872168DBD43A41BD71FFC4713274D404FA6ACC@xmb-ams-33b.emea.cisco.com> <7A6D4815C5E8F74988784FEBD50F2F1E01ABAA16@FRVELSMBS22.ad2.ad.alcatel.com> <D9872168DBD43A41BD71FFC4713274D404FF10C1@xmb-ams-33b.emea.cisco.com> <7A6D4815C5E8F74988784FEBD50F2F1E01ABAAA4@FRVELSMBS22.ad2.ad.alcatel.com> From: "Wojciech Dec (wdec)" <wdec@cisco.com> To: "DE CNODDER Stefaan" <stefaan.de_cnodder@alcatel-lucent.be>, "Busser, M" <Michael.Busser@t-systems.com>, <ancp@ietf.org> X-OriginalArrivalTime: 28 Apr 2008 19:33:12.0855 (UTC) FILETIME=[B29E8270:01C8A966] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=62374; t=1209411193; x=1210275193; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20<wdec@cisco.com> |Subject:=20RE=3A=20[ANCP]=20Mandatory=20TLVs=20in=20draft- ietf-ancp-protocol=20proposal |Sender:=20; bh=M1XttJbdVCm57FrD9SnWJkqpi1ENDW3zQYcbCRMEoGw=; b=tZmNKy0Yq7oFPGnRu4JHQOGZJCKsrH/vFV6mUSlxV8ZDGAStelDcplXR2Y RH4geta3YnpkpSrx+5J9R8lpgqtrc+sWQiel6yTdmDbm21R3fMHc+EajNnSN mDjL0uUGXF; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: "Haag, T" <Thomas.Haag@t-systems.com> Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list <ancp.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/ancp> List-Post: <mailto:ancp@ietf.org> List-Help: <mailto:ancp-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1920464201==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1920464201== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A966.B261D946" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A966.B261D946 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 ________________________________ From: DE CNODDER Stefaan [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Sent: 28 April 2008 17:15 To: Wojciech Dec (wdec); Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal =09 =09 =20 Take the bandwidth sub-TLV in port up messages as example. The current = protocol spec says that it is mandatory to be sent in port up messages. = that's ok. But it is not mandatory for the receiver to process the = bandwidth sub-TLV. What is done with this information by the NAS is not = specified by ANCP, so you cannot make it mandatory for the receiver = side.=20 =20 Woj> Is the information required by the application? It would appear = for the dynamic shaping use-case to be most certainly so. Hence it is = absolutely mandatory, otherwise the message makes no sense for the = application. In any case, if=20 =20 So it looks to me that the flag can only indicate what the receiver = should do. Then the flag makes sense.=20 =20 Woj> The flag tells the receiver what info the sender thinks is = required to carry out the application. This in almost all cases has to = match up to what the receiver thinks is required. The sender doesn't = tell the receiver what to do with the info. =20 If the receiver knows what is mandatory, then I do not see a reason why = this has to be made explicit in the protocol. It would only complicate = the protocol. As already said by Michael: if a mandatory TLV is not = there, then it is just a bug.=20 =20 Woj> Can you specifically describe what aspect of the protocol does it = complicate? It's just making explicitly clear what the protocol already = has to implement anyway to be of any use. As to whether it is a bug, having such explicit marking makes it clear = what/where the problem is when observing a messaging flow vs a lot of = deduction work. In any case, the other point being made here is that = today the protocol does NOT specify what should happen if a mandatory = TLV is missing. =20 -Woj. =20 regards, Stefaan =20 =20 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: maandag 28 april 2008 16:28 To: DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal =09 =09 It's actually a mix of both. Inline... ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = Of DE CNODDER Stefaan Sent: 28 April 2008 16:04 To: Wojciech Dec (wdec); Busser, M; ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 =20 Hi, =20 This new mandatory flag, what is exactly its meaning? =20 (1) if flag set to "mandatory", then the *receiver* of this TLV MUST = process it, and if unrecognized must drop the message=20 =20 If a received TLV is has the "mandatory" flag set then the receiver = MUST drop the message and report an error to the sender if it doesn't = recognize the TLV.=20 If a the receiver expects a "mandatory" TLV but doesn't receive it, = the message MUST be droped and an error report sent to the sender.=20 =20 OR =20 (2) if flag is set to"mandatory", then the *sender* MUST include it in = the message for which it is defined=20 =20 The sender MUST include mandatory TLVs as defined by the = protocol-spec/applications. =20 The current protocols draft says for certain TLVs that they are = mandatory, but that applies to the sender of it (interpretation 2). The = flag would indicate interpretation 1 (like for Radius VSAs?)? =20 If the higher order bit is set to "0" means that it is mandatory, then = currently defined optional defined TLVs suddenly become mandatory which = is not good.=20 =20 Woj> Only the currently used TLVs become mandatory. If they are not = used/implemented we can re-define them as optional (set flag to 1) at no = cost.=20 =20 But I would first to understand the exact meaning of this mandatory = flag. Defining such a flag indeed looks useful but then as = interpretation 1, and I would say that if flag set to 1, then it is = mandatory and actually, it is possible that a TLV is sent sometimes as = optional and sometimes as mandatory.=20 =20 Woj> Precisely, that is possible on a per application basis. Having = the flag would make troubleshooting of a message flow much more explicit = (today, with any problem one has to browse the drafts to figure out what = MUST be there vs what SHOULD be there all while looking what is actually = there) =20 Regards, Woj. =20 regards, Stefaan =20 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = Of Wojciech Dec (wdec) Sent: donderdag 24 april 2008 14:19 To: Busser, M; ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 Hi Michael, =20 inline... ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = Of Busser, M Sent: 24 April 2008 13:13 To: ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 Hi Woi, all =20 I see the problem but i can not see, how an additional flag will help = solving this problem. =20 Lets assume your first proposal. If an implementation does not send the complete TLV, even it is = defined to be mandatory, I would call this a bug and I can not see, how = an additional flag can help here.=20 =20 Woj> The way it helps, and other protocols bear proof of this scheme, = is that it is easier for implementations to reconcile errors resulting = out of "Mandatory" and "Optional" TLV sets. The key to this lies on a = per application basis. One application may mandate TLV A for operation, = while another might not. Resolving such issues when implementing or = troubleshooting multiple applications is not always trivial.=20 =20 Your second proposal seems obviously be required to keep existing = things working, if we agree on your first proposal.=20 But from my point of view it also assumes, that all existing = implementations are using the same set of TLVs now.=20 And I am not sure about that. =20 =20 Woj> This would be a good thing for the WG to discuss. There most = evidently is a fair amount of "dead wood" in the current spec, ie stuff = that nobody yet implements or cares about. In the former case, we could = re-cast that material using the new notions/extensions, in the latter = case simply chop it out. =20 Therefore I disagree with your first proposal. I recommend, the = better way will be to be more precise in definitions.=20 In my mind, it is a bug, if a mandatory TLV is missing. It is up to = the robustness of the implementation to deal with this situation. Is it really neccesary to define the behavior of a network element in = this case of failure in the ancp protocol itself? =20 =20 Woj> Other people have faced this problem before, and I would rather = go with the lessons they learned, rather than clinging to hopes of = perfect textual definitions and implementations. Other than backwards = compatibility, I do not see in your statements a valid reason to object = to the 1st proposal, particularly for new applications since it can only = make things more robust. The counter argument of being precise in the = definitions, as evidenced by the current spec, is admirable and needs to = be there, with this proposal providing an extra level of robustness and = visibility of any problems.=20 =20 Thanks, Woj. =20 If optional TLVs are not present in a message, we should describe = some kind of default behaviour, as you already stated. =20 =20 =20 =20 =09 Comments on draft-ietf-ancp-protocol-02.txt: =20 It is not clearly stated, if the TLV "DSL Line Attributes " is = mandatory or optional.=20 In fact it is mandatory because some of its SubTLVs are mandatory.=20 We should spent a sentence to make this clear. =20 It is not clearly stated, if the TLV "Service-Profile-Name" is = mandatory or optional. I prefer mandatory because it is essetial for the use case Line = Config.=20 =09 =20 Section 5.4.3 Line Config, where the TLVs are mentioned (page 35): ...defined in section 5.4.1.... must be corrected to = ...defined in section 5.4.2........ =20 =09 Section 5.4.4 OAM, where the TLVs are mentioned (page 36 and page = 38): ...defined in section 5.4.1.... must be corrected to = ...defined in section 5.4.2........ =20 =20 =20 =20 Best Regards; Freundliche Gr=FC=DFe=20 Michael Busser =09 T-Systems Enterprise Services GmbH=20 Production Line Network Centric Systems ICT-Systems Integration Network Integration Services =20 Br=FCckes 2 -8, 55545 Bad Kreuznach Postfach 9100, 55541 Bad Kreuznach +49 671 8333 8911 (Phone) +49 521 9210 3859 (Fax) +49 151 1211 9689 (Mobile) E-Mail: michael.busser@t-systems.com =09 Internet: http://www.t-systems.com <http://www.t-systems.com/> =20 =09 =20 T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Reinhard Clemens (Vorsitzender)*, Helmut Binder, = Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Wilfried = Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG =20 Notice: This transmittal and/or attachments may be privileged or = confidential. If you are not the intended recipient, you are hereby = notified that you have received this transmittal in error; any review, = dissemination, or copying is strictly prohibited. If you received this = transmittal in error, please notify us immediately by reply and = immediately delete this message and all its attachments. Thank you.=20 T-Systems - Business flexibility=20 =20 =09 =09 ________________________________ Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag = von Wojciech Dec (wdec) Gesendet: Mittwoch, 23. April 2008 14:54 An: ancp@ietf.org Betreff: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal =20 Hi All,=20 Continuing with the series of e-mails regarding basic protocol = issues still to be addressed, I now would now like to ask your feedback = regarding the distinction the protocol places on mandatory TLVs. Given = the length of this mail I'll first cut to the proposal, and after it you = can find the problem description. The proposal which I am putting in front of the WG is to define a = new TLV format which contains at a minimum a Mandatory flag (much like = Radius VSAs do). We could have this TLV Flag be defined only for new = applications. A second proposal would be try to make this flag work with existing = ones by for example defining the highest order bit of the TLV# field to = mean "Mandatory" when set to "0". This would be invisible to exiting = implementations, but newer ones may have problems in communicating with = older ones when the latter do not send all TLVs. But that can also be = addressed by simply forming the set of mandatory TLVs to be the ones = that all implementations currently send by default. Without additional feedback, I will assume that the WG is fine with = the first proposal, and also with the 2nd one conditional on deriving a = suitable "commonly used" TLV set. The problem in more detail:=20 Currently the situation is that Mandatory TLVs are only stated to be = as such in the body of the protocol draft spec, with an implementer = having to scour fairly attentively the text. Eg "Type = (Access-Loop-Circuit-ID =3D 0x01): This is a mandatory TLV", etc. The behaviour of an implementation that receives a message with a = missing mandatory TLV is not defined at all, and the opposite is handled = but not very robustly, i.e. when receiving a TLV but not recognizing it, = and implementation is free to discard it (even if it is mandatory!). = This is a recipe for interoperability problems and an implementation = mine field. This problem is complicated by different applications. For example = the current OAM section states the following regarding TLVs that are to = be carried in the request message (my italics): "=20 Following TLVs can appear in this message:=20 o Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section = 5.4.1 =20 o Type (Access-Aggregation-Circuit-ID-Binary =3D 0x06): = defined in=20 section 5.4.1.=20 =20 o Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03): = defined in section=20 5.4.1. =20 o Type (OAM-Loopback-Test-Parameters =3D 0x07): Parameters = related to =20 loopback test. This is an optional TLV. If this TLV is not = present=20 in the request message, the DSLAM SHOULD use locally = determined=20 default values for the test parameters. =20 "=20 (NOTE: The last "SHOULD" appears to be inappropriate. If the TLV is = missing, the DSLAM MUST have some default parameters, or return an = error) The "can" above indicates that they're all optional, while clearly = the application cannot run its course without one or more of these = fields. Here we have a case where one could have a perfectly compliant = implementation that ignores all these TLVs... -Woj.=20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 ------_=_NextPart_001_01C8A966.B261D946 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns:v =3D "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word" xmlns:p =3D=20 "urn:schemas-microsoft-com:office:powerpoint"><HEAD><TITLE>Nachricht</TIT= LE> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2900.3314" name=3DGENERATOR><!--[if !mso]> <STYLE>v\:* { BEHAVIOR: url(#default#VML) } o\:* { BEHAVIOR: url(#default#VML) } w\:* { BEHAVIOR: url(#default#VML) } .shape { BEHAVIOR: url(#default#VML) } </STYLE> <![endif]--> <STYLE>@font-face { font-family: Tahoma; } @page Section1 {size: 595.3pt 841.9pt; margin: 70.85pt 70.85pt 2.0cm = 70.85pt; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline } A:visited { COLOR: purple; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline } P { FONT-SIZE: 12pt; MARGIN-LEFT: 0cm; MARGIN-RIGHT: 0cm; FONT-FAMILY: = "Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto } SPAN.E-MailFormatvorlage18 { COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply } DIV.Section1 { page: Section1 } </STYLE> </HEAD> <BODY lang=3DDE vLink=3Dpurple link=3Dblue> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial = size=3D2></FONT> </DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> DE CNODDER Stefaan=20 [mailto:stefaan.de_cnodder@alcatel-lucent.be] <BR><B>Sent:</B> 28 = April 2008=20 17:15<BR><B>To:</B> Wojciech Dec (wdec); Busser, M;=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> RE: [ANCP] = Mandatory=20 TLVs in draft-ietf-ancp-protocol proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>Take the bandwidth = sub-TLV in port=20 up messages as example.  The current protocol spec says that it = is=20 mandatory to be sent in port up messages.  that's ok.  = But it=20 is not mandatory for the receiver to process the bandwidth = sub-TLV.  What=20 is done with this information by the NAS is not specified by ANCP, so = you=20 cannot make it mandatory for the receiver side.<SPAN=20 class=3D163161615-28042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D163161615-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008><FONT color=3D#000000>Woj> Is the = information=20 required by the application? It would appear for the dynamic shaping = use-case=20 to be most certainly so. Hence it is absolutely mandatory, otherwise = the=20 message makes no sense for the application.</FONT> <FONT = color=3D#000000>In=20 any case, if </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>So it looks to me = that the flag=20 can only indicate what the receiver should do.  Then the flag = makes=20 sense.<SPAN class=3D163161615-28042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D163161615-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008><FONT color=3D#000000>Woj> = </FONT> <FONT=20 color=3D#000000>The flag tells the receiver what info the sender = thinks is=20 required to carry out the application. This in almost all cases has to = match=20 up to what the receiver thinks is required. The=20 sender </FONT></SPAN></FONT></FONT></FONT></SPAN><SPAN=20 class=3D436050615-28042008><FONT color=3D#0000ff><FONT = face=3DArial><FONT=20 size=3D2><SPAN class=3D163161615-28042008><FONT = color=3D#000000>doesn't tell the=20 receiver what to do with the=20 info.</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>If the receiver = knows what is=20 mandatory, then I do not see a reason why this has to be made explicit = in the=20 protocol.  It would only complicate the protocol.  As = already said=20 by Michael: if a mandatory TLV is not there, then it is just a = bug.<SPAN=20 class=3D163161615-28042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D163161615-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008><FONT color=3D#000000>Woj> Can you = specifically=20 describe what aspect of the protocol does it = complicate?</FONT> <FONT=20 color=3D#000000>It's just making explicitly clear what the protocol = already has=20 to implement anyway to be of any=20 use.</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = size=3D+0><FONT=20 face=3DArial><FONT size=3D2><SPAN class=3D163161615-28042008>As to = whether it is a=20 bug, having such explicit marking makes it clear what/where the = problem is=20 when observing a messaging flow vs a lot of deduction work. In = any case,=20 the other point being made here is that today the protocol does = NOT=20 specify what should happen if a mandatory TLV is=20 missing.</SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = size=3D+0><FONT=20 face=3DArial><FONT size=3D2><SPAN=20 = class=3D163161615-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = size=3D+0><FONT=20 face=3DArial><FONT size=3D2><SPAN=20 = class=3D163161615-28042008>-Woj.</SPAN></FONT></FONT></FONT></SPAN></DIV>= <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Stefaan</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV><BR> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com] <BR><B>Sent:</B> maandag 28 april 2008=20 16:28<BR><B>To:</B> DE CNODDER Stefaan; Busser, M; = ancp@ietf.org<BR><B>Cc:</B>=20 Haag, T<BR><B>Subject:</B> RE: [ANCP] Mandatory TLVs in=20 draft-ietf-ancp-protocol proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D560491614-28042008><FONT = face=3DArial=20 size=3D2>It's actually a mix of both. = Inline...</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>DE CNODDER=20 Stefaan<BR><B>Sent:</B> 28 April 2008 16:04<BR><B>To:</B> Wojciech = Dec=20 (wdec); Busser, M; ancp@ietf.org<BR><B>Cc:</B> Haag, = T<BR><B>Subject:</B>=20 Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol=20 proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Hi,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>This new mandatory flag, what is exactly = its=20 meaning?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>(1) if flag = set to=20 "mandatory", then the *receiver* of this TLV MUST process it, and if = unrecognized must drop the message<SPAN = class=3D560491614-28042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>If a received TLV = is has=20 the "mandatory" flag set then the receiver MUST drop the = message=20 and report an error to the sender if it doesn't recognize the=20 TLV.</FONT> </SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>If a the receiver = expects=20 a "mandatory" TLV but doesn't receive it, the message MUST = be droped and an error report sent to=20 = the sender.</FONT> </SPAN></FONT></FONT></FONT></SPAN></SPAN></= FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>OR</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>(2) if flag = is set=20 to"mandatory", then the *sender* MUST include it in the message for = which it=20 is defined<SPAN class=3D560491614-28042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>The sender MUST = include=20 mandatory TLVs as defined by the=20 = protocol-spec/applications.</FONT></SPAN></FONT></FONT></FONT></SPAN></DI= V> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>The current protocols draft says for = certain TLVs that=20 they are mandatory, but that applies to the sender of it = (interpretation=20 2).  The flag would indicate interpretation 1 (like for Radius=20 VSAs?)?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>If the higher = order bit is set=20 to "0" means that it is mandatory, then currently defined optional = defined=20 TLVs suddenly become mandatory which is not good.<SPAN=20 class=3D560491614-28042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>Woj> Only the = currently used=20 TLVs become mandatory. If they are not used/implemented we can=20 re-define them as optional (set flag to 1) at no cost.=20 </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>But I would first = to understand=20 the exact meaning of this mandatory flag.  Defining such a flag = indeed=20 looks useful but then as interpretation 1, and I would say that if = flag set=20 to 1, then it is mandatory and actually, it is possible that a TLV = is sent=20 sometimes as optional and sometimes as mandatory.<SPAN=20 class=3D560491614-28042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>Woj> Precisely, = that is=20 possible on a per application basis.</FONT> <FONT = color=3D#000000>Having=20 the flag would make troubleshooting of a message flow much more = explicit (today, with any problem one has to browse the drafts = to=20 figure out what MUST be there vs what SHOULD be there all while = looking what is actually=20 there)</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 = size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 = size=3D2><SPAN=20 = class=3D560491614-28042008>Regards,</SPAN></FONT></FONT></FONT></SPAN></D= IV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 = size=3D2><SPAN=20 = class=3D560491614-28042008>Woj.</SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 = size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Stefaan</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT> </DIV><BR> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>Wojciech Dec=20 (wdec)<BR><B>Sent:</B> donderdag 24 april 2008 14:19<BR><B>To:</B> = Busser,=20 M; ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> Re: [ANCP] = Mandatory TLVs in draft-ietf-ancp-protocol = proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D709295811-24042008><FONT = face=3DArial=20 size=3D2>Hi Michael,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D709295811-24042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D709295811-24042008><FONT = face=3DArial=20 size=3D2>inline...</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 = 2px solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>Busser,=20 M<BR><B>Sent:</B> 24 April 2008 13:13<BR><B>To:</B>=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> Re: [ANCP]=20 Mandatory TLVs in draft-ietf-ancp-protocol = proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Hi Woi,=20 all</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>I see the=20 problem but i can not see, how an additional flag will help = solving this=20 problem.</FONT></SPAN></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Lets assume=20 your first proposal.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT=20 size=3D2>If an implementation does not send the = complete TLV, even=20 it is defined to be mandatory, I would call this a = bug=20 and I can not see, how an additional flag can help here.<SPAN = = class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 = class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Woj> The way it helps, and other = protocols=20 bear proof of this scheme, is that it is easier for = implementations to=20 reconcile errors resulting out of "Mandatory" and = "Optional" TLV=20 sets. The key to this lies on a per application basis. One = application may=20 mandate TLV A for operation, while another might not. Resolving = such=20 issues when implementing or troubleshooting multiple applications = is not=20 always trivial. </SPAN></FONT></FONT></SPAN><SPAN=20 class=3D364043506-24042008><FONT face=3DArial><FONT size=3D2><SPAN = class=3D709295811-24042008></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 = class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Your second=20 proposal seems obviously be required to keep existing things = working,=20 if we agree on your first proposal. </FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>But from my=20 point of view it also assumes, that all existing = implementations are=20 using the same set of TLVs now. </FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT=20 size=3D2>And I am not sure about that. <SPAN=20 = class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 = class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Woj> This would be a good thing for = the WG to=20 discuss. There most evidently is a fair amount of "dead wood" = in the=20 current spec, ie stuff that nobody yet implements or cares = about.=20  In the former case, we could re-cast that material using the = new=20 notions/extensions, in the latter case simply chop it=20 out.</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2><SPAN=20 class=3D364043506-24042008><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV></FONT></SPAN> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT=20 size=3D2>Therefore I disagree with your first proposal. I = recommend, the=20 better way will be to be more precise in definitions.<SPAN=20 = class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>In my mind, it=20 is a bug, if a mandatory TLV is missing. It is up to the = robustness of the=20 implementation to deal with this = situation.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2>Is it=20 really neccesary to define the behavior of a network element in = this case=20 of failure in the ancp protocol itself? <SPAN=20 = class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 = class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Woj> Other people have faced this = problem=20 before, and I would rather go with the lessons they learned, = rather than=20 clinging to hopes of perfect textual definitions and = implementations.=20 Other than backwards compatibility, I do not see in your = statements a=20 valid reason to object to the 1st proposal, particularly = for new=20 applications since it can only make things more robust. The = counter=20 argument of being precise in the definitions, as evidenced by the = current=20 spec, is admirable and needs to be there, with this proposal = providing an=20 extra level of robustness and visibility of any problems.=20 </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 = class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 = class=3D709295811-24042008>Thanks,</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Woj.</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>If optional=20 TLVs are not present in a message, we should describe some kind of = default=20 behaviour, as you already stated.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Comments on=20 = draft-ietf-ancp-protocol-02.txt:</FONT></SPAN></DIV></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT = face=3DArial>It is=20 not clearly stated, if the TLV  "<SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA">DSL=20 Line Attributes "<FONT face=3DArial> is mandatory or optional.=20 </FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT = face=3DArial><SPAN=20 lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>In fact it is mandatory because some of its SubTLVs = are=20 mandatory. </FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT = face=3DArial><SPAN=20 lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>We should spent a sentence to make this=20 clear.</FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2><SPAN=20 class=3D364043506-24042008><FONT size=3D2><FONT face=3DArial>It is = not clearly=20 stated, if the TLV  "<SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: = AR-SA">Service-Profile-Name"<FONT=20 face=3DArial> is mandatory or=20 optional.</FONT></SPAN></FONT></FONT></SPAN></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2><SPAN=20 class=3D364043506-24042008><FONT size=3D2><FONT face=3DArial><SPAN = lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>I prefer mandatory because it is essetial for the use = case Line=20 = Config. </FONT></SPAN></FONT></FONT></SPAN></DIV></FONT></SPAN><SPAN= =20 class=3D364043506-24042008><FONT face=3DArial = size=3D2></FONT></SPAN> <DIV><SPAN class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Section 5.4.3=20 Line Config, where the TLVs are mentioned (page = 35):</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2> =20 ...defined in section 5.4.1....    must be = corrected=20 to    ...defined in section=20 5.4.2........</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Section=20 5.4.4 OAM, where the TLVs are mentioned (page 36 and page=20 38):</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2> =20 ...defined in section 5.4.1....    must be = corrected=20 to    ...defined in section=20 5.4.2........</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV></FONT></SPAN><SPAN class=3D364043506-24042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV></DIV> <DIV><SPAN class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN = class=3D364043506-24042008><FONT=20 face=3DArial color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV align=3Dleft><FONT color=3D#000080 size=3D2> <P align=3Dleft>Best Regards; Freundliche Gr=FC=DFe = </P></FONT><B><FONT=20 color=3D#000080> <P>Michael Busser</P></B></FONT><FONT size=3D1> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt">T-Systems=20 Enterprise Services GmbH </SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1>Production Line Network Centric = Systems</FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1>ICT-Systems Integration</FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1>Network Integration Services</FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1></FONT><SPAN style=3D"COLOR: navy"></SPAN><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy"><FONT face=3DArial = color=3D#000000=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy"><FONT color=3D#000000 = size=3D1>Br=FCckes 2=20 -8, 55545 Bad Kreuznach<BR>Postfach 9100, 55541 Bad = Kreuznach<BR>+49 671=20 8333 8911 (Phone)<BR>+49 521 9210 3859 (Fax)<BR>+49 151=20 1211 9689 (Mobile)<BR>E-Mail: <A=20 = href=3D"mailto:michael.busser@t-systems.com">michael.busser@t-systems.com= </A></FONT></SPAN></DIV></SPAN> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN></DIV><SPAN style=3D"FONT-SIZE: = 8pt">Internet:=20 </SPAN><SPAN style=3D"FONT-SIZE: 8pt"><p:onmouseclick=20 href=3D"http://www.t-systems.com/" = hyperlinktype=3D"url"></p:onmouseclick><A=20 onclick=3Dwindow.event.cancelBubble=3Dtrue; = href=3D"http://www.t-systems.com/"=20 target=3D_parent><FONT=20 color=3D#6699ff>http://www.t-systems.com</FONT></A></SPAN><SPAN=20 style=3D"FONT-SIZE: 8pt"> </SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN> </DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D3><FONT size=3D1><SPAN=20 style=3D"FONT-SIZE: 7.5pt; COLOR: black; FONT-FAMILY: = Arial">T-Systems=20 Enterprise Services GmbH<BR>Aufsichtsrat: Ren=E9 Obermann=20 (Vorsitzender)<BR>Executive Committee: Reinhard Clemens = (Vorsitzender)*,=20 Helmut Binder, Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich = Kemp,=20 Wilfried Peters*,<BR>Dr. Herbert Schaaff*, Zvezdana=20 Seeger*<BR>Handelsregister: Amtsgericht Frankfurt am Main HRB=20 55933<BR>Sitz der Gesellschaft: Frankfurt am Main<BR>WEEE-Reg.-Nr. = DE87523644<BR>*Gesch=E4ftsf=FChrer gem. =A7 35=20 GmbHG</SPAN></FONT></FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT face=3DArial=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT size=3D1>Notice: This transmittal = and/or=20 attachments may be privileged or confidential. If you are not the = intended=20 recipient, you are hereby notified that you have received this = transmittal=20 in error; any review, dissemination, or copying is strictly = prohibited. If=20 you received this transmittal in error, please notify us = immediately by=20 reply and immediately delete this message and all its attachments. = Thank=20 you. </FONT><FONT size=3D1><BR>T-Systems =96 Business flexibility=20 </FONT></DIV></SPAN></SPAN> <DIV><FONT face=3DArial size=3D2></FONT> </DIV></FONT></DIV> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"> <DIV></DIV> <DIV class=3DOutlookMessageHeader lang=3Dde dir=3Dltr = align=3Dleft> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy = size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: = Arial"><o:p></o:p></SPAN></FONT></P><FONT=20 face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: = 12pt"><FONT=20 face=3DArial size=3D2></FONT> <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2> </SPAN></FONT></DIV> <DIV class=3DSection1> <DIV> <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: = Tahoma">Von:</SPAN></FONT></B><FONT=20 face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; = FONT-FAMILY: Tahoma">=20 ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] <B><SPAN=20 style=3D"FONT-WEIGHT: bold">Im Auftrag von </SPAN></B>Wojciech = Dec=20 (wdec)<BR><B><SPAN style=3D"FONT-WEIGHT: = bold">Gesendet:</SPAN></B>=20 Mittwoch, 23. April 2008 14:54<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">An:</SPAN></B> = ancp@ietf.org<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Betreff:</SPAN></B> [ANCP] Mandatory = TLVs in=20 draft-ietf-ancp-protocol = proposal</SPAN></FONT><o:p></o:p></P></DIV> <P class=3DMsoNormal><FONT face=3D"Times New Roman" = size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi = All,</SPAN></FONT><SPAN=20 lang=3DEN-GB> </SPAN><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Continuing with = the series=20 of e-mails regarding basic protocol issues still to be = addressed, I now=20 would now like to ask your feedback regarding the distinction = the=20 protocol places on mandatory TLVs. Given the length of this mail = I'll=20 first cut to the proposal, and after it you can find the problem = description.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The proposal which = I am=20 putting in front of the WG is to define a new TLV format which = contains=20 at a minimum a Mandatory flag (much like Radius VSAs do). We = could have=20 this TLV Flag be defined only for new=20 applications.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">A second proposal = would be=20 try to make this flag work with existing ones by for example = defining=20 the highest order bit of the TLV# field to mean "Mandatory" when = set to=20 "0". This would be invisible to exiting implementations, but = newer ones=20 may have problems in communicating with older ones when the = latter do=20 not send all TLVs. But that can also be addressed by simply = forming the=20 set of mandatory TLVs to be the ones that all implementations = currently=20 send by default.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Without additional = feedback,=20 I will assume that the WG is fine with the first proposal, and = also with=20 the 2nd one conditional on deriving a suitable "commonly used" = TLV=20 set.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The problem in = more detail:=20 </SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Currently the = situation is=20 that Mandatory TLVs are only stated to be as such in the body of = the=20 protocol draft spec, with an implementer having to scour fairly=20 attentively the text. Eg "Type (Access-Loop-Circuit-ID =3D = 0x01): This is=20 a mandatory TLV", etc.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The behaviour of = an=20 implementation that receives a message with a missing mandatory = TLV is=20 not defined at all, and the opposite is handled but not very = robustly,=20 i.e. when receiving a TLV but not recognizing it, and = implementation is=20 free to discard it (even if it is mandatory!). This is a recipe = for=20 interoperability problems and an implementation mine=20 field.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">This problem is = complicated=20 by different applications. For example the current OAM section = states=20 the following regarding TLVs that are to be carried in the = request=20 message (my italics):</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">"</SPAN></FONT> = <BR><FONT=20 face=3D"Courier New" color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">Following=20 TLVs<B><I><SPAN style=3D"FONT-WEIGHT: bold; FONT-STYLE: italic"> = can</SPAN></I></B> appear in this message: = </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section=20 5.4.1    </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (Access-Aggregation-Circuit-ID-Binary =3D 0x06): defined = in=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 section 5.4.1. </SPAN></FONT><BR><FONT face=3D"Courier New" = color=3Dblack=20 size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'"> </SPAN></FONT>=20 <BR><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03): defined = in section=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 5.4.1.  </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (OAM-Loopback-Test-Parameters =3D 0x07): Parameters = related=20 to  </SPAN></FONT><BR><FONT face=3D"Courier New" = color=3Dblack=20 size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 loopback test. This is an optional TLV. If this TLV is not = present=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 in the request message, the DSLAM SHOULD use locally determined=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 default values for the test parameters.  = </SPAN></FONT><BR><FONT=20 face=3D"Courier New" color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">"</SPAN></FONT>=20 <BR><FONT face=3DArial color=3Dblack size=3D2><SPAN lang=3DEN-US = style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = Arial">(NOTE: The=20 last "SHOULD" appears to be inappropriate. If the TLV is = missing, the=20 DSLAM MUST have some default parameters, or return an=20 error)</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">The = "can"=20 above indicates that they're all optional, while clearly the = application=20 cannot run its course without one or more of these fields. Here = we have=20 a case where one could have a perfectly compliant implementation = that=20 ignores all these TLVs=85</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = Arial">-Woj.</SPAN></FONT><SPAN=20 lang=3DEN-US> </SPAN><o:p></o:p></P> <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><FONT=20 face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: = 12pt"><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><o:p></o:p></SPAN></FONT></= P></DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML= > ------_=_NextPart_001_01C8A966.B261D946-- --===============1920464201== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============1920464201==-- From ancp-bounces@ietf.org Tue Apr 29 00:51:45 2008 Return-Path: <ancp-bounces@ietf.org> X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1607D3A69D2; Tue, 29 Apr 2008 00:51:45 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35FA23A69D9 for <ancp@core3.amsl.com>; Tue, 29 Apr 2008 00:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xawc9BxeFPAI for <ancp@core3.amsl.com>; Tue, 29 Apr 2008 00:51:37 -0700 (PDT) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id DD9A03A6AA7 for <ancp@ietf.org>; Tue, 29 Apr 2008 00:51:35 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m3T7hEXK027144; Tue, 29 Apr 2008 09:43:14 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 29 Apr 2008 09:51:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Apr 2008 09:51:34 +0200 Message-ID: <7A6D4815C5E8F74988784FEBD50F2F1E01ABAC34@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <D9872168DBD43A41BD71FFC4713274D404FF1233@xmb-ams-33b.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal Thread-Index: AcilQRMfK4kdawUKQOWs5fdBngS8QQAAr04QACRhApAAC0ujAADNHRywAADiEXAAAbhxoAAAWwcQACIOoKA= References: <1B6169C658325341A3B8066E23919E1C01230DC1@S4DE8PSAANK.mitte.t-com.de><1B6169C658325341A3B8066E23919E1CFBC5C4@S4DE8PSAANK.mitte.t-com.de><D9872168DBD43A41BD71FFC4713274D404FA6ACC@xmb-ams-33b.emea.cisco.com> <7A6D4815C5E8F74988784FEBD50F2F1E01ABAA16@FRVELSMBS22.ad2.ad.alcatel.com> <D9872168DBD43A41BD71FFC4713274D404FF10C1@xmb-ams-33b.emea.cisco.com> <7A6D4815C5E8F74988784FEBD50F2F1E01ABAAA4@FRVELSMBS22.ad2.ad.alcatel.com> <D9872168DBD43A41BD71FFC4713274D404FF1233@xmb-ams-33b.emea.cisco.com> From: "DE CNODDER Stefaan" <stefaan.de_cnodder@alcatel-lucent.be> To: "Wojciech Dec (wdec)" <wdec@cisco.com>, "Busser, M" <Michael.Busser@t-systems.com>, <ancp@ietf.org> X-OriginalArrivalTime: 29 Apr 2008 07:51:33.0526 (UTC) FILETIME=[D7E07360:01C8A9CD] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: "Haag, T" <Thomas.Haag@t-systems.com> Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list <ancp.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/ancp> List-Post: <mailto:ancp@ietf.org> List-Help: <mailto:ancp-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0981949343==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0981949343== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A9CD.D7944D7E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A9CD.D7944D7E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Hi Woj, =20 Take the following example: I have a network with 2 NASses, NAS-A is = doing hierarchical shaping, NAS-B just wants to have the port = information but is not doing hierarchical shaping (it is doing other = things like OAM, ...). This means NAS-A needs the bandwidth, while = NAS-B does not need the bandwidth. How should the flag be set in this = case by the AN? Set to 'Mandatory' for the port up messages to NAS-A, = and set to 'Optional' for port up messages towards NAS-B? Or is it = always set to 'Mandatory'? From your answer below, I understand that it = should be set to 'Optional' towards NAS-B. Is that correct? =20 NAS-B will simply ignore the bandwidth TLV. If such a flag would exist, = and the flag is set to 'Mandatory' by the AN to NAS-B, what should be = the behavior of NAS-B? Should it reject the whole message? Maybe NAS-B = is not supporting hierarchical shaping, so it might not support the = bandwidth TLV. Today, the bandwidht TLV is only mandatory to be put in = the port up messages, but for the receiver there is nothing mandatory. =20 I believe the original intend of ANCP was that the AN does not need to = know what the NAS is doing with this information, the use of the = bandwidth is also not specified by ANCP, only an example is given (which = is shaping). In the future there may be applications for which TLVs = will be mandatory which are now optional. =20 regards, Stefaan =20 =20 =20 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: maandag 28 april 2008 21:33 To: DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal =20 ________________________________ From: DE CNODDER Stefaan [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Sent: 28 April 2008 17:15 To: Wojciech Dec (wdec); Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal =09 =09 =20 Take the bandwidth sub-TLV in port up messages as example. The current = protocol spec says that it is mandatory to be sent in port up messages. = that's ok. But it is not mandatory for the receiver to process the = bandwidth sub-TLV. What is done with this information by the NAS is not = specified by ANCP, so you cannot make it mandatory for the receiver = side.=20 =20 Woj> Is the information required by the application? It would appear = for the dynamic shaping use-case to be most certainly so. Hence it is = absolutely mandatory, otherwise the message makes no sense for the = application. In any case, if=20 =20 So it looks to me that the flag can only indicate what the receiver = should do. Then the flag makes sense.=20 =20 Woj> The flag tells the receiver what info the sender thinks is = required to carry out the application. This in almost all cases has to = match up to what the receiver thinks is required. The sender doesn't = tell the receiver what to do with the info. =20 If the receiver knows what is mandatory, then I do not see a reason why = this has to be made explicit in the protocol. It would only complicate = the protocol. As already said by Michael: if a mandatory TLV is not = there, then it is just a bug.=20 =20 Woj> Can you specifically describe what aspect of the protocol does it = complicate? It's just making explicitly clear what the protocol already = has to implement anyway to be of any use. As to whether it is a bug, having such explicit marking makes it clear = what/where the problem is when observing a messaging flow vs a lot of = deduction work. In any case, the other point being made here is that = today the protocol does NOT specify what should happen if a mandatory = TLV is missing. =20 -Woj. =20 regards, Stefaan =20 =20 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: maandag 28 april 2008 16:28 To: DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal =09 =09 It's actually a mix of both. Inline... ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = Of DE CNODDER Stefaan Sent: 28 April 2008 16:04 To: Wojciech Dec (wdec); Busser, M; ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 =20 Hi, =20 This new mandatory flag, what is exactly its meaning? =20 (1) if flag set to "mandatory", then the *receiver* of this TLV MUST = process it, and if unrecognized must drop the message=20 =20 If a received TLV is has the "mandatory" flag set then the receiver = MUST drop the message and report an error to the sender if it doesn't = recognize the TLV.=20 If a the receiver expects a "mandatory" TLV but doesn't receive it, = the message MUST be droped and an error report sent to the sender.=20 =20 OR =20 (2) if flag is set to"mandatory", then the *sender* MUST include it in = the message for which it is defined=20 =20 The sender MUST include mandatory TLVs as defined by the = protocol-spec/applications. =20 The current protocols draft says for certain TLVs that they are = mandatory, but that applies to the sender of it (interpretation 2). The = flag would indicate interpretation 1 (like for Radius VSAs?)? =20 If the higher order bit is set to "0" means that it is mandatory, then = currently defined optional defined TLVs suddenly become mandatory which = is not good.=20 =20 Woj> Only the currently used TLVs become mandatory. If they are not = used/implemented we can re-define them as optional (set flag to 1) at no = cost.=20 =20 But I would first to understand the exact meaning of this mandatory = flag. Defining such a flag indeed looks useful but then as = interpretation 1, and I would say that if flag set to 1, then it is = mandatory and actually, it is possible that a TLV is sent sometimes as = optional and sometimes as mandatory.=20 =20 Woj> Precisely, that is possible on a per application basis. Having = the flag would make troubleshooting of a message flow much more explicit = (today, with any problem one has to browse the drafts to figure out what = MUST be there vs what SHOULD be there all while looking what is actually = there) =20 Regards, Woj. =20 regards, Stefaan =20 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = Of Wojciech Dec (wdec) Sent: donderdag 24 april 2008 14:19 To: Busser, M; ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 Hi Michael, =20 inline... ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = Of Busser, M Sent: 24 April 2008 13:13 To: ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 Hi Woi, all =20 I see the problem but i can not see, how an additional flag will help = solving this problem. =20 Lets assume your first proposal. If an implementation does not send the complete TLV, even it is = defined to be mandatory, I would call this a bug and I can not see, how = an additional flag can help here.=20 =20 Woj> The way it helps, and other protocols bear proof of this scheme, = is that it is easier for implementations to reconcile errors resulting = out of "Mandatory" and "Optional" TLV sets. The key to this lies on a = per application basis. One application may mandate TLV A for operation, = while another might not. Resolving such issues when implementing or = troubleshooting multiple applications is not always trivial.=20 =20 Your second proposal seems obviously be required to keep existing = things working, if we agree on your first proposal.=20 But from my point of view it also assumes, that all existing = implementations are using the same set of TLVs now.=20 And I am not sure about that. =20 =20 Woj> This would be a good thing for the WG to discuss. There most = evidently is a fair amount of "dead wood" in the current spec, ie stuff = that nobody yet implements or cares about. In the former case, we could = re-cast that material using the new notions/extensions, in the latter = case simply chop it out. =20 Therefore I disagree with your first proposal. I recommend, the = better way will be to be more precise in definitions.=20 In my mind, it is a bug, if a mandatory TLV is missing. It is up to = the robustness of the implementation to deal with this situation. Is it really neccesary to define the behavior of a network element in = this case of failure in the ancp protocol itself? =20 =20 Woj> Other people have faced this problem before, and I would rather = go with the lessons they learned, rather than clinging to hopes of = perfect textual definitions and implementations. Other than backwards = compatibility, I do not see in your statements a valid reason to object = to the 1st proposal, particularly for new applications since it can only = make things more robust. The counter argument of being precise in the = definitions, as evidenced by the current spec, is admirable and needs to = be there, with this proposal providing an extra level of robustness and = visibility of any problems.=20 =20 Thanks, Woj. =20 If optional TLVs are not present in a message, we should describe = some kind of default behaviour, as you already stated. =20 =20 =20 =20 =09 Comments on draft-ietf-ancp-protocol-02.txt: =20 It is not clearly stated, if the TLV "DSL Line Attributes " is = mandatory or optional.=20 In fact it is mandatory because some of its SubTLVs are mandatory.=20 We should spent a sentence to make this clear. =20 It is not clearly stated, if the TLV "Service-Profile-Name" is = mandatory or optional. I prefer mandatory because it is essetial for the use case Line = Config.=20 =09 =20 Section 5.4.3 Line Config, where the TLVs are mentioned (page 35): ...defined in section 5.4.1.... must be corrected to = ...defined in section 5.4.2........ =20 =09 Section 5.4.4 OAM, where the TLVs are mentioned (page 36 and page = 38): ...defined in section 5.4.1.... must be corrected to = ...defined in section 5.4.2........ =20 =20 =20 =20 Best Regards; Freundliche Gr=FC=DFe=20 Michael Busser =09 T-Systems Enterprise Services GmbH=20 Production Line Network Centric Systems ICT-Systems Integration Network Integration Services =20 Br=FCckes 2 -8, 55545 Bad Kreuznach Postfach 9100, 55541 Bad Kreuznach +49 671 8333 8911 (Phone) +49 521 9210 3859 (Fax) +49 151 1211 9689 (Mobile) E-Mail: michael.busser@t-systems.com =09 Internet: http://www.t-systems.com <http://www.t-systems.com/> =20 =09 =20 T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Reinhard Clemens (Vorsitzender)*, Helmut Binder, = Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Wilfried = Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG =20 Notice: This transmittal and/or attachments may be privileged or = confidential. If you are not the intended recipient, you are hereby = notified that you have received this transmittal in error; any review, = dissemination, or copying is strictly prohibited. If you received this = transmittal in error, please notify us immediately by reply and = immediately delete this message and all its attachments. Thank you.=20 T-Systems - Business flexibility=20 =20 =09 =09 ________________________________ Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag = von Wojciech Dec (wdec) Gesendet: Mittwoch, 23. April 2008 14:54 An: ancp@ietf.org Betreff: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal =20 Hi All,=20 Continuing with the series of e-mails regarding basic protocol = issues still to be addressed, I now would now like to ask your feedback = regarding the distinction the protocol places on mandatory TLVs. Given = the length of this mail I'll first cut to the proposal, and after it you = can find the problem description. The proposal which I am putting in front of the WG is to define a = new TLV format which contains at a minimum a Mandatory flag (much like = Radius VSAs do). We could have this TLV Flag be defined only for new = applications. A second proposal would be try to make this flag work with existing = ones by for example defining the highest order bit of the TLV# field to = mean "Mandatory" when set to "0". This would be invisible to exiting = implementations, but newer ones may have problems in communicating with = older ones when the latter do not send all TLVs. But that can also be = addressed by simply forming the set of mandatory TLVs to be the ones = that all implementations currently send by default. Without additional feedback, I will assume that the WG is fine with = the first proposal, and also with the 2nd one conditional on deriving a = suitable "commonly used" TLV set. The problem in more detail:=20 Currently the situation is that Mandatory TLVs are only stated to be = as such in the body of the protocol draft spec, with an implementer = having to scour fairly attentively the text. Eg "Type = (Access-Loop-Circuit-ID =3D 0x01): This is a mandatory TLV", etc. The behaviour of an implementation that receives a message with a = missing mandatory TLV is not defined at all, and the opposite is handled = but not very robustly, i.e. when receiving a TLV but not recognizing it, = and implementation is free to discard it (even if it is mandatory!). = This is a recipe for interoperability problems and an implementation = mine field. This problem is complicated by different applications. For example = the current OAM section states the following regarding TLVs that are to = be carried in the request message (my italics): "=20 Following TLVs can appear in this message:=20 o Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section = 5.4.1 =20 o Type (Access-Aggregation-Circuit-ID-Binary =3D 0x06): = defined in=20 section 5.4.1.=20 =20 o Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03): = defined in section=20 5.4.1. =20 o Type (OAM-Loopback-Test-Parameters =3D 0x07): Parameters = related to =20 loopback test. This is an optional TLV. If this TLV is not = present=20 in the request message, the DSLAM SHOULD use locally = determined=20 default values for the test parameters. =20 "=20 (NOTE: The last "SHOULD" appears to be inappropriate. If the TLV is = missing, the DSLAM MUST have some default parameters, or return an = error) The "can" above indicates that they're all optional, while clearly = the application cannot run its course without one or more of these = fields. Here we have a case where one could have a perfectly compliant = implementation that ignores all these TLVs... -Woj.=20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 ------_=_NextPart_001_01C8A9CD.D7944D7E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns:v =3D "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word" xmlns:p =3D=20 "urn:schemas-microsoft-com:office:powerpoint"><HEAD><TITLE>Nachricht</TIT= LE> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2900.3314" name=3DGENERATOR><!--[if !mso]> <STYLE>v\:* { BEHAVIOR: url(#default#VML) } o\:* { BEHAVIOR: url(#default#VML) } w\:* { BEHAVIOR: url(#default#VML) } .shape { BEHAVIOR: url(#default#VML) } </STYLE> <![endif]--> <STYLE>@font-face { font-family: Tahoma; } @page Section1 {size: 595.3pt 841.9pt; margin: 70.85pt 70.85pt 2.0cm = 70.85pt; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline } A:visited { COLOR: purple; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline } P { FONT-SIZE: 12pt; MARGIN-LEFT: 0cm; MARGIN-RIGHT: 0cm; FONT-FAMILY: = "Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto } SPAN.E-MailFormatvorlage18 { COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply } DIV.Section1 { page: Section1 } </STYLE> </HEAD> <BODY lang=3DDE vLink=3Dpurple link=3Dblue> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Hi Woj,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Take the following example: I have a network = with 2 NASses,=20 NAS-A is doing hierarchical shaping, NAS-B just wants to have the port=20 information but is not doing hierarchical shaping (it is doing other = things like=20 OAM, ...).  This means NAS-A needs the bandwidth, while NAS-B does = not need=20 the bandwidth.  How should the flag be set in this case by the = AN? =20 Set to 'Mandatory' for the port up messages to NAS-A, and set to = 'Optional' for=20 port up messages towards NAS-B? Or is it always set to = 'Mandatory'?  From=20 your answer below, I understand that it should be set to 'Optional' = towards=20 NAS-B.  Is that correct?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>NAS-B will simply ignore the bandwidth = TLV.  If such a=20 flag would exist, and the flag is set to 'Mandatory' by the AN to NAS-B, = what=20 should be the behavior of NAS-B?  Should it reject the whole = message? =20 Maybe NAS-B is not supporting hierarchical shaping, so it might not = support the=20 bandwidth TLV.  Today, the bandwidht TLV is only mandatory to be = put in the=20 port up messages, but for the receiver there is nothing=20 mandatory.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>I believe the original intend of ANCP was that = the AN does=20 not need to know what the NAS is doing with this information, the use of = the=20 bandwidth is also not specified by ANCP, only an example is given (which = is=20 shaping).  In the future there may be applications for which TLVs = will be=20 mandatory which are now optional.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Stefaan</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV><BR> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com] <BR><B>Sent:</B> maandag 28 april 2008=20 21:33<BR><B>To:</B> DE CNODDER Stefaan; Busser, M; = ancp@ietf.org<BR><B>Cc:</B>=20 Haag, T<BR><B>Subject:</B> RE: [ANCP] Mandatory TLVs in = draft-ietf-ancp-protocol=20 proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial = size=3D2></FONT> </DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> DE CNODDER Stefaan=20 [mailto:stefaan.de_cnodder@alcatel-lucent.be] <BR><B>Sent:</B> 28 = April 2008=20 17:15<BR><B>To:</B> Wojciech Dec (wdec); Busser, M;=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> RE: [ANCP] = Mandatory=20 TLVs in draft-ietf-ancp-protocol proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>Take the bandwidth = sub-TLV in port=20 up messages as example.  The current protocol spec says that it = is=20 mandatory to be sent in port up messages.  that's ok.  = But it=20 is not mandatory for the receiver to process the bandwidth = sub-TLV.  What=20 is done with this information by the NAS is not specified by ANCP, so = you=20 cannot make it mandatory for the receiver side.<SPAN=20 class=3D163161615-28042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D163161615-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008><FONT color=3D#000000>Woj> Is the = information=20 required by the application? It would appear for the dynamic shaping = use-case=20 to be most certainly so. Hence it is absolutely mandatory, otherwise = the=20 message makes no sense for the application.</FONT> <FONT = color=3D#000000>In=20 any case, if </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>So it looks to me = that the flag=20 can only indicate what the receiver should do.  Then the flag = makes=20 sense.<SPAN class=3D163161615-28042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D163161615-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008><FONT color=3D#000000>Woj> = </FONT> <FONT=20 color=3D#000000>The flag tells the receiver what info the sender = thinks is=20 required to carry out the application. This in almost all cases has to = match=20 up to what the receiver thinks is required. The=20 sender </FONT></SPAN></FONT></FONT></FONT></SPAN><SPAN=20 class=3D436050615-28042008><FONT color=3D#0000ff><FONT = face=3DArial><FONT=20 size=3D2><SPAN class=3D163161615-28042008><FONT = color=3D#000000>doesn't tell the=20 receiver what to do with the=20 info.</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>If the receiver = knows what is=20 mandatory, then I do not see a reason why this has to be made explicit = in the=20 protocol.  It would only complicate the protocol.  As = already said=20 by Michael: if a mandatory TLV is not there, then it is just a = bug.<SPAN=20 class=3D163161615-28042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D163161615-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008><FONT color=3D#000000>Woj> Can you = specifically=20 describe what aspect of the protocol does it = complicate?</FONT> <FONT=20 color=3D#000000>It's just making explicitly clear what the protocol = already has=20 to implement anyway to be of any=20 use.</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = size=3D+0><FONT=20 face=3DArial><FONT size=3D2><SPAN class=3D163161615-28042008>As to = whether it is a=20 bug, having such explicit marking makes it clear what/where the = problem is=20 when observing a messaging flow vs a lot of deduction work. In = any case,=20 the other point being made here is that today the protocol does = NOT=20 specify what should happen if a mandatory TLV is=20 missing.</SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = size=3D+0><FONT=20 face=3DArial><FONT size=3D2><SPAN=20 = class=3D163161615-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = size=3D+0><FONT=20 face=3DArial><FONT size=3D2><SPAN=20 = class=3D163161615-28042008>-Woj.</SPAN></FONT></FONT></FONT></SPAN></DIV>= <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Stefaan</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV><BR> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com] <BR><B>Sent:</B> maandag 28 april 2008=20 16:28<BR><B>To:</B> DE CNODDER Stefaan; Busser, M; = ancp@ietf.org<BR><B>Cc:</B>=20 Haag, T<BR><B>Subject:</B> RE: [ANCP] Mandatory TLVs in=20 draft-ietf-ancp-protocol proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D560491614-28042008><FONT = face=3DArial=20 size=3D2>It's actually a mix of both. = Inline...</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>DE CNODDER=20 Stefaan<BR><B>Sent:</B> 28 April 2008 16:04<BR><B>To:</B> Wojciech = Dec=20 (wdec); Busser, M; ancp@ietf.org<BR><B>Cc:</B> Haag, = T<BR><B>Subject:</B>=20 Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol=20 proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Hi,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>This new mandatory flag, what is exactly = its=20 meaning?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>(1) if flag = set to=20 "mandatory", then the *receiver* of this TLV MUST process it, and if = unrecognized must drop the message<SPAN = class=3D560491614-28042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>If a received TLV = is has=20 the "mandatory" flag set then the receiver MUST drop the = message=20 and report an error to the sender if it doesn't recognize the=20 TLV.</FONT> </SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>If a the receiver = expects=20 a "mandatory" TLV but doesn't receive it, the message MUST = be droped and an error report sent to=20 = the sender.</FONT> </SPAN></FONT></FONT></FONT></SPAN></SPAN></= FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>OR</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>(2) if flag = is set=20 to"mandatory", then the *sender* MUST include it in the message for = which it=20 is defined<SPAN class=3D560491614-28042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>The sender MUST = include=20 mandatory TLVs as defined by the=20 = protocol-spec/applications.</FONT></SPAN></FONT></FONT></FONT></SPAN></DI= V> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>The current protocols draft says for = certain TLVs that=20 they are mandatory, but that applies to the sender of it = (interpretation=20 2).  The flag would indicate interpretation 1 (like for Radius=20 VSAs?)?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>If the higher = order bit is set=20 to "0" means that it is mandatory, then currently defined optional = defined=20 TLVs suddenly become mandatory which is not good.<SPAN=20 class=3D560491614-28042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>Woj> Only the = currently used=20 TLVs become mandatory. If they are not used/implemented we can=20 re-define them as optional (set flag to 1) at no cost.=20 </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>But I would first = to understand=20 the exact meaning of this mandatory flag.  Defining such a flag = indeed=20 looks useful but then as interpretation 1, and I would say that if = flag set=20 to 1, then it is mandatory and actually, it is possible that a TLV = is sent=20 sometimes as optional and sometimes as mandatory.<SPAN=20 class=3D560491614-28042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>Woj> Precisely, = that is=20 possible on a per application basis.</FONT> <FONT = color=3D#000000>Having=20 the flag would make troubleshooting of a message flow much more = explicit (today, with any problem one has to browse the drafts = to=20 figure out what MUST be there vs what SHOULD be there all while = looking what is actually=20 there)</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 = size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 = size=3D2><SPAN=20 = class=3D560491614-28042008>Regards,</SPAN></FONT></FONT></FONT></SPAN></D= IV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 = size=3D2><SPAN=20 = class=3D560491614-28042008>Woj.</SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 = size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Stefaan</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT> </DIV><BR> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>Wojciech Dec=20 (wdec)<BR><B>Sent:</B> donderdag 24 april 2008 14:19<BR><B>To:</B> = Busser,=20 M; ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> Re: [ANCP] = Mandatory TLVs in draft-ietf-ancp-protocol = proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D709295811-24042008><FONT = face=3DArial=20 size=3D2>Hi Michael,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D709295811-24042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D709295811-24042008><FONT = face=3DArial=20 size=3D2>inline...</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 = 2px solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>Busser,=20 M<BR><B>Sent:</B> 24 April 2008 13:13<BR><B>To:</B>=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> Re: [ANCP]=20 Mandatory TLVs in draft-ietf-ancp-protocol = proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Hi Woi,=20 all</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>I see the=20 problem but i can not see, how an additional flag will help = solving this=20 problem.</FONT></SPAN></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Lets assume=20 your first proposal.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT=20 size=3D2>If an implementation does not send the = complete TLV, even=20 it is defined to be mandatory, I would call this a = bug=20 and I can not see, how an additional flag can help here.<SPAN = = class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 = class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Woj> The way it helps, and other = protocols=20 bear proof of this scheme, is that it is easier for = implementations to=20 reconcile errors resulting out of "Mandatory" and = "Optional" TLV=20 sets. The key to this lies on a per application basis. One = application may=20 mandate TLV A for operation, while another might not. Resolving = such=20 issues when implementing or troubleshooting multiple applications = is not=20 always trivial. </SPAN></FONT></FONT></SPAN><SPAN=20 class=3D364043506-24042008><FONT face=3DArial><FONT size=3D2><SPAN = class=3D709295811-24042008></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 = class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Your second=20 proposal seems obviously be required to keep existing things = working,=20 if we agree on your first proposal. </FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>But from my=20 point of view it also assumes, that all existing = implementations are=20 using the same set of TLVs now. </FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT=20 size=3D2>And I am not sure about that. <SPAN=20 = class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 = class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Woj> This would be a good thing for = the WG to=20 discuss. There most evidently is a fair amount of "dead wood" = in the=20 current spec, ie stuff that nobody yet implements or cares = about.=20  In the former case, we could re-cast that material using the = new=20 notions/extensions, in the latter case simply chop it=20 out.</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2><SPAN=20 class=3D364043506-24042008><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV></FONT></SPAN> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT=20 size=3D2>Therefore I disagree with your first proposal. I = recommend, the=20 better way will be to be more precise in definitions.<SPAN=20 = class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>In my mind, it=20 is a bug, if a mandatory TLV is missing. It is up to the = robustness of the=20 implementation to deal with this = situation.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2>Is it=20 really neccesary to define the behavior of a network element in = this case=20 of failure in the ancp protocol itself? <SPAN=20 = class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 = class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Woj> Other people have faced this = problem=20 before, and I would rather go with the lessons they learned, = rather than=20 clinging to hopes of perfect textual definitions and = implementations.=20 Other than backwards compatibility, I do not see in your = statements a=20 valid reason to object to the 1st proposal, particularly = for new=20 applications since it can only make things more robust. The = counter=20 argument of being precise in the definitions, as evidenced by the = current=20 spec, is admirable and needs to be there, with this proposal = providing an=20 extra level of robustness and visibility of any problems.=20 </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 = class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 = class=3D709295811-24042008>Thanks,</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Woj.</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>If optional=20 TLVs are not present in a message, we should describe some kind of = default=20 behaviour, as you already stated.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Comments on=20 = draft-ietf-ancp-protocol-02.txt:</FONT></SPAN></DIV></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT = face=3DArial>It is=20 not clearly stated, if the TLV  "<SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA">DSL=20 Line Attributes "<FONT face=3DArial> is mandatory or optional.=20 </FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT = face=3DArial><SPAN=20 lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>In fact it is mandatory because some of its SubTLVs = are=20 mandatory. </FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT = face=3DArial><SPAN=20 lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>We should spent a sentence to make this=20 clear.</FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2><SPAN=20 class=3D364043506-24042008><FONT size=3D2><FONT face=3DArial>It is = not clearly=20 stated, if the TLV  "<SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: = AR-SA">Service-Profile-Name"<FONT=20 face=3DArial> is mandatory or=20 optional.</FONT></SPAN></FONT></FONT></SPAN></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2><SPAN=20 class=3D364043506-24042008><FONT size=3D2><FONT face=3DArial><SPAN = lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>I prefer mandatory because it is essetial for the use = case Line=20 = Config. </FONT></SPAN></FONT></FONT></SPAN></DIV></FONT></SPAN><SPAN= =20 class=3D364043506-24042008><FONT face=3DArial = size=3D2></FONT></SPAN> <DIV><SPAN class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Section 5.4.3=20 Line Config, where the TLVs are mentioned (page = 35):</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2> =20 ...defined in section 5.4.1....    must be = corrected=20 to    ...defined in section=20 5.4.2........</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Section=20 5.4.4 OAM, where the TLVs are mentioned (page 36 and page=20 38):</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2> =20 ...defined in section 5.4.1....    must be = corrected=20 to    ...defined in section=20 5.4.2........</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV></FONT></SPAN><SPAN class=3D364043506-24042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV></DIV> <DIV><SPAN class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN = class=3D364043506-24042008><FONT=20 face=3DArial color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV align=3Dleft><FONT color=3D#000080 size=3D2> <P align=3Dleft>Best Regards; Freundliche Gr=FC=DFe = </P></FONT><B><FONT=20 color=3D#000080> <P>Michael Busser</P></B></FONT><FONT size=3D1> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt">T-Systems=20 Enterprise Services GmbH </SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1>Production Line Network Centric = Systems</FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1>ICT-Systems Integration</FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1>Network Integration Services</FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1></FONT><SPAN style=3D"COLOR: navy"></SPAN><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy"><FONT face=3DArial = color=3D#000000=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy"><FONT color=3D#000000 = size=3D1>Br=FCckes 2=20 -8, 55545 Bad Kreuznach<BR>Postfach 9100, 55541 Bad = Kreuznach<BR>+49 671=20 8333 8911 (Phone)<BR>+49 521 9210 3859 (Fax)<BR>+49 151=20 1211 9689 (Mobile)<BR>E-Mail: <A=20 = href=3D"mailto:michael.busser@t-systems.com">michael.busser@t-systems.com= </A></FONT></SPAN></DIV></SPAN> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN></DIV><SPAN style=3D"FONT-SIZE: = 8pt">Internet:=20 </SPAN><SPAN style=3D"FONT-SIZE: 8pt"><p:onmouseclick = hyperlinktype=3D"url"=20 href=3D"http://www.t-systems.com/"></p:onmouseclick><A=20 onclick=3Dwindow.event.cancelBubble=3Dtrue; = href=3D"http://www.t-systems.com/"=20 target=3D_parent><FONT=20 color=3D#6699ff>http://www.t-systems.com</FONT></A></SPAN><SPAN=20 style=3D"FONT-SIZE: 8pt"> </SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN> </DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D3><FONT size=3D1><SPAN=20 style=3D"FONT-SIZE: 7.5pt; COLOR: black; FONT-FAMILY: = Arial">T-Systems=20 Enterprise Services GmbH<BR>Aufsichtsrat: Ren=E9 Obermann=20 (Vorsitzender)<BR>Executive Committee: Reinhard Clemens = (Vorsitzender)*,=20 Helmut Binder, Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich = Kemp,=20 Wilfried Peters*,<BR>Dr. Herbert Schaaff*, Zvezdana=20 Seeger*<BR>Handelsregister: Amtsgericht Frankfurt am Main HRB=20 55933<BR>Sitz der Gesellschaft: Frankfurt am Main<BR>WEEE-Reg.-Nr. = DE87523644<BR>*Gesch=E4ftsf=FChrer gem. =A7 35=20 GmbHG</SPAN></FONT></FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT face=3DArial=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT size=3D1>Notice: This transmittal = and/or=20 attachments may be privileged or confidential. If you are not the = intended=20 recipient, you are hereby notified that you have received this = transmittal=20 in error; any review, dissemination, or copying is strictly = prohibited. If=20 you received this transmittal in error, please notify us = immediately by=20 reply and immediately delete this message and all its attachments. = Thank=20 you. </FONT><FONT size=3D1><BR>T-Systems =96 Business flexibility=20 </FONT></DIV></SPAN></SPAN> <DIV><FONT face=3DArial size=3D2></FONT> </DIV></FONT></DIV> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"> <DIV></DIV> <DIV class=3DOutlookMessageHeader lang=3Dde dir=3Dltr = align=3Dleft> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy = size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: = Arial"><o:p></o:p></SPAN></FONT></P><FONT=20 face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: = 12pt"><FONT=20 face=3DArial size=3D2></FONT> <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2> </SPAN></FONT></DIV> <DIV class=3DSection1> <DIV> <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: = Tahoma">Von:</SPAN></FONT></B><FONT=20 face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; = FONT-FAMILY: Tahoma">=20 ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] <B><SPAN=20 style=3D"FONT-WEIGHT: bold">Im Auftrag von </SPAN></B>Wojciech = Dec=20 (wdec)<BR><B><SPAN style=3D"FONT-WEIGHT: = bold">Gesendet:</SPAN></B>=20 Mittwoch, 23. April 2008 14:54<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">An:</SPAN></B> = ancp@ietf.org<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Betreff:</SPAN></B> [ANCP] Mandatory = TLVs in=20 draft-ietf-ancp-protocol = proposal</SPAN></FONT><o:p></o:p></P></DIV> <P class=3DMsoNormal><FONT face=3D"Times New Roman" = size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi = All,</SPAN></FONT><SPAN=20 lang=3DEN-GB> </SPAN><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Continuing with = the series=20 of e-mails regarding basic protocol issues still to be = addressed, I now=20 would now like to ask your feedback regarding the distinction = the=20 protocol places on mandatory TLVs. Given the length of this mail = I'll=20 first cut to the proposal, and after it you can find the problem = description.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The proposal which = I am=20 putting in front of the WG is to define a new TLV format which = contains=20 at a minimum a Mandatory flag (much like Radius VSAs do). We = could have=20 this TLV Flag be defined only for new=20 applications.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">A second proposal = would be=20 try to make this flag work with existing ones by for example = defining=20 the highest order bit of the TLV# field to mean "Mandatory" when = set to=20 "0". This would be invisible to exiting implementations, but = newer ones=20 may have problems in communicating with older ones when the = latter do=20 not send all TLVs. But that can also be addressed by simply = forming the=20 set of mandatory TLVs to be the ones that all implementations = currently=20 send by default.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Without additional = feedback,=20 I will assume that the WG is fine with the first proposal, and = also with=20 the 2nd one conditional on deriving a suitable "commonly used" = TLV=20 set.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The problem in = more detail:=20 </SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Currently the = situation is=20 that Mandatory TLVs are only stated to be as such in the body of = the=20 protocol draft spec, with an implementer having to scour fairly=20 attentively the text. Eg "Type (Access-Loop-Circuit-ID =3D = 0x01): This is=20 a mandatory TLV", etc.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The behaviour of = an=20 implementation that receives a message with a missing mandatory = TLV is=20 not defined at all, and the opposite is handled but not very = robustly,=20 i.e. when receiving a TLV but not recognizing it, and = implementation is=20 free to discard it (even if it is mandatory!). This is a recipe = for=20 interoperability problems and an implementation mine=20 field.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">This problem is = complicated=20 by different applications. For example the current OAM section = states=20 the following regarding TLVs that are to be carried in the = request=20 message (my italics):</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">"</SPAN></FONT> = <BR><FONT=20 face=3D"Courier New" color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">Following=20 TLVs<B><I><SPAN style=3D"FONT-WEIGHT: bold; FONT-STYLE: italic"> = can</SPAN></I></B> appear in this message: = </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section=20 5.4.1    </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (Access-Aggregation-Circuit-ID-Binary =3D 0x06): defined = in=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 section 5.4.1. </SPAN></FONT><BR><FONT face=3D"Courier New" = color=3Dblack=20 size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'"> </SPAN></FONT>=20 <BR><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03): defined = in section=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 5.4.1.  </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (OAM-Loopback-Test-Parameters =3D 0x07): Parameters = related=20 to  </SPAN></FONT><BR><FONT face=3D"Courier New" = color=3Dblack=20 size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 loopback test. This is an optional TLV. If this TLV is not = present=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 in the request message, the DSLAM SHOULD use locally determined=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 default values for the test parameters.  = </SPAN></FONT><BR><FONT=20 face=3D"Courier New" color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">"</SPAN></FONT>=20 <BR><FONT face=3DArial color=3Dblack size=3D2><SPAN lang=3DEN-US = style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = Arial">(NOTE: The=20 last "SHOULD" appears to be inappropriate. If the TLV is = missing, the=20 DSLAM MUST have some default parameters, or return an=20 error)</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">The = "can"=20 above indicates that they're all optional, while clearly the = application=20 cannot run its course without one or more of these fields. Here = we have=20 a case where one could have a perfectly compliant implementation = that=20 ignores all these TLVs=85</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = Arial">-Woj.</SPAN></FONT><SPAN=20 lang=3DEN-US> </SPAN><o:p></o:p></P> <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><FONT=20 face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: = 12pt"><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><o:p></o:p></SPAN></FONT></= P></DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML= > ------_=_NextPart_001_01C8A9CD.D7944D7E-- --===============0981949343== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============0981949343==-- From ancp-bounces@ietf.org Tue Apr 29 02:30:30 2008 Return-Path: <ancp-bounces@ietf.org> X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 133753A69FF; Tue, 29 Apr 2008 02:30:30 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C4713A68ED for <ancp@core3.amsl.com>; Tue, 29 Apr 2008 02:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.468 X-Spam-Level: X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2ad2nEEOVKk for <ancp@core3.amsl.com>; Tue, 29 Apr 2008 02:30:25 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id CAE603A6814 for <ancp@ietf.org>; Tue, 29 Apr 2008 02:30:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,722,1199660400"; d="scan'208,217";a="7595426" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 29 Apr 2008 11:29:59 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3T9TxZ0028045; Tue, 29 Apr 2008 11:29:59 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3T9Tx7q001311; Tue, 29 Apr 2008 09:29:59 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Apr 2008 11:29:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Apr 2008 11:28:03 +0200 Message-ID: <D9872168DBD43A41BD71FFC4713274D404FF13AD@xmb-ams-33b.emea.cisco.com> In-Reply-To: <7A6D4815C5E8F74988784FEBD50F2F1E01ABAC34@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal thread-index: AcilQRMfK4kdawUKQOWs5fdBngS8QQAAr04QACRhApAAC0ujAADNHRywAADiEXAAAbhxoAAAWwcQACIOoKAAAXsqYA== References: <1B6169C658325341A3B8066E23919E1C01230DC1@S4DE8PSAANK.mitte.t-com.de><1B6169C658325341A3B8066E23919E1CFBC5C4@S4DE8PSAANK.mitte.t-com.de><D9872168DBD43A41BD71FFC4713274D404FA6ACC@xmb-ams-33b.emea.cisco.com> <7A6D4815C5E8F74988784FEBD50F2F1E01ABAA16@FRVELSMBS22.ad2.ad.alcatel.com> <D9872168DBD43A41BD71FFC4713274D404FF10C1@xmb-ams-33b.emea.cisco.com> <7A6D4815C5E8F74988784FEBD50F2F1E01ABAAA4@FRVELSMBS22.ad2.ad.alcatel.com> <D9872168DBD43A41BD71FFC4713274D404FF1233@xmb-ams-33b.emea.cisco.com> <7A6D4815C5E8F74988784FEBD50F2F1E01ABAC34@FRVELSMBS22.ad2.ad.alcatel.com> From: "Wojciech Dec (wdec)" <wdec@cisco.com> To: "DE CNODDER Stefaan" <stefaan.de_cnodder@alcatel-lucent.be>, "Busser, M" <Michael.Busser@t-systems.com>, <ancp@ietf.org> X-OriginalArrivalTime: 29 Apr 2008 09:29:59.0392 (UTC) FILETIME=[980C1600:01C8A9DB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=80447; t=1209461399; x=1210325399; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20<wdec@cisco.com> |Subject:=20RE=3A=20[ANCP]=20Mandatory=20TLVs=20in=20draft- ietf-ancp-protocol=20proposal |Sender:=20; bh=me/Z6n/9tKZrk6jz5WvaBeK5uM0a5Yqi8MuQyR9STaE=; b=b29tLLiI5Fi0gcsmte0MFtOEGkLDF/LfiRJjtCEcwS4Bpnxa5mLgZAvBfM GkE4vU222hwWizvHoZql9fLgy1VOCGrJ3Wfn65B39Y3v86HBYJRu4VaEf3cb h7oUZ8lPhV; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: "Haag, T" <Thomas.Haag@t-systems.com> Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list <ancp.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/ancp> List-Post: <mailto:ancp@ietf.org> List-Help: <mailto:ancp-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============2127316610==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============2127316610== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A9DB.97D2DBD2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A9DB.97D2DBD2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stefaan, =20 a number of points: 1. There currently is to my knowledge no implementation of ANCP there = that doesn't send the DSL Line attributes info by default in Port-UP = messages? The support of HS on the NAS is an orthogonal issue. 2. The current ancp protocol draft (02) doesn't say whether the rate = info is optional or mandatory, it only states that the sub-TLVs are = mandatory. Based on this, an implementer can be justified to expect = port-ups to *always* have the rate-info tlv (ie treat them as = mandatory). Equally, she's justified in considering this as optional. 3. The port-up and OAM are best considered as legacy applications for = ANCP. The re-use of any of the GSMP defined fields is already out of the = question due to constrains put in place by the existing use-case = messaging. Needless to say, this wasn't as thoroughly designed as it = should have been, and with the OAM and port-up apps being coupled. 4. It's up to the application to define what TLVs are mandatory and = which aren't, as you also state. The AN does not need to know what the = NAS will do with the info, BUT it needs to send the right TLVs for the = application (eg if we had a hypothetical AN that only sends Port-up's = with line-id, it would be next to useless for the dynamic shaping = application). =20 With all this in mind it's useful to re-read what I proposed originally = below regarding the mandatory flag: 1. "have this TLV Flag be defined = only for new applications" and 2. The notion of the mandatory flag = applying to existing TLVs being "conditional on deriving a suitable = "commonly used" TLV set." The latter point would ensure that existing = implementations do not need to change, but future ones can take = advantage of the extra robustness. =20 Hence, can the WG derive a set of commonly used, i.e. always used, TLVs = for existing implementations? The list I came up is as follows (making them pretty much mandatory TLVs = if it agrees with the views of others); =20 Port-up message (0x80); Extension-TLV (dsl tech type) Access-Loop-circuit-id (0x01) DSL Line Attribute (0x04) with the following sub TLVs; DSL-Type =3D 0x91; Actual-Net-Data-Upstream =3D 0x81; = Actual-Net-Data-Rate-Downstream =3D 0x82 =20 Port-down message (0x81); Extension TLV (dsl tech type) Access-Loop-circuit-id (0x01) DSL Line Attribute (0x04) with the following sub TLVs; DSL line state =3D 0x8F =20 All other TLVs are optional. =20 Would appreciate confirmation from the WG regarding the above. =20 Thanks, Woj. =20 ________________________________ From: DE CNODDER Stefaan [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Sent: 29 April 2008 09:52 To: Wojciech Dec (wdec); Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal =09 =09 =20 Hi Woj, =20 Take the following example: I have a network with 2 NASses, NAS-A is = doing hierarchical shaping, NAS-B just wants to have the port = information but is not doing hierarchical shaping (it is doing other = things like OAM, ...). This means NAS-A needs the bandwidth, while = NAS-B does not need the bandwidth. How should the flag be set in this = case by the AN? Set to 'Mandatory' for the port up messages to NAS-A, = and set to 'Optional' for port up messages towards NAS-B? Or is it = always set to 'Mandatory'? From your answer below, I understand that it = should be set to 'Optional' towards NAS-B. Is that correct? =20 NAS-B will simply ignore the bandwidth TLV. If such a flag would = exist, and the flag is set to 'Mandatory' by the AN to NAS-B, what = should be the behavior of NAS-B? Should it reject the whole message? = Maybe NAS-B is not supporting hierarchical shaping, so it might not = support the bandwidth TLV. Today, the bandwidht TLV is only mandatory = to be put in the port up messages, but for the receiver there is nothing = mandatory. =20 I believe the original intend of ANCP was that the AN does not need to = know what the NAS is doing with this information, the use of the = bandwidth is also not specified by ANCP, only an example is given (which = is shaping). In the future there may be applications for which TLVs = will be mandatory which are now optional. =20 regards, Stefaan =20 =20 =20 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: maandag 28 april 2008 21:33 To: DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal =09 =09 =20 ________________________________ From: DE CNODDER Stefaan [mailto:stefaan.de_cnodder@alcatel-lucent.be] = Sent: 28 April 2008 17:15 To: Wojciech Dec (wdec); Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 =20 Take the bandwidth sub-TLV in port up messages as example. The = current protocol spec says that it is mandatory to be sent in port up = messages. that's ok. But it is not mandatory for the receiver to = process the bandwidth sub-TLV. What is done with this information by = the NAS is not specified by ANCP, so you cannot make it mandatory for = the receiver side.=20 =20 Woj> Is the information required by the application? It would appear = for the dynamic shaping use-case to be most certainly so. Hence it is = absolutely mandatory, otherwise the message makes no sense for the = application. In any case, if=20 =20 So it looks to me that the flag can only indicate what the receiver = should do. Then the flag makes sense.=20 =20 Woj> The flag tells the receiver what info the sender thinks is = required to carry out the application. This in almost all cases has to = match up to what the receiver thinks is required. The sender doesn't = tell the receiver what to do with the info. =20 If the receiver knows what is mandatory, then I do not see a reason = why this has to be made explicit in the protocol. It would only = complicate the protocol. As already said by Michael: if a mandatory TLV = is not there, then it is just a bug.=20 =20 Woj> Can you specifically describe what aspect of the protocol does it = complicate? It's just making explicitly clear what the protocol already = has to implement anyway to be of any use. As to whether it is a bug, having such explicit marking makes it clear = what/where the problem is when observing a messaging flow vs a lot of = deduction work. In any case, the other point being made here is that = today the protocol does NOT specify what should happen if a mandatory = TLV is missing. =20 -Woj. =20 regards, Stefaan =20 =20 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: maandag 28 april 2008 16:28 To: DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 It's actually a mix of both. Inline... ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = Of DE CNODDER Stefaan Sent: 28 April 2008 16:04 To: Wojciech Dec (wdec); Busser, M; ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 =20 Hi, =20 This new mandatory flag, what is exactly its meaning? =20 (1) if flag set to "mandatory", then the *receiver* of this TLV MUST = process it, and if unrecognized must drop the message=20 =20 If a received TLV is has the "mandatory" flag set then the receiver = MUST drop the message and report an error to the sender if it doesn't = recognize the TLV.=20 If a the receiver expects a "mandatory" TLV but doesn't receive it, = the message MUST be droped and an error report sent to the sender.=20 =20 OR =20 (2) if flag is set to"mandatory", then the *sender* MUST include it = in the message for which it is defined=20 =20 The sender MUST include mandatory TLVs as defined by the = protocol-spec/applications. =20 The current protocols draft says for certain TLVs that they are = mandatory, but that applies to the sender of it (interpretation 2). The = flag would indicate interpretation 1 (like for Radius VSAs?)? =20 If the higher order bit is set to "0" means that it is mandatory, = then currently defined optional defined TLVs suddenly become mandatory = which is not good.=20 =20 Woj> Only the currently used TLVs become mandatory. If they are not = used/implemented we can re-define them as optional (set flag to 1) at no = cost.=20 =20 But I would first to understand the exact meaning of this mandatory = flag. Defining such a flag indeed looks useful but then as = interpretation 1, and I would say that if flag set to 1, then it is = mandatory and actually, it is possible that a TLV is sent sometimes as = optional and sometimes as mandatory.=20 =20 Woj> Precisely, that is possible on a per application basis. Having = the flag would make troubleshooting of a message flow much more explicit = (today, with any problem one has to browse the drafts to figure out what = MUST be there vs what SHOULD be there all while looking what is actually = there) =20 Regards, Woj. =20 regards, Stefaan =20 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = Of Wojciech Dec (wdec) Sent: donderdag 24 april 2008 14:19 To: Busser, M; ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 Hi Michael, =20 inline... ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = Of Busser, M Sent: 24 April 2008 13:13 To: ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 Hi Woi, all =20 I see the problem but i can not see, how an additional flag will = help solving this problem. =20 Lets assume your first proposal. If an implementation does not send the complete TLV, even it is = defined to be mandatory, I would call this a bug and I can not see, how = an additional flag can help here.=20 =20 Woj> The way it helps, and other protocols bear proof of this = scheme, is that it is easier for implementations to reconcile errors = resulting out of "Mandatory" and "Optional" TLV sets. The key to this = lies on a per application basis. One application may mandate TLV A for = operation, while another might not. Resolving such issues when = implementing or troubleshooting multiple applications is not always = trivial.=20 =20 Your second proposal seems obviously be required to keep existing = things working, if we agree on your first proposal.=20 But from my point of view it also assumes, that all existing = implementations are using the same set of TLVs now.=20 And I am not sure about that. =20 =20 Woj> This would be a good thing for the WG to discuss. There most = evidently is a fair amount of "dead wood" in the current spec, ie stuff = that nobody yet implements or cares about. In the former case, we could = re-cast that material using the new notions/extensions, in the latter = case simply chop it out. =20 Therefore I disagree with your first proposal. I recommend, the = better way will be to be more precise in definitions.=20 In my mind, it is a bug, if a mandatory TLV is missing. It is up to = the robustness of the implementation to deal with this situation. Is it really neccesary to define the behavior of a network element = in this case of failure in the ancp protocol itself? =20 =20 Woj> Other people have faced this problem before, and I would rather = go with the lessons they learned, rather than clinging to hopes of = perfect textual definitions and implementations. Other than backwards = compatibility, I do not see in your statements a valid reason to object = to the 1st proposal, particularly for new applications since it can only = make things more robust. The counter argument of being precise in the = definitions, as evidenced by the current spec, is admirable and needs to = be there, with this proposal providing an extra level of robustness and = visibility of any problems.=20 =20 Thanks, Woj. =20 If optional TLVs are not present in a message, we should describe = some kind of default behaviour, as you already stated. =20 =20 =20 =20 =09 Comments on draft-ietf-ancp-protocol-02.txt: =20 It is not clearly stated, if the TLV "DSL Line Attributes " is = mandatory or optional.=20 In fact it is mandatory because some of its SubTLVs are mandatory.=20 We should spent a sentence to make this clear. =20 It is not clearly stated, if the TLV "Service-Profile-Name" is = mandatory or optional. I prefer mandatory because it is essetial for the use case Line = Config.=20 =09 =20 Section 5.4.3 Line Config, where the TLVs are mentioned (page 35): ...defined in section 5.4.1.... must be corrected to = ...defined in section 5.4.2........ =20 =09 Section 5.4.4 OAM, where the TLVs are mentioned (page 36 and page = 38): ...defined in section 5.4.1.... must be corrected to = ...defined in section 5.4.2........ =20 =20 =20 =20 Best Regards; Freundliche Gr=FC=DFe=20 Michael Busser =09 T-Systems Enterprise Services GmbH=20 Production Line Network Centric Systems ICT-Systems Integration Network Integration Services =20 Br=FCckes 2 -8, 55545 Bad Kreuznach Postfach 9100, 55541 Bad Kreuznach +49 671 8333 8911 (Phone) +49 521 9210 3859 (Fax) +49 151 1211 9689 (Mobile) E-Mail: michael.busser@t-systems.com =09 Internet: http://www.t-systems.com <http://www.t-systems.com/> =20 =09 =20 T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Reinhard Clemens (Vorsitzender)*, Helmut = Binder, Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, = Wilfried Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG =20 Notice: This transmittal and/or attachments may be privileged or = confidential. If you are not the intended recipient, you are hereby = notified that you have received this transmittal in error; any review, = dissemination, or copying is strictly prohibited. If you received this = transmittal in error, please notify us immediately by reply and = immediately delete this message and all its attachments. Thank you.=20 T-Systems - Business flexibility=20 =20 =09 =09 ________________________________ Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im = Auftrag von Wojciech Dec (wdec) Gesendet: Mittwoch, 23. April 2008 14:54 An: ancp@ietf.org Betreff: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal =20 Hi All,=20 Continuing with the series of e-mails regarding basic protocol = issues still to be addressed, I now would now like to ask your feedback = regarding the distinction the protocol places on mandatory TLVs. Given = the length of this mail I'll first cut to the proposal, and after it you = can find the problem description. The proposal which I am putting in front of the WG is to define a = new TLV format which contains at a minimum a Mandatory flag (much like = Radius VSAs do). We could have this TLV Flag be defined only for new = applications. A second proposal would be try to make this flag work with existing = ones by for example defining the highest order bit of the TLV# field to = mean "Mandatory" when set to "0". This would be invisible to exiting = implementations, but newer ones may have problems in communicating with = older ones when the latter do not send all TLVs. But that can also be = addressed by simply forming the set of mandatory TLVs to be the ones = that all implementations currently send by default. Without additional feedback, I will assume that the WG is fine with = the first proposal, and also with the 2nd one conditional on deriving a = suitable "commonly used" TLV set. The problem in more detail:=20 Currently the situation is that Mandatory TLVs are only stated to = be as such in the body of the protocol draft spec, with an implementer = having to scour fairly attentively the text. Eg "Type = (Access-Loop-Circuit-ID =3D 0x01): This is a mandatory TLV", etc. The behaviour of an implementation that receives a message with a = missing mandatory TLV is not defined at all, and the opposite is handled = but not very robustly, i.e. when receiving a TLV but not recognizing it, = and implementation is free to discard it (even if it is mandatory!). = This is a recipe for interoperability problems and an implementation = mine field. This problem is complicated by different applications. For example = the current OAM section states the following regarding TLVs that are to = be carried in the request message (my italics): "=20 Following TLVs can appear in this message:=20 o Type (Access-Loop-Circuit-ID =3D 0x01) : defined in = section 5.4.1 =20 o Type (Access-Aggregation-Circuit-ID-Binary =3D 0x06): = defined in=20 section 5.4.1.=20 =20 o Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03): = defined in section=20 5.4.1. =20 o Type (OAM-Loopback-Test-Parameters =3D 0x07): Parameters = related to =20 loopback test. This is an optional TLV. If this TLV is not = present=20 in the request message, the DSLAM SHOULD use locally = determined=20 default values for the test parameters. =20 "=20 (NOTE: The last "SHOULD" appears to be inappropriate. If the TLV is = missing, the DSLAM MUST have some default parameters, or return an = error) The "can" above indicates that they're all optional, while clearly = the application cannot run its course without one or more of these = fields. Here we have a case where one could have a perfectly compliant = implementation that ignores all these TLVs... -Woj.=20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 ------_=_NextPart_001_01C8A9DB.97D2DBD2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns:v =3D "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word" xmlns:p =3D=20 "urn:schemas-microsoft-com:office:powerpoint"><HEAD><TITLE>Nachricht</TIT= LE> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2900.3314" name=3DGENERATOR><!--[if !mso]> <STYLE>v\:* { BEHAVIOR: url(#default#VML) } o\:* { BEHAVIOR: url(#default#VML) } w\:* { BEHAVIOR: url(#default#VML) } .shape { BEHAVIOR: url(#default#VML) } </STYLE> <![endif]--> <STYLE>@font-face { font-family: Tahoma; } @page Section1 {size: 595.3pt 841.9pt; margin: 70.85pt 70.85pt 2.0cm = 70.85pt; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline } A:visited { COLOR: purple; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline } P { FONT-SIZE: 12pt; MARGIN-LEFT: 0cm; MARGIN-RIGHT: 0cm; FONT-FAMILY: = "Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto } SPAN.E-MailFormatvorlage18 { COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply } DIV.Section1 { page: Section1 } </STYLE> </HEAD> <BODY lang=3DDE vLink=3Dpurple link=3Dblue> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>Stefaan,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial size=3D2>a=20 number of points:</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>1. There currently is to my knowledge no implementation of = ANCP=20 there that doesn't send the DSL Line attributes info by default in = Port-UP=20 messages? The support of HS on the NAS is an orthogonal=20 issue.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>2. T</FONT></SPAN><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>he current ancp protocol draft (02) doesn't say whether the = rate info is=20 optional or mandatory, it only states that the sub-TLVs are mandatory. = Based on=20 this, an implementer can be justified to expect port-ups to = *always* have=20 the rate-info tlv (ie treat them as mandatory). Equally, she's = justified in=20 considering this  as optional.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><SPAN=20 class=3D342501308-29042008><FONT face=3DArial = size=3D2>3.<EM> </EM><SPAN=20 class=3D342501308-29042008><FONT face=3DArial size=3D2>The port-up and = OAM=20 are best considered as legacy applications for ANCP. The re-use of = any of=20 the GSMP defined fields is already out of the question due to constrains = put in=20 place by the existing use-case messaging. Needless to say, this wasn't = as=20 thoroughly designed as it should have been, and with the OAM and port-up = apps=20 being coupled.</FONT></SPAN></FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>4. It's up to the application to define what TLVs are mandatory = and which=20 aren't, as you also state. The AN does not need to know what the = NAS will=20 do with the info, BUT it needs to send the right TLVs for the = application (eg if=20 we had a hypothetical AN that only sends Port-up's with line-id, it = would=20 be next to useless for the dynamic shaping = application).</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>With all this in mind it's useful to re-read what I proposed = originally=20 below regarding the mandatory flag: 1. "<EM>have this TLV Flag be = defined=20 only for new applications" </EM>and 2. The notion of the mandatory flag = applying=20 to existing TLVs  being "<EM>conditional on deriving a suitable = "commonly=20 used" TLV set." </EM>The latter point would ensure that existing = implementations=20 do not need to change, but future ones can take advantage of the extra=20 robustness.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2><SPAN class=3D342501308-29042008></SPAN></FONT></SPAN><SPAN=20 class=3D342501308-29042008><FONT face=3DArial=20 size=3D2><EM></EM></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>Hence, can the WG derive a set of commonly used, i.e. always = used, TLVs=20 for existing implementations?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>The list I came up is as follows (making them pretty much = mandatory TLVs=20 if it agrees with the views of others);</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>Port-up message (0x80);</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>    Extension-TLV (dsl tech = type)</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>    Access-Loop-circuit-id = (0x01)</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>    DSL Line Attribute (0x04) with the following = sub=20 TLVs;</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008> <FONT = size=3D2>       DSL-Type =3D 0x91;=20 Actual-Net-Data-Upstream =3D 0x81<SPAN class=3D342501308-29042008>;=20 Actual-Net-Data-Rate-Downstream =3D 0x82</SPAN></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>Port-down message (0x81);</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008>    <FONT=20 face=3DArial size=3D2>Extension  TLV (dsl tech = type)</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008>    <FONT=20 face=3DArial size=3D2>Access-Loop-circuit-id (0x01)</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008>    <FONT=20 face=3DArial size=3D2>DSL Line Attribute (0x04) with the following sub=20 TLVs;</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN=20 class=3D342501308-29042008>       <FON= T size=3D2>=20 DSL line state =3D 0x8F</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>All other TLVs are optional.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>Would appreciate confirmation from the WG regarding the=20 above.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>Thanks,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>Woj.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> DE CNODDER Stefaan=20 [mailto:stefaan.de_cnodder@alcatel-lucent.be] <BR><B>Sent:</B> 29 = April 2008=20 09:52<BR><B>To:</B> Wojciech Dec (wdec); Busser, M;=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> RE: [ANCP] = Mandatory=20 TLVs in draft-ietf-ancp-protocol proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Hi Woj,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Take the following example: I have a network = with 2=20 NASses, NAS-A is doing hierarchical shaping, NAS-B just wants to have = the port=20 information but is not doing hierarchical shaping (it is doing other = things=20 like OAM, ...).  This means NAS-A needs the bandwidth, while = NAS-B does=20 not need the bandwidth.  How should the flag be set in this case = by the=20 AN?  Set to 'Mandatory' for the port up messages to NAS-A, and = set to=20 'Optional' for port up messages towards NAS-B? Or is it always set to=20 'Mandatory'?  From your answer below, I understand that it should = be set=20 to 'Optional' towards NAS-B.  Is that = correct?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>NAS-B will simply ignore the bandwidth = TLV.  If such=20 a flag would exist, and the flag is set to 'Mandatory' by the AN to = NAS-B,=20 what should be the behavior of NAS-B?  Should it reject the whole = message?  Maybe NAS-B is not supporting hierarchical shaping, so = it might=20 not support the bandwidth TLV.  Today, the bandwidht TLV is only=20 mandatory to be put in the port up messages, but for the receiver = there is=20 nothing mandatory.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>I believe the original intend of ANCP was = that the AN=20 does not need to know what the NAS is doing with this information, the = use of=20 the bandwidth is also not specified by ANCP, only an example is given = (which=20 is shaping).  In the future there may be applications for which = TLVs will=20 be mandatory which are now optional.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Stefaan</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV><BR> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com] <BR><B>Sent:</B> maandag 28 april 2008=20 21:33<BR><B>To:</B> DE CNODDER Stefaan; Busser, M; = ancp@ietf.org<BR><B>Cc:</B>=20 Haag, T<BR><B>Subject:</B> RE: [ANCP] Mandatory TLVs in=20 draft-ietf-ancp-protocol proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial = size=3D2></FONT> </DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> DE CNODDER Stefaan=20 [mailto:stefaan.de_cnodder@alcatel-lucent.be] <BR><B>Sent:</B> 28 = April 2008=20 17:15<BR><B>To:</B> Wojciech Dec (wdec); Busser, M;=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> RE: [ANCP] = Mandatory=20 TLVs in draft-ietf-ancp-protocol proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>Take the bandwidth = sub-TLV in=20 port up messages as example.  The current protocol spec says = that it is=20 mandatory to be sent in port up messages.  that's = ok.  But it=20 is not mandatory for the receiver to process the bandwidth = sub-TLV. =20 What is done with this information by the NAS is not specified by = ANCP, so=20 you cannot make it mandatory for the receiver side.<SPAN=20 class=3D163161615-28042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D163161615-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008><FONT color=3D#000000>Woj> Is the = information=20 required by the application? It would appear for the dynamic shaping = use-case to be most certainly so. Hence it is absolutely mandatory,=20 otherwise the message makes no sense for the = application.</FONT> <FONT=20 color=3D#000000>In any case, if=20 </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>So it looks to me = that the flag=20 can only indicate what the receiver should do.  Then the flag = makes=20 sense.<SPAN class=3D163161615-28042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D163161615-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008><FONT color=3D#000000>Woj> = </FONT> <FONT=20 color=3D#000000>The flag tells the receiver what info the sender = thinks is=20 required to carry out the application. This in almost all cases has = to match=20 up to what the receiver thinks is required. The=20 sender </FONT></SPAN></FONT></FONT></FONT></SPAN><SPAN=20 class=3D436050615-28042008><FONT color=3D#0000ff><FONT = face=3DArial><FONT=20 size=3D2><SPAN class=3D163161615-28042008><FONT = color=3D#000000>doesn't tell the=20 receiver what to do with the=20 info.</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>If the receiver = knows what is=20 mandatory, then I do not see a reason why this has to be made = explicit in=20 the protocol.  It would only complicate the protocol.  As = already=20 said by Michael: if a mandatory TLV is not there, then it is just a=20 bug.<SPAN class=3D163161615-28042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D163161615-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008><FONT color=3D#000000>Woj> Can you = specifically=20 describe what aspect of the protocol does it = complicate?</FONT> <FONT=20 color=3D#000000>It's just making explicitly clear what the protocol = already=20 has to implement anyway to be of any=20 use.</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = size=3D+0><FONT=20 face=3DArial><FONT size=3D2><SPAN class=3D163161615-28042008>As to = whether it is a=20 bug, having such explicit marking makes it clear what/where the = problem is=20 when observing a messaging flow vs a lot of deduction work. In = any=20 case, the other point being made here is that today the = protocol does=20 NOT specify what should happen if a mandatory TLV is=20 missing.</SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = size=3D+0><FONT=20 face=3DArial><FONT size=3D2><SPAN=20 = class=3D163161615-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = size=3D+0><FONT=20 face=3DArial><FONT size=3D2><SPAN=20 = class=3D163161615-28042008>-Woj.</SPAN></FONT></FONT></FONT></SPAN></DIV>= <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Stefaan</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV><BR> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com] <BR><B>Sent:</B> maandag 28 april 2008=20 16:28<BR><B>To:</B> DE CNODDER Stefaan; Busser, M;=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> RE: [ANCP] = Mandatory=20 TLVs in draft-ietf-ancp-protocol proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D560491614-28042008><FONT = face=3DArial=20 size=3D2>It's actually a mix of both. = Inline...</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 = 2px solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>DE CNODDER=20 Stefaan<BR><B>Sent:</B> 28 April 2008 16:04<BR><B>To:</B> Wojciech = Dec=20 (wdec); Busser, M; ancp@ietf.org<BR><B>Cc:</B> Haag, = T<BR><B>Subject:</B>=20 Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol=20 proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Hi,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>This new mandatory flag, what is exactly = its=20 meaning?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2>(1) if flag = set to=20 "mandatory", then the *receiver* of this TLV MUST process it, and = if=20 unrecognized must drop the message<SPAN = class=3D560491614-28042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>If a received TLV = is has=20 the "mandatory" flag set then the receiver MUST drop the = message=20 and report an error to the sender if it doesn't recognize the = TLV.</FONT> </SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>If a the receiver = expects=20 a "mandatory" TLV but doesn't receive it, the message = MUST=20 be droped and an error report sent to=20 = the sender.</FONT> </SPAN></FONT></FONT></FONT></SPAN></SPAN></= FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>OR</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2>(2) if flag = is set=20 to"mandatory", then the *sender* MUST include it in the message = for which=20 it is defined<SPAN class=3D560491614-28042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>The sender MUST = include=20 mandatory TLVs as defined by the=20 = protocol-spec/applications.</FONT></SPAN></FONT></FONT></FONT></SPAN></DI= V> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>The current protocols draft says for = certain TLVs=20 that they are mandatory, but that applies to the sender of it=20 (interpretation 2).  The flag would indicate interpretation 1 = (like=20 for Radius VSAs?)?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2>If the higher = order bit is set=20 to "0" means that it is mandatory, then currently defined optional = defined=20 TLVs suddenly become mandatory which is not good.<SPAN=20 class=3D560491614-28042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>Woj> Only the = currently=20 used TLVs become mandatory. If they are not used/implemented = we can=20 re-define them as optional (set flag to 1) at no cost.=20 </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2>But I would = first to=20 understand the exact meaning of this mandatory flag.  = Defining such a=20 flag indeed looks useful but then as interpretation 1, and I would = say=20 that if flag set to 1, then it is mandatory and actually, it is = possible=20 that a TLV is sent sometimes as optional and sometimes as = mandatory.<SPAN=20 class=3D560491614-28042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>Woj> = Precisely, that is=20 possible on a per application basis.</FONT> <FONT=20 color=3D#000000>Having the flag would make troubleshooting of a = message=20 flow much more explicit (today, with any problem one has = to=20 browse the drafts to figure out what MUST be there vs what SHOULD = be=20 there all while looking what is actually=20 there)</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 = size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 = size=3D2><SPAN=20 = class=3D560491614-28042008>Regards,</SPAN></FONT></FONT></FONT></SPAN></D= IV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 = size=3D2><SPAN=20 = class=3D560491614-28042008>Woj.</SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 = size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Stefaan</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT> </DIV><BR> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>Wojciech Dec=20 (wdec)<BR><B>Sent:</B> donderdag 24 april 2008 14:19<BR><B>To:</B> = Busser,=20 M; ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> Re: = [ANCP]=20 Mandatory TLVs in draft-ietf-ancp-protocol = proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D709295811-24042008><FONT = face=3DArial=20 size=3D2>Hi Michael,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D709295811-24042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D709295811-24042008><FONT = face=3DArial=20 size=3D2>inline...</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 = 2px solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>Busser,=20 M<BR><B>Sent:</B> 24 April 2008 13:13<BR><B>To:</B>=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> Re: = [ANCP]=20 Mandatory TLVs in draft-ietf-ancp-protocol = proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Hi Woi,=20 all</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>I see the=20 problem but i can not see, how an additional flag will help = solving this=20 problem.</FONT></SPAN></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Lets assume=20 your first proposal.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT=20 size=3D2>If an implementation does not send the = complete TLV,=20 even it is defined to be mandatory, I would call = this a=20 bug and I can not see, how an additional flag can help = here.<SPAN=20 = class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 = class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Woj> The way it helps, and other = protocols=20 bear proof of this scheme, is that it is easier for = implementations to=20 reconcile errors resulting out of "Mandatory" and = "Optional" TLV=20 sets. The key to this lies on a per application basis. One = application=20 may mandate TLV A for operation, while another might not. = Resolving such=20 issues when implementing or troubleshooting multiple = applications is not=20 always trivial. </SPAN></FONT></FONT></SPAN><SPAN=20 class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 = class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Your second=20 proposal seems obviously be required to keep existing = things=20 working, if we agree on your first proposal.=20 </FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>But from my=20 point of view it also assumes, that all existing = implementations=20 are using the same set of TLVs now. </FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT=20 size=3D2>And I am not sure about that. <SPAN=20 = class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 = class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Woj> This would be a good thing = for the WG=20 to discuss. There most evidently is a fair amount of "dead = wood" in=20 the current spec, ie stuff that nobody yet implements or = cares=20 about.  In the former case, we could re-cast that material = using=20 the new notions/extensions, in the latter case simply chop it=20 out.</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2><SPAN=20 class=3D364043506-24042008><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV></FONT></SPAN> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT=20 size=3D2>Therefore I disagree with your first proposal. I = recommend, the=20 better way will be to be more precise in definitions.<SPAN=20 = class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>In my mind,=20 it is a bug, if a mandatory TLV is missing. It is up to the = robustness=20 of the implementation to deal with this=20 situation.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2>Is it=20 really neccesary to define the behavior of a network element in = this=20 case of failure in the ancp protocol itself? <SPAN=20 = class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 = class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 class=3D709295811-24042008>Woj> Other people have faced this = problem=20 before, and I would rather go with the lessons they learned, = rather than=20 clinging to hopes of perfect textual definitions and = implementations.=20 Other than backwards compatibility, I do not see in your = statements a=20 valid reason to object to the 1st proposal, = particularly for=20 new applications since it can only make things more robust. The = counter=20 argument of being precise in the definitions, as evidenced by = the=20 current spec, is admirable and needs to be there, with this = proposal=20 providing an extra level of robustness and visibility of any = problems.=20 </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 = class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 = class=3D709295811-24042008>Thanks,</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 = class=3D709295811-24042008>Woj.</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>If optional=20 TLVs are not present in a message, we should describe some kind = of=20 default behaviour, as you already stated.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Comments on=20 = draft-ietf-ancp-protocol-02.txt:</FONT></SPAN></DIV></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT = face=3DArial>It is=20 not clearly stated, if the TLV  "<SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA">DSL=20 Line Attributes "<FONT face=3DArial> is mandatory or optional.=20 </FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT = face=3DArial><SPAN=20 lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>In fact it is mandatory because some of its SubTLVs = are=20 mandatory. </FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT = face=3DArial><SPAN=20 lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>We should spent a sentence to make this=20 clear.</FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2><SPAN=20 class=3D364043506-24042008><FONT size=3D2><FONT face=3DArial>It = is not clearly=20 stated, if the TLV  "<SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: = AR-SA">Service-Profile-Name"<FONT=20 face=3DArial> is mandatory or=20 optional.</FONT></SPAN></FONT></FONT></SPAN></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2><SPAN=20 class=3D364043506-24042008><FONT size=3D2><FONT = face=3DArial><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>I prefer mandatory because it is essetial for the = use case=20 Line=20 = Config. </FONT></SPAN></FONT></FONT></SPAN></DIV></FONT></SPAN><SPAN= =20 class=3D364043506-24042008><FONT face=3DArial = size=3D2></FONT></SPAN> <DIV><SPAN class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Section=20 5.4.3 Line Config, where the TLVs are mentioned (page=20 35):</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2> =20 ...defined in section 5.4.1....    must be = corrected=20 to    ...defined in section=20 5.4.2........</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Section=20 5.4.4 OAM, where the TLVs are mentioned (page 36 and page=20 38):</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2> =20 ...defined in section 5.4.1....    must be = corrected=20 to    ...defined in section=20 5.4.2........</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV></FONT></SPAN><SPAN class=3D364043506-24042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV></DIV> <DIV><SPAN class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN = class=3D364043506-24042008><FONT=20 face=3DArial color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV align=3Dleft><FONT color=3D#000080 size=3D2> <P align=3Dleft>Best Regards; Freundliche Gr=FC=DFe = </P></FONT><B><FONT=20 color=3D#000080> <P>Michael Busser</P></B></FONT><FONT size=3D1> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: 169" = align=3Dleft=20 v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt">T-Systems Enterprise=20 Services GmbH </SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: 169" = align=3Dleft=20 v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: 8pt"><FONT=20 size=3D1>Production Line Network Centric = Systems</FONT></SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: 169" = align=3Dleft=20 v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: 8pt"><FONT=20 size=3D1>ICT-Systems Integration</FONT></SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: 169" = align=3Dleft=20 v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: 8pt"><FONT = size=3D1>Network=20 Integration Services</FONT></SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: 169" = align=3Dleft=20 v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: 8pt"><FONT=20 size=3D1></FONT><SPAN style=3D"COLOR: navy"></SPAN><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy"><FONT face=3DArial = color=3D#000000=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: 169" = align=3Dleft=20 v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: 8pt"><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy"><FONT color=3D#000000 = size=3D1>Br=FCckes=20 2 -8, 55545 Bad Kreuznach<BR>Postfach 9100, 55541 Bad = Kreuznach<BR>+49=20 671 8333 8911 (Phone)<BR>+49 521 9210 3859 = (Fax)<BR>+49 151=20 1211 9689 (Mobile)<BR>E-Mail: <A=20 = href=3D"mailto:michael.busser@t-systems.com">michael.busser@t-systems.com= </A></FONT></SPAN></DIV></SPAN> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: 169" = align=3Dleft=20 v:shape=3D"_x0000_s1026"> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: 169" = align=3Dleft=20 v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"></SPAN></DIV><SPAN=20 style=3D"FONT-SIZE: 8pt">Internet: </SPAN><SPAN=20 style=3D"FONT-SIZE: 8pt"><p:onmouseclick = href=3D"http://www.t-systems.com/"=20 hyperlinktype=3D"url"></p:onmouseclick><A=20 onclick=3Dwindow.event.cancelBubble=3Dtrue; = href=3D"http://www.t-systems.com/"=20 target=3D_parent><FONT=20 color=3D#6699ff>http://www.t-systems.com</FONT></A></SPAN><SPAN=20 style=3D"FONT-SIZE: 8pt"> </SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '90 0 50'; mso-margin-left-alt: 169" = align=3Dleft=20 v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"></SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '90 0 50'; mso-margin-left-alt: 169" = align=3Dleft=20 v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"></SPAN> </DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '90 0 50'; mso-margin-left-alt: 169" = align=3Dleft=20 v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: 8pt"><FONT = size=3D3><FONT=20 size=3D1><SPAN=20 style=3D"FONT-SIZE: 7.5pt; COLOR: black; FONT-FAMILY: = Arial">T-Systems=20 Enterprise Services GmbH<BR>Aufsichtsrat: Ren=E9 Obermann=20 (Vorsitzender)<BR>Executive Committee: Reinhard Clemens = (Vorsitzender)*,=20 Helmut Binder, Albert Henn, Olaf Heyden*, Katrin Horstmann, = Ulrich Kemp,=20 Wilfried Peters*,<BR>Dr. Herbert Schaaff*, Zvezdana=20 Seeger*<BR>Handelsregister: Amtsgericht Frankfurt am Main HRB=20 55933<BR>Sitz der Gesellschaft: Frankfurt am = Main<BR>WEEE-Reg.-Nr.=20 DE87523644<BR>*Gesch=E4ftsf=FChrer gem. =A7 35=20 GmbHG</SPAN></FONT></FONT></SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '90 0 50'; mso-margin-left-alt: 169" = align=3Dleft=20 v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: 8pt"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT face=3DArial=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '90 0 50'; mso-margin-left-alt: 169" = align=3Dleft=20 v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: 8pt"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT size=3D1>Notice: This transmittal = and/or=20 attachments may be privileged or confidential. If you are not = the=20 intended recipient, you are hereby notified that you have = received this=20 transmittal in error; any review, dissemination, or copying is = strictly=20 prohibited. If you received this transmittal in error, please = notify us=20 immediately by reply and immediately delete this message and all = its=20 attachments. Thank you. </FONT><FONT size=3D1><BR>T-Systems =96 = Business=20 flexibility </FONT></DIV></SPAN></SPAN> <DIV><FONT face=3DArial = size=3D2></FONT> </DIV></FONT></DIV> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"> <DIV></DIV> <DIV class=3DOutlookMessageHeader lang=3Dde dir=3Dltr = align=3Dleft> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy = size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: = Arial"><o:p></o:p></SPAN></FONT></P><FONT=20 face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: = 12pt"><FONT=20 face=3DArial size=3D2></FONT> <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2> </SPAN></FONT></DIV> <DIV class=3DSection1> <DIV> <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: = Tahoma">Von:</SPAN></FONT></B><FONT=20 face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; = FONT-FAMILY: Tahoma">=20 ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] <B><SPAN=20 style=3D"FONT-WEIGHT: bold">Im Auftrag von </SPAN></B>Wojciech = Dec=20 (wdec)<BR><B><SPAN style=3D"FONT-WEIGHT: = bold">Gesendet:</SPAN></B>=20 Mittwoch, 23. April 2008 14:54<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">An:</SPAN></B> = ancp@ietf.org<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Betreff:</SPAN></B> [ANCP] = Mandatory TLVs in=20 draft-ietf-ancp-protocol = proposal</SPAN></FONT><o:p></o:p></P></DIV> <P class=3DMsoNormal><FONT face=3D"Times New Roman" = size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi = All,</SPAN></FONT><SPAN=20 lang=3DEN-GB> </SPAN><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Continuing with = the series=20 of e-mails regarding basic protocol issues still to be = addressed, I=20 now would now like to ask your feedback regarding the = distinction the=20 protocol places on mandatory TLVs. Given the length of this = mail I'll=20 first cut to the proposal, and after it you can find the = problem=20 description.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The proposal = which I am=20 putting in front of the WG is to define a new TLV format which = contains at a minimum a Mandatory flag (much like Radius VSAs = do). We=20 could have this TLV Flag be defined only for new=20 applications.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">A second = proposal would be=20 try to make this flag work with existing ones by for example = defining=20 the highest order bit of the TLV# field to mean "Mandatory" = when set=20 to "0". This would be invisible to exiting implementations, = but newer=20 ones may have problems in communicating with older ones when = the=20 latter do not send all TLVs. But that can also be addressed by = simply=20 forming the set of mandatory TLVs to be the ones that all=20 implementations currently send by=20 default.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Without = additional=20 feedback, I will assume that the WG is fine with the first = proposal,=20 and also with the 2nd one conditional on deriving a suitable = "commonly=20 used" TLV set.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The problem in = more=20 detail: </SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Currently the = situation is=20 that Mandatory TLVs are only stated to be as such in the body = of the=20 protocol draft spec, with an implementer having to scour = fairly=20 attentively the text. Eg "Type (Access-Loop-Circuit-ID =3D = 0x01): This=20 is a mandatory TLV", etc.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The behaviour of = an=20 implementation that receives a message with a missing = mandatory TLV is=20 not defined at all, and the opposite is handled but not very = robustly,=20 i.e. when receiving a TLV but not recognizing it, and = implementation=20 is free to discard it (even if it is mandatory!). This is a = recipe for=20 interoperability problems and an implementation mine=20 field.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">This problem is=20 complicated by different applications. For example the current = OAM=20 section states the following regarding TLVs that are to be = carried in=20 the request message (my italics):</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">"</SPAN></FONT> = <BR><FONT=20 face=3D"Courier New" color=3Dblack size=3D2><SPAN lang=3DEN-US = style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">Following=20 TLVs<B><I><SPAN style=3D"FONT-WEIGHT: bold; FONT-STYLE: = italic">=20 can</SPAN></I></B> appear in this message:=20 </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section=20 5.4.1    </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (Access-Aggregation-Circuit-ID-Binary =3D 0x06): = defined in=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 section 5.4.1. </SPAN></FONT><BR><FONT face=3D"Courier New" = color=3Dblack=20 size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'"> </SPAN></FONT>=20 <BR><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03): defined = in=20 section </SPAN></FONT><BR><FONT face=3D"Courier New" = color=3Dblack=20 size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 5.4.1.  </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">      =20 o Type (OAM-Loopback-Test-Parameters =3D 0x07): Parameters = related=20 to  </SPAN></FONT><BR><FONT face=3D"Courier New" = color=3Dblack=20 size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 loopback test. This is an optional TLV. If this TLV is not = present=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 in the request message, the DSLAM SHOULD use locally = determined=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">        =20 default values for the test parameters.  = </SPAN></FONT><BR><FONT=20 face=3D"Courier New" color=3Dblack size=3D2><SPAN lang=3DEN-US = style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier = New'">"</SPAN></FONT>=20 <BR><FONT face=3DArial color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = Arial">(NOTE: The=20 last "SHOULD" appears to be inappropriate. If the TLV is = missing, the=20 DSLAM MUST have some default parameters, or return an=20 error)</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = Arial">The "can"=20 above indicates that they're all optional, while clearly the=20 application cannot run its course without one or more of these = fields.=20 Here we have a case where one could have a perfectly compliant = implementation that ignores all these=20 TLVs=85</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = Arial">-Woj.</SPAN></FONT><SPAN=20 lang=3DEN-US> </SPAN><o:p></o:p></P> <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><FONT=20 face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: = 12pt"><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><o:p></o:p></SPAN></FONT></= P></DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE>= </BODY></HTML> ------_=_NextPart_001_01C8A9DB.97D2DBD2-- --===============2127316610== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============2127316610==-- From ancp-bounces@ietf.org Tue Apr 29 05:06:38 2008 Return-Path: <ancp-bounces@ietf.org> X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC16A3A6CF2; Tue, 29 Apr 2008 05:06:38 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CACF3A6C84 for <ancp@core3.amsl.com>; Tue, 29 Apr 2008 05:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ud3A-xPimruq for <ancp@core3.amsl.com>; Tue, 29 Apr 2008 05:06:36 -0700 (PDT) Received: from maill.telecomitalia.it (maill.telecomitalia.it [217.169.121.52]) by core3.amsl.com (Postfix) with ESMTP id F144528C194 for <ancp@ietf.org>; Tue, 29 Apr 2008 05:06:18 -0700 (PDT) Received: from ptpxch008rm001.idc.cww.telecomitalia.it ([156.54.205.170]) by maill.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Apr 2008 14:06:19 +0200 Received: from grfhub703rm001.griffon.local ([10.19.3.10]) by ptpxch008rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Apr 2008 14:06:16 +0200 Received: from GRFMBX702RM001.griffon.local ([10.19.3.19]) by grfhub703rm001.griffon.local ([10.19.3.10]) with mapi; Tue, 29 Apr 2008 14:06:11 +0200 From: "Maglione Roberta" <roberta.maglione@telecomitalia.it> To: "Sanjay Wadhwa" <swadhwa@juniper.net> Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Date: Tue, 29 Apr 2008 14:06:10 +0200 Thread-Topic: question regarding Labels in ANCP port up messages thread-index: AcigmA/KomZRxzutR3KVCt4iUapYhQEdac+QAAJNLMAADUINAAAvT/GQAADkesAAAvMysAAAjrywAAGWHyAA8tFsZQ== Message-ID: <A1F769BC58A8B146B2EEA818EAE052A20121E75F40@GRFMBX702RM001.griffon.local> References: <A1F769BC58A8B146B2EEA818EAE052A279468D4F@GRFMBX702RM001.griffon.local> <A1F769BC58A8B146B2EEA818EAE052A27B09701A@GRFMBX702RM001.griffon.local> <D9872168DBD43A41BD71FFC4713274D404F5E0F1@xmb-ams-33b.emea.cisco.com> <A1F769BC58A8B146B2EEA818EAE052A27B097025@GRFMBX702RM001.griffon.local> <D9872168DBD43A41BD71FFC4713274D404FA6B20@xmb-ams-33b.emea.cisco.com> <A1F769BC58A8B146B2EEA818EAE052A20121E8248B@GRFMBX702RM001.griffon.local> <48214755113BB04F84D958B4F0DE261C0593001F@xmb-sjc-222.amer.cisco.com> <A1F769BC58A8B146B2EEA818EAE052A20121E8248C@GRFMBX702RM001.griffon.local>, <48214755113BB04F84D958B4F0DE261C0593011A@xmb-sjc-222.amer.cisco.com> In-Reply-To: <48214755113BB04F84D958B4F0DE261C0593011A@xmb-sjc-222.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 29 Apr 2008 12:06:16.0527 (UTC) FILETIME=[6D4155F0:01C8A9F1] Cc: ancp@ietf.org Subject: Re: [ANCP] question regarding Labels in ANCP port up messages X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list <ancp.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/ancp> List-Post: <mailto:ancp@ietf.org> List-Help: <mailto:ancp-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=subscribe> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hi Sanjay and All, I was reading the current ancp protocol draft in order to understand which should be the correct format for the label field in the ancp port Up message. Actually as it was already pointed out in the alias the draft in section 5.4.2 says "GSMP Event message with PORT UP message type (80) is used" thus I am assuming that the label in the port UP message should follow the message format defined in RFC 3292, section 3.1.3: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|S|x|x| Label Type | Label Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Label Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ but from what I have seen different implementations use different format for label field: in particular several implementations use a label format that is similar to the one specified in the expired draft draft-ietf-gsmp-v3-base-spec: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|S|x|x|x|x|x|x|x|x|x|x|x|x|x|x| Label Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Adaptation | Label Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Label Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Even if ancp does not care about the label field, having this field somehow not clearly specified in the current ancp draft can easily lead to interoperability issues, thus I think it would be very helpful if you and/or the other editors can clarify what should be the correct format for the label field to be used in the ancp Port Up message. Thanks and best regards, Roberta ________________________________________ From: Philippe Champagne (pchamp) [pchamp@cisco.com] Sent: Thursday, April 24, 2008 7:14 PM To: Sanjay Wadhwa Cc: Maglione Roberta; Wojciech Dec (wdec); ancp@ietf.org Subject: question regarding Labels in ANCP port up messages Hi Sanjay In section 5.4.2 of the draft, we have: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub | Message Type | Result| Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Session Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Event Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|S|x|x| | +-+-+-+-+ Label | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Extension Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where Label I suppose is taken from the RFC 3292, section 3.1.3: (well, I'm guessing) A summary of TLV labels supported in this version of the protocol is listed below: TLV Label Type Section Title --------- ---- ------------- ATM Label 0x100 ATM TLV Labels FR Label 0x101 Frame Relay TLV Labels MPLS Gen Label 0x102 MPLS Generic TLV Labels FEC Label 0x103 FEC TLV Labels All Labels will be designated as follow: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|S|x|x| Label Type | Label Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Label Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ x: Reserved Flags. These are generally used by specific messages and will be defined in those messages. S: Stacked Label Indicator Label Stacking is discussed below in section 3.1.3.5 Label Type A 12-bit field indicating the type of label. Label Length A 16-bit field indicating the length of the Label Value field in bytes. Label Value A variable length field that is an integer number of 32 bit words long. The Label Value field is interpreted according to the Label Type as described in the following sections. The draft is a bit obscure about this and since it doesn't specify much, it can lead to misinterpretation for the unused part. Moreover, it would appear that several implementations currently use another format for the label field. Can you explain? I mean, how come what's in the current draft doesn't match what's known to be implemented? I'm still wondering why we carried over pieces from GSMP that we do not intend to use. I would recommend that if we are to keep them but not use them, we should mention precisely how we intend not to use them: that is how many 0 filled bytes this is expected to use The rfc 3292 doesn't cover the case where this field is not used. Can you shed some ligths on this? Thanks Regards Phil -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Apr 29 08:28:59 2008 Return-Path: <ancp-bounces@ietf.org> X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0D5A3A6DC8; Tue, 29 Apr 2008 08:28:59 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1B173A685D for <ancp@core3.amsl.com>; Tue, 29 Apr 2008 08:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQMSWRdGbU4z for <ancp@core3.amsl.com>; Tue, 29 Apr 2008 08:28:53 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 54B5F28C123 for <ancp@ietf.org>; Tue, 29 Apr 2008 08:28:51 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Tue, 29 Apr 2008 08:22:33 PDT Received: from proton.jnpr.net ([10.10.2.37]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Apr 2008 08:28:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Apr 2008 11:28:48 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280AB439FC@proton.jnpr.net> In-Reply-To: <A1F769BC58A8B146B2EEA818EAE052A20121E75F40@GRFMBX702RM001.griffon.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: question regarding Labels in ANCP port up messages Thread-Index: AcigmA/KomZRxzutR3KVCt4iUapYhQEdac+QAAJNLMAADUINAAAvT/GQAADkesAAAvMysAAAjrywAAGWHyAA8tFsZQAGU1sw From: "Sanjay Wadhwa" <swadhwa@juniper.net> To: "Maglione Roberta" <roberta.maglione@telecomitalia.it> X-OriginalArrivalTime: 29 Apr 2008 15:28:52.0477 (UTC) FILETIME=[BAC41AD0:01C8AA0D] Cc: ancp@ietf.org Subject: Re: [ANCP] question regarding Labels in ANCP port up messages X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list <ancp.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/ancp> List-Post: <mailto:ancp@ietf.org> List-Help: <mailto:ancp-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=subscribe> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hi Maglione Yes, the label format is as defined in RFC 3292. The ANCP draft is based on RFC 3292 and proposes extensions/modifications where required. This is clearly stated upfront both in the abstract and in section 2. In section 5.4.2, it clearly specifies the format of "port up" message (based on RFC 3292), and explicitly states the label field should be set to 0. Following is what the draft currently states: 5.4.2 Topology Discovery Extensions The GSMP Event message with PORT UP message type (80) is used for conveying DSL line attributes to the NAS. The version field should be set to 3, and the sub field should be set to 1. The I and subMessage fields SHOULD be set to 1 to signify no fragmentation. The Port and Label fields should be set to 0. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub | Message Type | Result| Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Session Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Event Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|S|x|x| | +-+-+-+-+ Label | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Extension Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When we say the label field should be set to 0, the intention is for the type and length fields in the label TLV to be set to 0. We can explicitly state this for clarity. -Sanjay >-----Original Message----- >From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] >Sent: Tuesday, April 29, 2008 8:06 AM >To: Sanjay Wadhwa >Cc: Wojciech Dec (wdec); ancp@ietf.org; pchamp@cisco.com >Subject: RE: question regarding Labels in ANCP port up messages > > >Hi Sanjay and All, > I was reading the current ancp protocol draft in order to > understand which should be the correct format for the label >field in the ancp port Up message. >Actually as it was already pointed out in the alias the draft >in section 5.4.2 says "GSMP Event message with PORT UP message >type (80) is used" thus I am assuming that the label in the >port UP message should follow the message format defined in >RFC 3292, section 3.1.3: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |x|S|x|x| Label Type | Label Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ Label Value ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >but from what I have seen different implementations use >different format for label field: in particular several >implementations use a label format that is similar to the one >specified in the expired draft draft-ietf-gsmp-v3-base-spec: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |x|S|x|x|x|x|x|x|x|x|x|x|x|x|x|x| Label Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Label Adaptation | Label Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ Label Value ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >Even if ancp does not care about the label field, having this >field somehow not clearly specified in the current ancp draft >can easily lead to interoperability issues, thus I think it >would be very helpful if you and/or the other editors can >clarify what should be the correct format for the label field >to be used in the ancp Port Up message. > >Thanks and best regards, >Roberta > >________________________________________ >From: Philippe Champagne (pchamp) [pchamp@cisco.com] >Sent: Thursday, April 24, 2008 7:14 PM >To: Sanjay Wadhwa >Cc: Maglione Roberta; Wojciech Dec (wdec); ancp@ietf.org >Subject: question regarding Labels in ANCP port up messages > >Hi Sanjay > >In section 5.4.2 of the draft, we have: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 >7 8 9 0 1 > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vers | Sub | Message Type | Result| Code > | > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Partition ID | Transaction Identifier > | > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |I| SubMessage Number | Length > | > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Port > | > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Port Session Number > | > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Event Sequence Number > | > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |x|S|x|x| > | > +-+-+-+-+ Label > | > ~ > ~ > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |x|x|x|x|x|x|x|x| Message Type | Tech Type | >Block Length | > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | > | > ~ Extension Value > ~ > | > | > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >Where Label I suppose is taken from the RFC 3292, section >3.1.3: (well, I'm guessing) > > A summary of TLV labels supported in this version of the protocol is > listed below: > > TLV Label Type Section Title > --------- ---- ------------- > ATM Label 0x100 ATM TLV Labels > FR Label 0x101 Frame Relay TLV Labels > MPLS Gen Label 0x102 MPLS Generic TLV Labels > FEC Label 0x103 FEC TLV Labels > > All Labels will be designated as follow: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |x|S|x|x| Label Type | Label Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ Label Value ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > x: Reserved Flags. > These are generally used by specific messages and will be > defined in those messages. > > S: Stacked Label Indicator > Label Stacking is discussed below in section 3.1.3.5 > > Label Type > A 12-bit field indicating the type of label. > > Label Length > A 16-bit field indicating the length of the Label Value field > in bytes. > > Label Value > A variable length field that is an integer number of 32 bit > words long. The Label Value field is interpreted according to > the Label Type as described in the following sections. > > >The draft is a bit obscure about this and since it doesn't >specify much, it can lead to misinterpretation for the unused >part. Moreover, it would appear that several implementations >currently use another format for the label field. Can you >explain? I mean, how come what's in the current draft doesn't >match what's known to be implemented? > >I'm still wondering why we carried over pieces from GSMP that >we do not intend to use. > >I would recommend that if we are to keep them but not use >them, we should mention precisely how we intend not to use >them: that is how many 0 filled bytes this is expected to use > >The rfc 3292 doesn't cover the case where this field is not used. > >Can you shed some ligths on this? > >Thanks >Regards >Phil > > > >-------------------------------------------------------------------- > >CONFIDENTIALITY NOTICE > >This message and its attachments are addressed solely to the >persons above and may contain confidential information. If you >have received the message in error, be informed that any use >of the content hereof is prohibited. Please return it >immediately to the sender and delete the message. Should you >have any questions, please contact us by replying to >webmaster@telecomitalia.it. > > Thank you > > www.telecomitalia.it > >-------------------------------------------------------------------- > > _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Apr 29 10:13:19 2008 Return-Path: <ancp-bounces@ietf.org> X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 463263A6939; Tue, 29 Apr 2008 10:13:19 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD5DD3A6803 for <ancp@core3.amsl.com>; Tue, 29 Apr 2008 10:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.48 X-Spam-Level: X-Spam-Status: No, score=-6.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSiefD+0gKyi for <ancp@core3.amsl.com>; Tue, 29 Apr 2008 10:13:15 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 16C763A6B5B for <ancp@ietf.org>; Tue, 29 Apr 2008 10:13:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,723,1199660400"; d="scan'208";a="7648607" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 29 Apr 2008 19:13:16 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3THDGY3016832; Tue, 29 Apr 2008 19:13:16 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3THDGlK010514; Tue, 29 Apr 2008 17:13:16 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Apr 2008 19:13:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Apr 2008 19:12:19 +0200 Message-ID: <D9872168DBD43A41BD71FFC4713274D404FF16F8@xmb-ams-33b.emea.cisco.com> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C280AB439FC@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: question regarding Labels in ANCP port up messages thread-index: AcigmA/KomZRxzutR3KVCt4iUapYhQEdac+QAAJNLMAADUINAAAvT/GQAADkesAAAvMysAAAjrywAAGWHyAA8tFsZQAGU1swAARUsRA= References: <A1F769BC58A8B146B2EEA818EAE052A20121E75F40@GRFMBX702RM001.griffon.local> <9BD5D7887235424FA97DFC223CAE3C280AB439FC@proton.jnpr.net> From: "Wojciech Dec (wdec)" <wdec@cisco.com> To: "Sanjay Wadhwa" <swadhwa@juniper.net>, "Maglione Roberta" <roberta.maglione@telecomitalia.it> X-OriginalArrivalTime: 29 Apr 2008 17:13:16.0683 (UTC) FILETIME=[508615B0:01C8AA1C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=13079; t=1209489196; x=1210353196; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20<wdec@cisco.com> |Subject:=20RE=3A=20question=20regarding=20=20Labels=20in=2 0ANCP=20port=20up=20messages |Sender:=20; bh=Vj35xuVORPA/wXbANILkEVtG+3UW3gv9YfHWi0VdSq4=; b=Uvd4sbTAQxmXOjXWEJvzXzuSUCNcKHMxLjZDFLLpMdW7fPDO135vze5KUM e6frURccmkIzWLMJwavS4U+HNZrBKLpgTJab+Xa26QazHLcZ4PHsKCsCXyNg rmm6yzVpvx; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ancp@ietf.org Subject: Re: [ANCP] question regarding Labels in ANCP port up messages X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list <ancp.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/ancp> List-Post: <mailto:ancp@ietf.org> List-Help: <mailto:ancp-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=subscribe> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Sanjay, All, What is stated below runs counter to at least a handful of ANCP implementations, all of which are known to be interoperable. There are really two options: 1) The current version of the spec is correct, and the known interoperable implementations do not follow it 2) The current version of the spec is not accurate, and does not reflect the fact that the known implementations follow the label field definition from draft-gsmpv3-base-spec. I would like to ask you, as the lead editor of the spec, to work with the WG in resolving what the problem is, and clearing up what the WG spec says about and if 1) holds to be true, then proposing an interoperability fix. In either case, the issue highlights the fact that there is still lingering confusion as to the dependencies ANCP has on rfc3292, or draft-gsmpv3-base-spec, or both. It seems to be in the best interest of all to address these. Regards, Woj. > -----Original Message----- > From: Sanjay Wadhwa [mailto:swadhwa@juniper.net] > Sent: 29 April 2008 17:29 > To: Maglione Roberta > Cc: Wojciech Dec (wdec); ancp@ietf.org; Philippe Champagne (pchamp) > Subject: RE: question regarding Labels in ANCP port up messages > > Hi Maglione > Yes, the label format is as defined in RFC 3292. The ANCP draft is > based on RFC 3292 and proposes extensions/modifications where > required. > This is clearly stated upfront both in the abstract and in > section 2. In > section 5.4.2, it clearly specifies the format of "port up" message > (based on RFC 3292), and explicitly states the label field > should be set > to 0. Following is what the draft currently states: > > > 5.4.2 Topology Discovery Extensions > > The GSMP Event message with PORT UP message type (80) is used for > conveying DSL line attributes to the NAS. The version field should be > set to 3, and the sub field should be set to 1. The I and subMessage > fields SHOULD be set to 1 to signify no fragmentation. The Port and > Label fields should be set to 0. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vers | Sub | Message Type | Result| Code > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Partition ID | Transaction Identifier > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |I| SubMessage Number | Length > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Port > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Port Session Number > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Event Sequence Number > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |x|S|x|x| > | > +-+-+-+-+ Label > | > ~ > ~ > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | > | > ~ Extension Value > ~ > | > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > When we say the label field should be set to 0, the intention > is for the > type and length fields in the label TLV to be set to 0. We can > explicitly state this for clarity. > > -Sanjay > > >-----Original Message----- > >From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] > >Sent: Tuesday, April 29, 2008 8:06 AM > >To: Sanjay Wadhwa > >Cc: Wojciech Dec (wdec); ancp@ietf.org; pchamp@cisco.com > >Subject: RE: question regarding Labels in ANCP port up messages > > > > > >Hi Sanjay and All, > > I was reading the current ancp protocol draft in order to > > understand which should be the correct format for the label > >field in the ancp port Up message. > >Actually as it was already pointed out in the alias the draft > >in section 5.4.2 says "GSMP Event message with PORT UP message > >type (80) is used" thus I am assuming that the label in the > >port UP message should follow the message format defined in > >RFC 3292, section 3.1.3: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |x|S|x|x| Label Type | Label Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > ~ Label Value ~ > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >but from what I have seen different implementations use > >different format for label field: in particular several > >implementations use a label format that is similar to the one > >specified in the expired draft draft-ietf-gsmp-v3-base-spec: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |x|S|x|x|x|x|x|x|x|x|x|x|x|x|x|x| Label > Type | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Label Adaptation | Label > Length | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | > | > > ~ Label Value > ~ > > | > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > >Even if ancp does not care about the label field, having this > >field somehow not clearly specified in the current ancp draft > >can easily lead to interoperability issues, thus I think it > >would be very helpful if you and/or the other editors can > >clarify what should be the correct format for the label field > >to be used in the ancp Port Up message. > > > >Thanks and best regards, > >Roberta > > > >________________________________________ > >From: Philippe Champagne (pchamp) [pchamp@cisco.com] > >Sent: Thursday, April 24, 2008 7:14 PM > >To: Sanjay Wadhwa > >Cc: Maglione Roberta; Wojciech Dec (wdec); ancp@ietf.org > >Subject: question regarding Labels in ANCP port up messages > > > >Hi Sanjay > > > >In section 5.4.2 of the draft, we have: > > > > > > 0 1 2 > 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > >7 8 9 0 1 > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Vers | Sub | Message Type | Result| Code > > | > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Partition ID | Transaction Identifier > > | > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |I| SubMessage Number | Length > > | > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Port > > | > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Port Session Number > > | > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Event Sequence Number > > | > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |x|S|x|x| > > | > > +-+-+-+-+ Label > > | > > ~ > > ~ > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |x|x|x|x|x|x|x|x| Message Type | Tech Type | > >Block Length | > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | > > | > > ~ Extension Value > > ~ > > | > > | > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >Where Label I suppose is taken from the RFC 3292, section > >3.1.3: (well, I'm guessing) > > > > A summary of TLV labels supported in this version of the > protocol is > > listed below: > > > > TLV Label Type Section Title > > --------- ---- ------------- > > ATM Label 0x100 ATM TLV Labels > > FR Label 0x101 Frame Relay TLV Labels > > MPLS Gen Label 0x102 MPLS Generic TLV Labels > > FEC Label 0x103 FEC TLV Labels > > > > All Labels will be designated as follow: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |x|S|x|x| Label Type | Label Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > ~ Label Value ~ > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > x: Reserved Flags. > > These are generally used by specific messages and will be > > defined in those messages. > > > > S: Stacked Label Indicator > > Label Stacking is discussed below in section 3.1.3.5 > > > > Label Type > > A 12-bit field indicating the type of label. > > > > Label Length > > A 16-bit field indicating the length of the Label > Value field > > in bytes. > > > > Label Value > > A variable length field that is an integer number of 32 bit > > words long. The Label Value field is interpreted > according to > > the Label Type as described in the following sections. > > > > > >The draft is a bit obscure about this and since it doesn't > >specify much, it can lead to misinterpretation for the unused > >part. Moreover, it would appear that several implementations > >currently use another format for the label field. Can you > >explain? I mean, how come what's in the current draft doesn't > >match what's known to be implemented? > > > >I'm still wondering why we carried over pieces from GSMP that > >we do not intend to use. > > > >I would recommend that if we are to keep them but not use > >them, we should mention precisely how we intend not to use > >them: that is how many 0 filled bytes this is expected to use > > > >The rfc 3292 doesn't cover the case where this field is not used. > > > >Can you shed some ligths on this? > > > >Thanks > >Regards > >Phil > > > > > > > >-------------------------------------------------------------------- > > > >CONFIDENTIALITY NOTICE > > > >This message and its attachments are addressed solely to the > >persons above and may contain confidential information. If you > >have received the message in error, be informed that any use > >of the content hereof is prohibited. Please return it > >immediately to the sender and delete the message. Should you > >have any questions, please contact us by replying to > >webmaster@telecomitalia.it. > > > > Thank you > > > > www.telecomitalia.it > > > >-------------------------------------------------------------------- > > > > > _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Apr 29 10:34:22 2008 Return-Path: <ancp-bounces@ietf.org> X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27ED428C112; Tue, 29 Apr 2008 10:34:22 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F353B3A6AA3 for <ancp@core3.amsl.com>; Tue, 29 Apr 2008 10:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfX3rHFApxfr for <ancp@core3.amsl.com>; Tue, 29 Apr 2008 10:34:14 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 3DA633A6970 for <ancp@ietf.org>; Tue, 29 Apr 2008 10:34:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id AF1FA1BAB52; Tue, 29 Apr 2008 10:34:05 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17032-03; Tue, 29 Apr 2008 10:34:05 -0700 (PDT) Received: from rbsjx.ad.redback.com (rbsjxh1.redback.com [155.53.14.105]) by prattle.redback.com (Postfix) with ESMTP id 315EB1BAB51; Tue, 29 Apr 2008 10:33:55 -0700 (PDT) Received: from RBSJX.ad.redback.com ([155.53.14.103]) by rbsjxh1.ad.redback.com ([155.53.14.105]) with mapi; Tue, 29 Apr 2008 10:33:49 -0700 From: Peter Arberg <parberg@redback.com> To: "Wojciech Dec (wdec)" <wdec@cisco.com>, DE CNODDER Stefaan <stefaan.de_cnodder@alcatel-lucent.be>, "Busser, M" <Michael.Busser@t-systems.com>, "ancp@ietf.org" <ancp@ietf.org> Date: Tue, 29 Apr 2008 10:33:48 -0700 Thread-Topic: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal Thread-Index: AcilQRMfK4kdawUKQOWs5fdBngS8QQAAr04QACRhApAAC0ujAADNHRywAADiEXAAAbhxoAAAWwcQACIOoKAAAXsqYAASvbCg Message-ID: <48C276B536524E478C659685995F6AA539DBB4F194@RBSJX.ad.redback.com> References: <1B6169C658325341A3B8066E23919E1C01230DC1@S4DE8PSAANK.mitte.t-com.de><1B6169C658325341A3B8066E23919E1CFBC5C4@S4DE8PSAANK.mitte.t-com.de><D9872168DBD43A41BD71FFC4713274D404FA6ACC@xmb-ams-33b.emea.cisco.com> <7A6D4815C5E8F74988784FEBD50F2F1E01ABAA16@FRVELSMBS22.ad2.ad.alcatel.com> <D9872168DBD43A41BD71FFC4713274D404FF10C1@xmb-ams-33b.emea.cisco.com> <7A6D4815C5E8F74988784FEBD50F2F1E01ABAAA4@FRVELSMBS22.ad2.ad.alcatel.com> <D9872168DBD43A41BD71FFC4713274D404FF1233@xmb-ams-33b.emea.cisco.com> <7A6D4815C5E8F74988784FEBD50F2F1E01ABAC34@FRVELSMBS22.ad2.ad.alcatel.com> <D9872168DBD43A41BD71FFC4713274D404FF13AD@xmb-ams-33b.emea.cisco.com> In-Reply-To: <D9872168DBD43A41BD71FFC4713274D404FF13AD@xmb-ams-33b.emea.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at redback.com Cc: "Haag, T" <Thomas.Haag@t-systems.com> Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list <ancp.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/ancp> List-Post: <mailto:ancp@ietf.org> List-Help: <mailto:ancp-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0185673203==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org --===============0185673203== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_48C276B536524E478C659685995F6AA539DBB4F194RBSJXadredbac_" --_000_48C276B536524E478C659685995F6AA539DBB4F194RBSJXadredbac_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Woj, I agree with Michael and Stefan on this issue, I do not see a need to chang= e the existing implementation with a mandatory/optional flag. I think I understand your arguments, but I do not agree with them. I think = most places in the draft it is clear what is defined as mandatory and optional. I agree on the point we need to go through the draft and make clarification= s to what TLV's in what capability types are mandatory and optional, and make more descript= ion what should happen if mandatory TLVs are not included. I think the DSLF TR-101 document has a good example of such a description i= n it's "Table 3 - Access loop characteristics sub-options", and I think if we do t= he same for each capability types TLV's in the ANCP draft it will be a good help. I do not agree with your point that it is not listed if "rate" is mandatory= or optional, it is clearly listed as a mandatory TLV, and as such it should be included in the port up= message, I really do not understand what confusion you have with this. The fact you say "Port UP" and "OAM" is best considered as legacy applicati= ons, I have some trouble with this as well, since ANCP running in production networks use th= em, and as such it is a central part of the ANCP specifications we need to finish as soon a= s possible. I think Stefaan's example is very valid, that we do not need to make mandat= ory requirements to what receivers of ANCP information use such info. for. I don't think we sh= ould try and make the ANCP specifications "mandatory" for box behavior, I think it is much more i= mportant for the working group to make the protocol specifications easy to understand and ge= t the first documentation finish and published, so the protocol can be used for different sets of app= lications, and make sure new applications can be added later. I do think that by documenting if a TLV is mandatory or optional inside a s= pecific capability type, it is easy to understand what must be sent to support the defined applicati= on/capability type. Then if anybody want to include new capability types or sub-TLVs later to a= ddress specific applications, then I think changes can be discussed at that time instead of trying to cha= nge existing protocol implementations. cheers, Peter ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Woj= ciech Dec (wdec) Sent: 29. april 2008 02:28 To: DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal Stefaan, a number of points: 1. There currently is to my knowledge no implementation of ANCP there that = doesn't send the DSL Line attributes info by default in Port-UP messages? T= he support of HS on the NAS is an orthogonal issue. 2. The current ancp protocol draft (02) doesn't say whether the rate info i= s optional or mandatory, it only states that the sub-TLVs are mandatory. Ba= sed on this, an implementer can be justified to expect port-ups to *always*= have the rate-info tlv (ie treat them as mandatory). Equally, she's justif= ied in considering this as optional. 3. The port-up and OAM are best considered as legacy applications for ANCP.= The re-use of any of the GSMP defined fields is already out of the questio= n due to constrains put in place by the existing use-case messaging. Needle= ss to say, this wasn't as thoroughly designed as it should have been, and w= ith the OAM and port-up apps being coupled. 4. It's up to the application to define what TLVs are mandatory and which a= ren't, as you also state. The AN does not need to know what the NAS will do= with the info, BUT it needs to send the right TLVs for the application (eg= if we had a hypothetical AN that only sends Port-up's with line-id, it wou= ld be next to useless for the dynamic shaping application). With all this in mind it's useful to re-read what I proposed originally bel= ow regarding the mandatory flag: 1. "have this TLV Flag be defined only for= new applications" and 2. The notion of the mandatory flag applying to exis= ting TLVs being "conditional on deriving a suitable "commonly used" TLV se= t." The latter point would ensure that existing implementations do not need= to change, but future ones can take advantage of the extra robustness. Hence, can the WG derive a set of commonly used, i.e. always used, TLVs for= existing implementations? The list I came up is as follows (making them pretty much mandatory TLVs if= it agrees with the views of others); Port-up message (0x80); Extension-TLV (dsl tech type) Access-Loop-circuit-id (0x01) DSL Line Attribute (0x04) with the following sub TLVs; DSL-Type =3D 0x91; Actual-Net-Data-Upstream =3D 0x81; Actual-Net-Da= ta-Rate-Downstream =3D 0x82 Port-down message (0x81); Extension TLV (dsl tech type) Access-Loop-circuit-id (0x01) DSL Line Attribute (0x04) with the following sub TLVs; DSL line state =3D 0x8F All other TLVs are optional. Would appreciate confirmation from the WG regarding the above. Thanks, Woj. ________________________________ From: DE CNODDER Stefaan [mailto:stefaan.de_cnodder@alcatel-lucent.be] Sent: 29 April 2008 09:52 To: Wojciech Dec (wdec); Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal Hi Woj, Take the following example: I have a network with 2 NASses, NAS-A is doing = hierarchical shaping, NAS-B just wants to have the port information but is = not doing hierarchical shaping (it is doing other things like OAM, ...). T= his means NAS-A needs the bandwidth, while NAS-B does not need the bandwidt= h. How should the flag be set in this case by the AN? Set to 'Mandatory' = for the port up messages to NAS-A, and set to 'Optional' for port up messag= es towards NAS-B? Or is it always set to 'Mandatory'? From your answer bel= ow, I understand that it should be set to 'Optional' towards NAS-B. Is tha= t correct? NAS-B will simply ignore the bandwidth TLV. If such a flag would exist, an= d the flag is set to 'Mandatory' by the AN to NAS-B, what should be the beh= avior of NAS-B? Should it reject the whole message? Maybe NAS-B is not su= pporting hierarchical shaping, so it might not support the bandwidth TLV. = Today, the bandwidht TLV is only mandatory to be put in the port up message= s, but for the receiver there is nothing mandatory. I believe the original intend of ANCP was that the AN does not need to know= what the NAS is doing with this information, the use of the bandwidth is a= lso not specified by ANCP, only an example is given (which is shaping). In= the future there may be applications for which TLVs will be mandatory whic= h are now optional. regards, Stefaan ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] Sent: maandag 28 april 2008 21:33 To: DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal ________________________________ From: DE CNODDER Stefaan [mailto:stefaan.de_cnodder@alcatel-lucent.be] Sent: 28 April 2008 17:15 To: Wojciech Dec (wdec); Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal Take the bandwidth sub-TLV in port up messages as example. The current pro= tocol spec says that it is mandatory to be sent in port up messages. that'= s ok. But it is not mandatory for the receiver to process the bandwidth su= b-TLV. What is done with this information by the NAS is not specified by A= NCP, so you cannot make it mandatory for the receiver side. Woj> Is the information required by the application? It would appear for th= e dynamic shaping use-case to be most certainly so. Hence it is absolutely = mandatory, otherwise the message makes no sense for the application. In any= case, if So it looks to me that the flag can only indicate what the receiver should = do. Then the flag makes sense. Woj> The flag tells the receiver what info the sender thinks is required t= o carry out the application. This in almost all cases has to match up to wh= at the receiver thinks is required. The sender doesn't tell the receiver wh= at to do with the info. If the receiver knows what is mandatory, then I do not see a reason why thi= s has to be made explicit in the protocol. It would only complicate the pr= otocol. As already said by Michael: if a mandatory TLV is not there, then = it is just a bug. Woj> Can you specifically describe what aspect of the protocol does it comp= licate? It's just making explicitly clear what the protocol already has to = implement anyway to be of any use. As to whether it is a bug, having such explicit marking makes it clear what= /where the problem is when observing a messaging flow vs a lot of deduction= work. In any case, the other point being made here is that today the proto= col does NOT specify what should happen if a mandatory TLV is missing. -Woj. regards, Stefaan ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] Sent: maandag 28 april 2008 16:28 To: DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal It's actually a mix of both. Inline... ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of DE = CNODDER Stefaan Sent: 28 April 2008 16:04 To: Wojciech Dec (wdec); Busser, M; ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal Hi, This new mandatory flag, what is exactly its meaning? (1) if flag set to "mandatory", then the *receiver* of this TLV MUST proces= s it, and if unrecognized must drop the message If a received TLV is has the "mandatory" flag set then the receiver MUST dr= op the message and report an error to the sender if it doesn't recognize th= e TLV. If a the receiver expects a "mandatory" TLV but doesn't receive it, the mes= sage MUST be droped and an error report sent to the sender. OR (2) if flag is set to"mandatory", then the *sender* MUST include it in the = message for which it is defined The sender MUST include mandatory TLVs as defined by the protocol-spec/appl= ications. The current protocols draft says for certain TLVs that they are mandatory, = but that applies to the sender of it (interpretation 2). The flag would in= dicate interpretation 1 (like for Radius VSAs?)? If the higher order bit is set to "0" means that it is mandatory, then curr= ently defined optional defined TLVs suddenly become mandatory which is not = good. Woj> Only the currently used TLVs become mandatory. If they are not used/im= plemented we can re-define them as optional (set flag to 1) at no cost. But I would first to understand the exact meaning of this mandatory flag. = Defining such a flag indeed looks useful but then as interpretation 1, and = I would say that if flag set to 1, then it is mandatory and actually, it is= possible that a TLV is sent sometimes as optional and sometimes as mandato= ry. Woj> Precisely, that is possible on a per application basis. Having the fla= g would make troubleshooting of a message flow much more explicit (today, w= ith any problem one has to browse the drafts to figure out what MUST be the= re vs what SHOULD be there all while looking what is actually there) Regards, Woj. regards, Stefaan ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Woj= ciech Dec (wdec) Sent: donderdag 24 april 2008 14:19 To: Busser, M; ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal Hi Michael, inline... ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Bus= ser, M Sent: 24 April 2008 13:13 To: ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal Hi Woi, all I see the problem but i can not see, how an additional flag will help solvi= ng this problem. Lets assume your first proposal. If an implementation does not send the complete TLV, even it is defined to = be mandatory, I would call this a bug and I can not see, how an additional = flag can help here. Woj> The way it helps, and other protocols bear proof of this scheme, is th= at it is easier for implementations to reconcile errors resulting out of "M= andatory" and "Optional" TLV sets. The key to this lies on a per applicatio= n basis. One application may mandate TLV A for operation, while another mig= ht not. Resolving such issues when implementing or troubleshooting multiple= applications is not always trivial. Your second proposal seems obviously be required to keep existing things wo= rking, if we agree on your first proposal. But from my point of view it also assumes, that all existing implementation= s are using the same set of TLVs now. And I am not sure about that. Woj> This would be a good thing for the WG to discuss. There most evidently= is a fair amount of "dead wood" in the current spec, ie stuff that nobody = yet implements or cares about. In the former case, we could re-cast that m= aterial using the new notions/extensions, in the latter case simply chop it= out. Therefore I disagree with your first proposal. I recommend, the better way = will be to be more precise in definitions. In my mind, it is a bug, if a mandatory TLV is missing. It is up to the rob= ustness of the implementation to deal with this situation. Is it really neccesary to define the behavior of a network element in this = case of failure in the ancp protocol itself? Woj> Other people have faced this problem before, and I would rather go wit= h the lessons they learned, rather than clinging to hopes of perfect textua= l definitions and implementations. Other than backwards compatibility, I do= not see in your statements a valid reason to object to the 1st proposal, p= articularly for new applications since it can only make things more robust.= The counter argument of being precise in the definitions, as evidenced by = the current spec, is admirable and needs to be there, with this proposal pr= oviding an extra level of robustness and visibility of any problems. Thanks, Woj. If optional TLVs are not present in a message, we should describe some kind= of default behaviour, as you already stated. Comments on draft-ietf-ancp-protocol-02.txt: It is not clearly stated, if the TLV "DSL Line Attributes " is mandatory o= r optional. In fact it is mandatory because some of its SubTLVs are mandatory. We should spent a sentence to make this clear. It is not clearly stated, if the TLV "Service-Profile-Name" is mandatory o= r optional. I prefer mandatory because it is essetial for the use case Line Config. Section 5.4.3 Line Config, where the TLVs are mentioned (page 35): ...defined in section 5.4.1.... must be corrected to ...defined in = section 5.4.2........ Section 5.4.4 OAM, where the TLVs are mentioned (page 36 and page 38): ...defined in section 5.4.1.... must be corrected to ...defined in = section 5.4.2........ Best Regards; Freundliche Gr=FC=DFe Michael Busser T-Systems Enterprise Services GmbH Production Line Network Centric Systems ICT-Systems Integration Network Integration Services Br=FCckes 2 -8, 55545 Bad Kreuznach Postfach 9100, 55541 Bad Kreuznach +49 671 8333 8911 (Phone) +49 521 9210 3859 (Fax) +49 151 1211 9689 (Mobile) E-Mail: michael.busser@t-systems.com<mailto:michael.busser@t-systems.com> Internet: http://www.t-systems.com<http://www.t-systems.com/> T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Reinhard Clemens (Vorsitzender)*, Helmut Binder, Alber= t Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Wilfried Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG Notice: This transmittal and/or attachments may be privileged or confidenti= al. If you are not the intended recipient, you are hereby notified that you= have received this transmittal in error; any review, dissemination, or cop= ying is strictly prohibited. If you received this transmittal in error, ple= ase notify us immediately by reply and immediately delete this message and = all its attachments. Thank you. T-Systems - Business flexibility ________________________________ Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von Wo= jciech Dec (wdec) Gesendet: Mittwoch, 23. April 2008 14:54 An: ancp@ietf.org Betreff: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal Hi All, Continuing with the series of e-mails regarding basic protocol issues still= to be addressed, I now would now like to ask your feedback regarding the d= istinction the protocol places on mandatory TLVs. Given the length of this = mail I'll first cut to the proposal, and after it you can find the problem = description. The proposal which I am putting in front of the WG is to define a new TLV f= ormat which contains at a minimum a Mandatory flag (much like Radius VSAs d= o). We could have this TLV Flag be defined only for new applications. A second proposal would be try to make this flag work with existing ones by= for example defining the highest order bit of the TLV# field to mean "Mand= atory" when set to "0". This would be invisible to exiting implementations,= but newer ones may have problems in communicating with older ones when the= latter do not send all TLVs. But that can also be addressed by simply form= ing the set of mandatory TLVs to be the ones that all implementations curre= ntly send by default. Without additional feedback, I will assume that the WG is fine with the fir= st proposal, and also with the 2nd one conditional on deriving a suitable "= commonly used" TLV set. The problem in more detail: Currently the situation is that Mandatory TLVs are only stated to be as suc= h in the body of the protocol draft spec, with an implementer having to sco= ur fairly attentively the text. Eg "Type (Access-Loop-Circuit-ID =3D 0x01):= This is a mandatory TLV", etc. The behaviour of an implementation that receives a message with a missing m= andatory TLV is not defined at all, and the opposite is handled but not ver= y robustly, i.e. when receiving a TLV but not recognizing it, and implement= ation is free to discard it (even if it is mandatory!). This is a recipe fo= r interoperability problems and an implementation mine field. This problem is complicated by different applications. For example the curr= ent OAM section states the following regarding TLVs that are to be carried = in the request message (my italics): " Following TLVs can appear in this message: o Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section 5.4.1 o Type (Access-Aggregation-Circuit-ID-Binary =3D 0x06): defined in section 5.4.1. o Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03): defined in se= ction 5.4.1. o Type (OAM-Loopback-Test-Parameters =3D 0x07): Parameters related t= o loopback test. This is an optional TLV. If this TLV is not present in the request message, the DSLAM SHOULD use locally determined default values for the test parameters. " (NOTE: The last "SHOULD" appears to be inappropriate. If the TLV is missing= , the DSLAM MUST have some default parameters, or return an error) The "can" above indicates that they're all optional, while clearly the appl= ication cannot run its course without one or more of these fields. Here we = have a case where one could have a perfectly compliant implementation that = ignores all these TLVs... -Woj. --_000_48C276B536524E478C659685995F6AA539DBB4F194RBSJXadredbac_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns:v =3D "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word" xmlns:p =3D=20 "urn:schemas-microsoft-com:office:powerpoint"><HEAD><TITLE>Nachricht</TITLE= > <META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1"= > <META content=3D"MSHTML 6.00.6000.16640" name=3DGENERATOR><!--[if !mso]> <STYLE>v\:* { BEHAVIOR: url(#default#VML) } o\:* { BEHAVIOR: url(#default#VML) } w\:* { BEHAVIOR: url(#default#VML) } .shape { BEHAVIOR: url(#default#VML) } </STYLE> <![endif]--> <STYLE>@font-face { font-family: Tahoma; } @page Section1 {size: 595.3pt 841.9pt; margin: 70.85pt 70.85pt 2.0cm 70.85p= t; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline } A:visited { COLOR: purple; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline } P { FONT-SIZE: 12pt; MARGIN-LEFT: 0cm; MARGIN-RIGHT: 0cm; FONT-FAMILY: "Times = New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto } SPAN.E-MailFormatvorlage18 { COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply } DIV.Section1 { page: Section1 } </STYLE> </HEAD> <BODY lang=3DDE vLink=3Dpurple link=3Dblue> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>Hi Woj,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>I agree with Michael and Stefan on this issue, I d= o not see=20 a need to change the existing</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>implementation with a mandatory/optional=20 flag.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>I think I understand your arguments, but I do not = agree=20 with them. I think most places in</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>the draft it is clear what is defined as mandatory= and=20 optional.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>I agree on the point we need to go through the dra= ft and=20 make clarifications to what TLV's</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>in what capability types are mandatory and optiona= l, and=20 make more description what should</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>happen if mandatory TLVs are not=20 included.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>I think the DSLF TR-101 document has a good exampl= e of such=20 a description in it's </FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 size=3D2><FONT color=3D#0000ff>"</FONT><FONT face=3DArial-BoldMT size=3D2><= FONT=20 color=3D#0000ff>Table 3 - Access loop characteristics sub-options<SPAN=20 class=3D058271017-29042008>", and I think if we do the same for=20 each</SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 size=3D2><FONT face=3DArial-BoldMT size=3D2><FONT color=3D#0000ff><SPAN=20 class=3D058271017-29042008>capability types TLV's in the ANCP draft it will= be a=20 good help.</SPAN></FONT></DIV></FONT></FONT></SPAN> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>I do not agree with your point that it is not list= ed if=20 "rate" is mandatory or optional, it is clearly</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>listed as a mandatory TLV, and as such it should b= e=20 included in the port up message, I really</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>do not understand what confusion you have with=20 this.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>The fact you say "Port UP" and "OAM" is best consi= dered as=20 legacy applications, I have some</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>trouble with this as well, since ANCP running in p= roduction=20 networks use them, and as such</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>it is a central part of the ANCP specifications we= need to=20 finish as soon as possible.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>I think Stefaan's example is very valid, that we d= o not=20 need to make mandatory requirements to </FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>what receivers of ANCP information use such info.= =20 for.  I don't think we should try and make the</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>ANCP specifications "mandatory" for box behavior, = I think=20 it is much more important for the </FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>working group to make the protocol specifications = easy to=20 understand and get the first documentation</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>finish and published, so the protocol can be used = for=20 different sets of applications, and make sure</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>new applications can be added later.</FONT></SPAN>= </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>I do think that by documenting if a TLV is mandato= ry or=20 optional inside a specific capability type,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>it is easy to understand what must be sent to supp= ort the=20 defined application/capability type.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>Then if anybody want to include new capability typ= es or=20 sub-TLVs later to address specific applications,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>then I think changes can be discussed at that time= instead=20 of trying to change existing protocol</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>implementations.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>cheers,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>Peter</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px soli= d; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>Wojciech Dec=20 (wdec)<BR><B>Sent:</B> 29. april 2008 02:28<BR><B>To:</B> DE CNODDER Stef= aan;=20 Busser, M; ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> Re: [AN= CP]=20 Mandatory TLVs in draft-ietf-ancp-protocol proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT face= =3DArial=20 size=3D2>Stefaan,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT face= =3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT face= =3DArial=20 size=3D2>a number of points:</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT face= =3DArial=20 size=3D2>1. There currently is to my knowledge no implementation of = ANCP=20 there that doesn't send the DSL Line attributes info by default in Port-U= P=20 messages? The support of HS on the NAS is an orthogonal=20 issue.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT face= =3DArial=20 size=3D2>2. T</FONT></SPAN><SPAN class=3D342501308-29042008><FONT face=3D= Arial=20 size=3D2>he current ancp protocol draft (02) doesn't say whether the rate= info=20 is optional or mandatory, it only states that the sub-TLVs are mandatory.= =20 Based on this, an implementer can be justified to expect port-ups to= =20 *always* have the rate-info tlv (ie treat them as mandatory). Equally, sh= e's=20 justified in considering this  as optional.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><SPAN=20 class=3D342501308-29042008><FONT face=3DArial size=3D2>3.<EM> </EM><= SPAN=20 class=3D342501308-29042008><FONT face=3DArial size=3D2>The port-up and OA= M=20 are best considered as legacy applications for ANCP. The re-use of a= ny of=20 the GSMP defined fields is already out of the question due to constrains = put=20 in place by the existing use-case messaging. Needless to say, this wasn't= as=20 thoroughly designed as it should have been, and with the OAM and port-up = apps=20 being coupled.</FONT></SPAN></FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT face= =3DArial=20 size=3D2>4. It's up to the application to define what TLVs are mandatory = and=20 which aren't, as you also state. The AN does not need to know what t= he=20 NAS will do with the info, BUT it needs to send the right TLVs for the=20 application (eg if we had a hypothetical AN that only sends Port-up'= s=20 with line-id, it would be next to useless for the dynamic shaping=20 application).</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT face= =3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT face= =3DArial=20 size=3D2>With all this in mind it's useful to re-read what I proposed ori= ginally=20 below regarding the mandatory flag: 1. "<EM>have this TLV Flag be de= fined=20 only for new applications" </EM>and 2. The notion of the mandatory flag=20 applying to existing TLVs  being "<EM>conditional on deriving a suit= able=20 "commonly used" TLV set." </EM>The latter point would ensure that existin= g=20 implementations do not need to change, but future ones can take advantage= of=20 the extra robustness.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT face= =3DArial=20 size=3D2><SPAN class=3D342501308-29042008></SPAN></FONT></SPAN><SPAN=20 class=3D342501308-29042008><FONT face=3DArial=20 size=3D2><EM></EM></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT face= =3DArial=20 size=3D2>Hence, can the WG derive a set of commonly used, i.e. always use= d, TLVs=20 for existing implementations?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT face= =3DArial=20 size=3D2>The list I came up is as follows (making them pretty much mandat= ory=20 TLVs if it agrees with the views of others);</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT face= =3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT face= =3DArial=20 size=3D2>Port-up message (0x80);</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT face= =3DArial=20 size=3D2>    Extension-TLV (dsl tech type)</FONT></SPAN></= DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT face= =3DArial=20 size=3D2>    Access-Loop-circuit-id (0x01)</FONT></SPAN></= DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT face= =3DArial=20 size=3D2>    DSL Line Attribute (0x04) with the following = sub=20 TLVs;</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008> <FONT= =20 size=3D2>       DSL-Type =3D 0x91;=20 Actual-Net-Data-Upstream =3D 0x81<SPAN class=3D342501308-29042008>;=20 Actual-Net-Data-Rate-Downstream =3D 0x82</SPAN></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT face= =3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT face= =3DArial=20 size=3D2>Port-down message (0x81);</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008>  =  =20 <FONT face=3DArial size=3D2>Extension  TLV (dsl tech=20 type)</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008>  =  =20 <FONT face=3DArial size=3D2>Access-Loop-circuit-id (0x01)</FONT></SPAN></= DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008>  =  =20 <FONT face=3DArial size=3D2>DSL Line Attribute (0x04) with the following = sub=20 TLVs;</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN=20 class=3D342501308-29042008>       <FON= T=20 size=3D2> DSL line state =3D 0x8F</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT face= =3DArial=20 size=3D2>All other TLVs are optional.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT face= =3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT face= =3DArial=20 size=3D2>Would appreciate confirmation from the WG regarding the=20 above.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT face= =3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT face= =3DArial=20 size=3D2>Thanks,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT face= =3DArial=20 size=3D2>Woj.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT face= =3DArial=20 size=3D2></FONT></SPAN> </DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px so= lid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> DE CNODDER Stefaan=20 [mailto:stefaan.de_cnodder@alcatel-lucent.be] <BR><B>Sent:</B> 29 April= 2008=20 09:52<BR><B>To:</B> Wojciech Dec (wdec); Busser, M;=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> RE: [ANCP] Manda= tory=20 TLVs in draft-ietf-ancp-protocol proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2>Hi Woj,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2>Take the following example: I have a network w= ith 2=20 NASses, NAS-A is doing hierarchical shaping, NAS-B just wants to have t= he=20 port information but is not doing hierarchical shaping (it is doing oth= er=20 things like OAM, ...).  This means NAS-A needs the bandwidth, whil= e=20 NAS-B does not need the bandwidth.  How should the flag be set in = this=20 case by the AN?  Set to 'Mandatory' for the port up messages to NA= S-A,=20 and set to 'Optional' for port up messages towards NAS-B? Or is it alwa= ys=20 set to 'Mandatory'?  From your answer below, I understand that it= =20 should be set to 'Optional' towards NAS-B.  Is that=20 correct?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2>NAS-B will simply ignore the bandwidth TLV.&nb= sp; If=20 such a flag would exist, and the flag is set to 'Mandatory' by the AN t= o=20 NAS-B, what should be the behavior of NAS-B?  Should it reject the= =20 whole message?  Maybe NAS-B is not supporting hierarchical shaping= , so=20 it might not support the bandwidth TLV.  Today, the bandwidht TLV = is=20 only mandatory to be put in the port up messages, but for the receiver = there=20 is nothing mandatory.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2>I believe the original intend of ANCP was that= the AN=20 does not need to know what the NAS is doing with this information, the = use=20 of the bandwidth is also not specified by ANCP, only an example is give= n=20 (which is shaping).  In the future there may be applications for w= hich=20 TLVs will be mandatory which are now optional.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2>regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2>Stefaan</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV><BR> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com] <BR><B>Sent:</B> maandag 28 april 2008=20 21:33<BR><B>To:</B> DE CNODDER Stefaan; Busser, M;=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> RE: [ANCP] Manda= tory=20 TLVs in draft-ietf-ancp-protocol proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial size=3D2></FONT> </= DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft= > <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> DE CNODDER Stefaan=20 [mailto:stefaan.de_cnodder@alcatel-lucent.be] <BR><B>Sent:</B> 28 Apr= il=20 2008 17:15<BR><B>To:</B> Wojciech Dec (wdec); Busser, M;=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> RE: [ANCP]=20 Mandatory TLVs in draft-ietf-ancp-protocol proposal<BR></FONT><BR></D= IV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>Take the bandwidth = sub-TLV in=20 port up messages as example.  The current protocol spec says tha= t it=20 is mandatory to be sent in port up messages.  that's ok.&nb= sp;=20 But it is not mandatory for the receiver to process the bandwidth=20 sub-TLV.  What is done with this information by the NAS is not=20 specified by ANCP, so you cannot make it mandatory for the receiver=20 side.<SPAN class=3D163161615-28042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008></SPAN></FONT></FONT></FONT></SPAN> <= /DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008><FONT color=3D#000000>Woj> Is the infor= mation=20 required by the application? It would appear for the dynamic shaping= =20 use-case to be most certainly so. Hence it is absolutely mandatory,=20 otherwise the message makes no sense for the=20 application.</FONT> <FONT color=3D#000000>In any case, if=20 </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT fa= ce=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>So it looks to me t= hat the=20 flag can only indicate what the receiver should do.  Then the fl= ag=20 makes sense.<SPAN class=3D163161615-28042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008></SPAN></FONT></FONT></FONT></SPAN> <= /DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008><FONT color=3D#000000>Woj> </FONT> = ;<FONT=20 color=3D#000000>The flag tells the receiver what info the sender thin= ks is=20 required to carry out the application. This in almost all cases has t= o=20 match up to what the receiver thinks is required. The=20 sender </FONT></SPAN></FONT></FONT></FONT></SPAN><SPAN=20 class=3D436050615-28042008><FONT color=3D#0000ff><FONT face=3DArial><= FONT=20 size=3D2><SPAN class=3D163161615-28042008><FONT color=3D#000000>doesn= 't tell the=20 receiver what to do with the=20 info.</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT fa= ce=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>If the receiver kno= ws what is=20 mandatory, then I do not see a reason why this has to be made explici= t in=20 the protocol.  It would only complicate the protocol.  As=20 already said by Michael: if a mandatory TLV is not there, then it is = just=20 a bug.<SPAN class=3D163161615-28042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008></SPAN></FONT></FONT></FONT></SPAN> <= /DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008><FONT color=3D#000000>Woj> Can you spec= ifically=20 describe what aspect of the protocol does it complicate?</FONT> = <FONT=20 color=3D#000000>It's just making explicitly clear what the protocol a= lready=20 has to implement anyway to be of any=20 use.</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT si= ze=3D+0><FONT=20 face=3DArial><FONT size=3D2><SPAN class=3D163161615-28042008>As to wh= ether it is=20 a bug, having such explicit marking makes it clear what/where the pro= blem=20 is when observing a messaging flow vs a lot of deduction work. I= n any=20 case, the other point being made here is that today the protocol= does=20 NOT specify what should happen if a mandatory TLV is=20 missing.</SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT si= ze=3D+0><FONT=20 face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008></SPAN></FONT></FONT></FONT></SPAN> <= /DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT si= ze=3D+0><FONT=20 face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008>-Woj.</SPAN></FONT></FONT></FONT></SPAN></= DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT fa= ce=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT fa= ce=3DArial=20 color=3D#0000ff size=3D2>regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT fa= ce=3DArial=20 color=3D#0000ff size=3D2>Stefaan</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT fa= ce=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FONT fa= ce=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV><BR> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft= > <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com] <BR><B>Sent:</B> maandag 28 april 2008=20 16:28<BR><B>To:</B> DE CNODDER Stefaan; Busser, M;=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> RE: [ANCP]=20 Mandatory TLVs in draft-ietf-ancp-protocol proposal<BR></FONT><BR></D= IV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D560491614-28042008><FONT fa= ce=3DArial=20 size=3D2>It's actually a mix of both. Inline...</FONT></SPAN></DIV><B= R> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2p= x solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dle= ft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>DE CNODDER=20 Stefaan<BR><B>Sent:</B> 28 April 2008 16:04<BR><B>To:</B> Wojciech = Dec=20 (wdec); Busser, M; ancp@ietf.org<BR><B>Cc:</B> Haag,=20 T<BR><B>Subject:</B> Re: [ANCP] Mandatory TLVs in=20 draft-ietf-ancp-protocol proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Hi,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>This new mandatory flag, what is exactly i= ts=20 meaning?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT= =20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>(1) if flag = set to=20 "mandatory", then the *receiver* of this TLV MUST process it, and i= f=20 unrecognized must drop the message<SPAN class=3D560491614-28042008>= <FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></D= IV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT= =20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> = ;</DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT= =20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>If a received TLV = is has=20 the "mandatory" flag set then the receiver MUST drop the= =20 message and report an error to the sender if it doesn't recogn= ize=20 the TLV.</FONT> </SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT= =20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><SPAN class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>If a the receiver = expects=20 a "mandatory" TLV but doesn't receive it, the message MUS= T=20 be droped and an error report sent to=20 the sender.</FONT> </SPAN></FONT></FONT></FONT></SPAN></S= PAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>OR</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT= =20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>(2) if flag = is set=20 to"mandatory", then the *sender* MUST include it in the message for= =20 which it is defined<SPAN class=3D560491614-28042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></D= IV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT= =20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> = ;</DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT= =20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>The sender MUST in= clude=20 mandatory TLVs as defined by the=20 protocol-spec/applications.</FONT></SPAN></FONT></FONT></FONT></SPA= N></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>The current protocols draft says for certa= in TLVs=20 that they are mandatory, but that applies to the sender of it=20 (interpretation 2).  The flag would indicate interpretation 1 = (like=20 for Radius VSAs?)?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT= =20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>If the higher ord= er bit is=20 set to "0" means that it is mandatory, then currently defined optio= nal=20 defined TLVs suddenly become mandatory which is not good.<SPAN=20 class=3D560491614-28042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></D= IV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT= =20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> = ;</DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT= =20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>Woj> Only the c= urrently=20 used TLVs become mandatory. If they are not used/implemented w= e can=20 re-define them as optional (set flag to 1) at no cost.=20 </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT= =20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>But I would first= to=20 understand the exact meaning of this mandatory flag.  Defining= such=20 a flag indeed looks useful but then as interpretation 1, and I woul= d say=20 that if flag set to 1, then it is mandatory and actually, it is pos= sible=20 that a TLV is sent sometimes as optional and sometimes as=20 mandatory.<SPAN class=3D560491614-28042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></D= IV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT= =20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> = ;</DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT= =20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>Woj> Precisely,= that is=20 possible on a per application basis.</FONT> <FONT=20 color=3D#000000>Having the flag would make troubleshooting of a mes= sage=20 flow much more explicit (today, with any problem one has = to=20 browse the drafts to figure out what MUST be there vs what SHOULD b= e=20 there all while looking what is actually=20 there)</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT= =20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 size=3D2><= SPAN=20 class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> = ;</DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT= =20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 size=3D2><= SPAN=20 class=3D560491614-28042008>Regards,</SPAN></FONT></FONT></FONT></SP= AN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT= =20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 size=3D2><= SPAN=20 class=3D560491614-28042008>Woj.</SPAN></FONT></FONT></FONT></SPAN><= /DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT= =20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 size=3D2><= SPAN=20 class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> = ;</DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Stefaan</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT> </DIV><BR> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dle= ft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>Wojciech Dec=20 (wdec)<BR><B>Sent:</B> donderdag 24 april 2008 14:19<BR><B>To:</B>= =20 Busser, M; ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> R= e:=20 [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol=20 proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D709295811-24042008><FONT = face=3DArial=20 size=3D2>Hi Michael,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D709295811-24042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D709295811-24042008><FONT = face=3DArial=20 size=3D2>inline...</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 = 2px solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3D= left> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>Busser,=20 M<BR><B>Sent:</B> 24 April 2008 13:13<BR><B>To:</B>=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> Re: [ANCP]= =20 Mandatory TLVs in draft-ietf-ancp-protocol=20 proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2= >Hi Woi,=20 all</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2= >I see the=20 problem but i can not see, how an additional flag will help solvi= ng=20 this problem.</FONT></SPAN></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2= >Lets=20 assume your first proposal.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT=20 size=3D2>If an implementation does not send the complete&nbs= p;TLV,=20 even it is defined to be mandatory, I would call t= his a=20 bug and I can not see, how an additional flag can help here.= <SPAN=20 class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DI= V> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT=20 size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DI= V> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT=20 size=3D2><SPAN class=3D709295811-24042008>Woj> The way it help= s, and=20 other protocols bear proof of this scheme, is that it is easier f= or=20 implementations to reconcile errors resulting out of "Mandatory" = and=20 "Optional" TLV sets. The key to this lies on a per applicati= on=20 basis. One application may mandate TLV A for operation, while ano= ther=20 might not. Resolving such issues when implementing or troubleshoo= ting=20 multiple applications is not always trivial.=20 </SPAN></FONT></FONT></SPAN><SPAN class=3D364043506-24042008><FON= T=20 face=3DArial><FONT size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT=20 size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DI= V> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2= >Your=20 second proposal seems obviously be required to keep existing= =20 things working, if we agree on your first proposal.=20 </FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2= >But from=20 my point of view it also assumes, that all existing=20 implementations are using the same set of TLVs now.=20 </FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT=20 size=3D2>And I am not sure about that. <SPAN=20 class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DI= V> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT=20 size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DI= V> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT=20 size=3D2><SPAN class=3D709295811-24042008>Woj> This would be a= good=20 thing for the WG to discuss. There most evidently is a fair amoun= t=20 of "dead wood" in the current spec, ie stuff that nobody=20 yet implements or cares about.  In the former case, we = could=20 re-cast that material using the new notions/extensions, in the la= tter=20 case simply chop it out.</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2= ><SPAN=20 class=3D364043506-24042008><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV></FONT></SPAN> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT=20 size=3D2>Therefore I disagree with your first proposal. I recomme= nd, the=20 better way will be to be more precise in definitions.<SPAN=20 class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DI= V> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2= >In my=20 mind, it is a bug, if a mandatory TLV is missing. It is up to the= =20 robustness of the implementation to deal with this=20 situation.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT si= ze=3D2>Is=20 it really neccesary to define the behavior of a network element i= n=20 this case of failure in the ancp protocol itself? <SPAN=20 class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DI= V> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT=20 size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DI= V> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT=20 size=3D2><SPAN class=3D709295811-24042008>Woj> Other people ha= ve faced=20 this problem before, and I would rather go with the lessons they= =20 learned, rather than clinging to hopes of perfect textual definit= ions=20 and implementations. Other than backwards compatibility, I do not= see=20 in your statements a valid reason to object to the=20 1st proposal, particularly for new applications since it can= only=20 make things more robust. The counter argument of being precise in= the=20 definitions, as evidenced by the current spec, is admirable and n= eeds=20 to be there, with this proposal providing an extra level of robus= tness=20 and visibility of any problems. </SPAN></FONT></FONT></SPAN></DIV= > <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT=20 size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DI= V> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT=20 size=3D2><SPAN=20 class=3D709295811-24042008>Thanks,</SPAN></FONT></FONT></SPAN></D= IV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FONT=20 size=3D2><SPAN=20 class=3D709295811-24042008>Woj.</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2= >If=20 optional TLVs are not present in a message, we should describe so= me=20 kind of default behaviour, as you already stated.</FONT></SPAN></= DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2= > <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2= >Comments=20 on=20 draft-ietf-ancp-protocol-02.txt:</FONT></SPAN></DIV></FONT></SPAN= ></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT face= =3DArial>It=20 is not clearly stated, if the TLV  "<SPAN lang=3DEN-GB= =20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; mso-far= east-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-= language: DE; mso-bidi-language: AR-SA">DSL=20 Line Attributes "<FONT face=3DArial> is mandatory or optional.=20 </FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT=20 face=3DArial><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; mso-far= east-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-= language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>In fact it is mandatory because some of its SubTLVs = are=20 mandatory. </FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT=20 face=3DArial><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; mso-far= east-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-= language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>We should spent a sentence to make this=20 clear.</FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2= ><SPAN=20 class=3D364043506-24042008><FONT size=3D2><FONT face=3DArial>It i= s not=20 clearly stated, if the TLV  "<SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; mso-far= east-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-= language: DE; mso-bidi-language: AR-SA">Service-Profile-Name"<FONT=20 face=3DArial> is mandatory or=20 optional.</FONT></SPAN></FONT></FONT></SPAN></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2= ><SPAN=20 class=3D364043506-24042008><FONT size=3D2><FONT face=3DArial><SPA= N=20 lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; mso-far= east-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-= language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>I prefer mandatory because it is essetial for the us= e case=20 Line=20 Config. </FONT></SPAN></FONT></FONT></SPAN></DIV></FONT></SP= AN><SPAN=20 class=3D364043506-24042008><FONT face=3DArial size=3D2></FONT></S= PAN> <DIV><SPAN class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2= >Section=20 5.4.3 Line Config, where the TLVs are mentioned (page=20 35):</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2= > =20 ...defined in section 5.4.1....    must be correct= ed=20 to    ...defined in section=20 5.4.2........</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2= >Section=20 5.4.4 OAM, where the TLVs are mentioned (page 36 and page=20 38):</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size=3D2= > =20 ...defined in section 5.4.1....    must be correct= ed=20 to    ...defined in section=20 5.4.2........</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV></FONT></SPAN><SPAN class=3D364043506-24042008><FONT face=3D= Arial=20 size=3D2></FONT></SPAN> </DIV></DIV> <DIV><SPAN class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN class=3D364043506-2404200= 8><FONT=20 face=3DArial color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial color=3D= #0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV align=3Dleft><FONT color=3D#000080 size=3D2> <P align=3Dleft>Best Regards; Freundliche Gr=FC=DFe </P></FONT><B= ><FONT=20 color=3D#000080> <P>Michael Busser</P></B></FONT><FONT size=3D1> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt">T-Systems Enterprise Services GmbH=20 </SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: 8= pt"><FONT=20 size=3D1>Production Line Network Centric Systems</FONT></SPAN></D= IV> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: 8= pt"><FONT=20 size=3D1>ICT-Systems Integration</FONT></SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: 8= pt"><FONT=20 size=3D1>Network Integration Services</FONT></SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: 8= pt"><FONT=20 size=3D1></FONT><SPAN style=3D"COLOR: navy"></SPAN><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy"><FONT face=3DArial color= =3D#000000=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: 8= pt"><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy"><FONT color=3D#000000=20 size=3D1>Br=FCckes 2 -8, 55545 Bad Kreuznach<BR>Postfach 9100, 55= 541 Bad=20 Kreuznach<BR>+49 671 8333 8911 (Phone)<BR>+49 521 9210 = 3859=20 (Fax)<BR>+49 151 1211 9689 (Mobile)<BR>E-Mail: <A=20 href=3D"mailto:michael.busser@t-systems.com">michael.busser@t-sys= tems.com</A></FONT></SPAN></DIV></SPAN> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN></DIV><SPAN=20 style=3D"FONT-SIZE: 8pt">Internet: </SPAN><SPAN=20 style=3D"FONT-SIZE: 8pt"><p:onmouseclick hyperlinktype=3D"url"=20 href=3D"http://www.t-systems.com/"></p:onmouseclick><A=20 onclick=3Dwindow.event.cancelBubble=3Dtrue;=20 href=3D"http://www.t-systems.com/" target=3D_parent><FONT=20 color=3D#6699ff>http://www.t-systems.com</FONT></A></SPAN><SPAN=20 style=3D"FONT-SIZE: 8pt"> </SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '90 0 50'; mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '90 0 50'; mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN> </DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '90 0 50'; mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: 8= pt"><FONT=20 size=3D3><FONT size=3D1><SPAN=20 style=3D"FONT-SIZE: 7.5pt; COLOR: black; FONT-FAMILY: Arial">T-Sy= stems=20 Enterprise Services GmbH<BR>Aufsichtsrat: Ren=E9 Obermann=20 (Vorsitzender)<BR>Executive Committee: Reinhard Clemens=20 (Vorsitzender)*, Helmut Binder, Albert Henn, Olaf Heyden*, Katrin= =20 Horstmann, Ulrich Kemp, Wilfried Peters*,<BR>Dr. Herbert Schaaff*= ,=20 Zvezdana Seeger*<BR>Handelsregister: Amtsgericht Frankfurt am Mai= n HRB=20 55933<BR>Sitz der Gesellschaft: Frankfurt am Main<BR>WEEE-Reg.-Nr= .=20 DE87523644<BR>*Gesch=E4ftsf=FChrer gem. =A7 35=20 GmbHG</SPAN></FONT></FONT></SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '90 0 50'; mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: 8= pt"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT face=3DArial=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '90 0 50'; mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: 8= pt"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT size=3D1>Notice: This transmittal = and/or=20 attachments may be privileged or confidential. If you are not the= =20 intended recipient, you are hereby notified that you have receive= d=20 this transmittal in error; any review, dissemination, or copying = is=20 strictly prohibited. If you received this transmittal in error, p= lease=20 notify us immediately by reply and immediately delete this messag= e and=20 all its attachments. Thank you. </FONT><FONT size=3D1><BR>T-Syste= ms =96=20 Business flexibility </FONT></DIV></SPAN></SPAN> <DIV><FONT face=3DArial size=3D2></FONT> </DIV></FONT></DIV> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"> <DIV></DIV> <DIV class=3DOutlookMessageHeader lang=3Dde dir=3Dltr align=3Dl= eft> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><= SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p= ></o:p></SPAN></FONT></P><FONT=20 face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12p= t"><FONT=20 face=3DArial size=3D2></FONT> <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2> </SPAN></FONT></DIV> <DIV class=3DSection1> <DIV> <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahom= a">Von:</SPAN></FONT></B><FONT=20 face=3DTahoma size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> ancp-bounces@ie= tf.org=20 [mailto:ancp-bounces@ietf.org] <B><SPAN style=3D"FONT-WEIGHT: b= old">Im=20 Auftrag von </SPAN></B>Wojciech Dec (wdec)<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Gesendet:</SPAN></B> Mittwoch, 23. = April=20 2008 14:54<BR><B><SPAN style=3D"FONT-WEIGHT: bold">An:</SPAN></= B>=20 ancp@ietf.org<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Betreff:</SPAN></B> [ANCP] Mandator= y TLVs=20 in draft-ietf-ancp-protocol=20 proposal</SPAN></FONT><o:p></o:p></P></DIV> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><S= PAN=20 style=3D"FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi=20 All,</SPAN></FONT><SPAN lang=3DEN-GB> </SPAN><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Continuing with t= he=20 series of e-mails regarding basic protocol issues still to be=20 addressed, I now would now like to ask your feedback regarding = the=20 distinction the protocol places on mandatory TLVs. Given the le= ngth=20 of this mail I'll first cut to the proposal, and after it you c= an=20 find the problem description.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The proposal whic= h I am=20 putting in front of the WG is to define a new TLV format which= =20 contains at a minimum a Mandatory flag (much like Radius VSAs d= o).=20 We could have this TLV Flag be defined only for new=20 applications.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">A second proposal= would=20 be try to make this flag work with existing ones by for example= =20 defining the highest order bit of the TLV# field to mean "Manda= tory"=20 when set to "0". This would be invisible to exiting implementat= ions,=20 but newer ones may have problems in communicating with older on= es=20 when the latter do not send all TLVs. But that can also be addr= essed=20 by simply forming the set of mandatory TLVs to be the ones that= all=20 implementations currently send by=20 default.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Without additiona= l=20 feedback, I will assume that the WG is fine with the first prop= osal,=20 and also with the 2nd one conditional on deriving a suitable=20 "commonly used" TLV set.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The problem in mo= re=20 detail: </SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Currently the sit= uation=20 is that Mandatory TLVs are only stated to be as such in the bod= y of=20 the protocol draft spec, with an implementer having to scour fa= irly=20 attentively the text. Eg "Type (Access-Loop-Circuit-ID =3D 0x01= ): This=20 is a mandatory TLV", etc.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The behaviour of = an=20 implementation that receives a message with a missing mandatory= TLV=20 is not defined at all, and the opposite is handled but not very= =20 robustly, i.e. when receiving a TLV but not recognizing it, and= =20 implementation is free to discard it (even if it is mandatory!)= .=20 This is a recipe for interoperability problems and an implement= ation=20 mine field.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">This problem is=20 complicated by different applications. For example the current = OAM=20 section states the following regarding TLVs that are to be carr= ied=20 in the request message (my italics):</SPAN></FONT><o:p></o:p></= P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">"</SPAN></FONT>=20 <BR><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN lan= g=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier N= ew'">Following=20 TLVs<B><I><SPAN style=3D"FONT-WEIGHT: bold; FONT-STYLE: italic"= >=20 can</SPAN></I></B> appear in this message:=20 </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN lang= =3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier N= ew'">      =20 o Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section=20 5.4.1    </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN lang= =3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier N= ew'">      =20 o Type (Access-Aggregation-Circuit-ID-Binary =3D 0x06): defined= in=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack size= =3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier N= ew'">        =20 section 5.4.1. </SPAN></FONT><BR><FONT face=3D"Courier New"=20 color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier N= ew'"> </SPAN></FONT>=20 <BR><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN lan= g=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier N= ew'">      =20 o Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03): defined = in=20 section </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dbl= ack=20 size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier N= ew'">        =20 5.4.1.  </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN lang= =3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier N= ew'">      =20 o Type (OAM-Loopback-Test-Parameters =3D 0x07): Parameters rela= ted=20 to  </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Db= lack=20 size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier N= ew'">        =20 loopback test. This is an optional TLV. If this TLV is not pres= ent=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack size= =3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier N= ew'">        =20 in the request message, the DSLAM SHOULD use locally determined= =20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack size= =3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier N= ew'">        =20 default values for the test parameters. =20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack size= =3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier N= ew'">"</SPAN></FONT>=20 <BR><FONT face=3DArial color=3Dblack size=3D2><SPAN lang=3DEN-U= S=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">(NO= TE: The=20 last "SHOULD" appears to be inappropriate. If the TLV is missin= g,=20 the DSLAM MUST have some default parameters, or return an=20 error)</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial color=3Dblack size=3D2><SPAN lang=3DEN-US= =20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">The= "can"=20 above indicates that they're all optional, while clearly the=20 application cannot run its course without one or more of these= =20 fields. Here we have a case where one could have a perfectly=20 compliant implementation that ignores all these=20 TLVs=85</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial color=3Dblack size=3D2><SPAN lang=3DEN-US= =20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">-Wo= j.</SPAN></FONT><SPAN=20 lang=3DEN-US> </SPAN><o:p></o:p></P> <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><FONT=20 face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"><BR><BR><BR><BR><BR><BR><BR><BR><BR><= BR><o:p></o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOT= E></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML> --_000_48C276B536524E478C659685995F6AA539DBB4F194RBSJXadredbac_-- --===============0185673203== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============0185673203==-- From ancp-bounces@ietf.org Tue Apr 29 11:07:41 2008 Return-Path: <ancp-bounces@ietf.org> X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05F8528C0DD; Tue, 29 Apr 2008 11:07:41 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B7B33A6BE7 for <ancp@core3.amsl.com>; Tue, 29 Apr 2008 11:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.49 X-Spam-Level: X-Spam-Status: No, score=-6.49 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b89VkVsVoVLz for <ancp@core3.amsl.com>; Tue, 29 Apr 2008 11:07:35 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 019193A6A17 for <ancp@ietf.org>; Tue, 29 Apr 2008 11:07:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,723,1199660400"; d="scan'208,217";a="7651951" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 29 Apr 2008 20:07:21 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3TI7LMA027683; Tue, 29 Apr 2008 20:07:21 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3TI7LOZ024303; Tue, 29 Apr 2008 18:07:21 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Apr 2008 20:07:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Apr 2008 20:07:04 +0200 Message-ID: <D9872168DBD43A41BD71FFC4713274D404FF172D@xmb-ams-33b.emea.cisco.com> In-Reply-To: <48C276B536524E478C659685995F6AA539DBB4F194@RBSJX.ad.redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal thread-index: AcilQRMfK4kdawUKQOWs5fdBngS8QQAAr04QACRhApAAC0ujAADNHRywAADiEXAAAbhxoAAAWwcQACIOoKAAAXsqYAASvbCgAAE4sjA= References: <1B6169C658325341A3B8066E23919E1C01230DC1@S4DE8PSAANK.mitte.t-com.de><1B6169C658325341A3B8066E23919E1CFBC5C4@S4DE8PSAANK.mitte.t-com.de><D9872168DBD43A41BD71FFC4713274D404FA6ACC@xmb-ams-33b.emea.cisco.com><7A6D4815C5E8F74988784FEBD50F2F1E01ABAA16@FRVELSMBS22.ad2.ad.alcatel.com><D9872168DBD43A41BD71FFC4713274D404FF10C1@xmb-ams-33b.emea.cisco.com><7A6D4815C5E8F74988784FEBD50F2F1E01ABAAA4@FRVELSMBS22.ad2.ad.alcatel.com><D9872168DBD43A41BD71FFC4713274D404FF1233@xmb-ams-33b.emea.cisco.com><7A6D4815C5E8F74988784FEBD50F2F1E01ABAC34@FRVELSMBS22.ad2.ad.alcatel.com> <D9872168DBD43A41BD71FFC4713274D404FF13AD@xmb-ams-33b.emea.cisco.com> <48C276B536524E478C659685995F6AA539DBB4F194@RBSJX.ad.redback.com> From: "Wojciech Dec (wdec)" <wdec@cisco.com> To: "Peter Arberg" <parberg@redback.com>, "DE CNODDER Stefaan" <stefaan.de_cnodder@alcatel-lucent.be>, "Busser, M" <Michael.Busser@t-systems.com>, <ancp@ietf.org> X-OriginalArrivalTime: 29 Apr 2008 18:07:21.0021 (UTC) FILETIME=[DE4CC6D0:01C8AA23] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=110649; t=1209492441; x=1210356441; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20<wdec@cisco.com> |Subject:=20RE=3A=20Re=3A=20[ANCP]=20Mandatory=20TLVs=20in= 20draft-ietf-ancp-protocol=20proposal |Sender:=20; bh=PCzV9C9N3vnNfVVIg13rXz0mwbo6ZTNihQIAQuuGZ9c=; b=HMNEES51CRZucrX8a9NAnajTrlvjlKvqZ4eFpNjZooAEPGVbigMYV/4H6Z cPRB2Mvs0gMY5M1400pWsjnk1APoHy8xsUXnSYB9cBhmoNSVD4z4axEDt0NM hudJCO6LCX; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: "Haag, T" <Thomas.Haag@t-systems.com> Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list <ancp.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/ancp> List-Post: <mailto:ancp@ietf.org> List-Help: <mailto:ancp-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1445035759==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1445035759== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8AA23.DE24331A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8AA23.DE24331A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Peter, =20 =20 ________________________________ From: Peter Arberg [mailto:parberg@redback.com]=20 Sent: 29 April 2008 19:34 To: Wojciech Dec (wdec); DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 Hi Woj, =20 I agree with Michael and Stefan on this issue, I do not see a need to = change the existing implementation with a mandatory/optional flag.=20 =20 Woj> Please indicate where in my proposal did you see anything about = changing existing implementaions?=20 =20 I think I understand your arguments, but I do not agree with them. I = think most places in the draft it is clear what is defined as mandatory and optional.=20 =20 I agree on the point we need to go through the draft and make = clarifications to what TLV's in what capability types are mandatory and optional, and make more = description what should happen if mandatory TLVs are not included.=20 =20 Woj> Exactly.=20 =20 I think the DSLF TR-101 document has a good example of such a = description in it's=20 "Table 3 - Access loop characteristics sub-options", and I think if we = do the same for each capability types TLV's in the ANCP draft it will be a good help. =20 Woj> Indeed, pre-ceeded by some rationalization. The appears to be no = reason for some of the DSLF "mandatory" TLVs. =20 I do not agree with your point that it is not listed if "rate" is = mandatory or optional, it is clearly listed as a mandatory TLV, and as such it should be included in the = port up message, I really do not understand what confusion you have with this.=20 =20 Woj> The text states: =20 =20 5. Type (DSL Line Attributes =3D 0x04):=20 Length : variable (up to 1024 bytes)=20 Value : This consists of one or more Sub-TLVs corresponding to DSL=20 line attributes. No sub-TLVs other than the "DSL type" and "DSL=20 line state" SHOULD be included in a PORT DOWN message.=20 The general format of the sub-TLVs is identical to the general TLV=20 format. The value field in each sub-TLV is padded to a 4-octet=20 alignment. The Length field in each sub-TLV contains the actual=20 number of bytes in the TLV (not including the padding if present).=20 Current defined sub-TLV types are start from 0x81. =20 Maybe you can point me to where exatly it is stated clearly as being = mandatory, or otherwise explain why you "not agree"?=20 =20 The fact you say "Port UP" and "OAM" is best considered as legacy = applications, I have some trouble with this as well, since ANCP running in production networks = use them, and as such it is a central part of the ANCP specifications we need to finish as = soon as possible.=20 =20 Woj> I should have said legacy applications from a protocol messaging = perspective, not usage, nor support. It's quite clear that GSMP derived = messaging has baggage that is un called for in new applications. =20 I think Stefaan's example is very valid, that we do not need to make = mandatory requirements to=20 what receivers of ANCP information use such info. for. I don't think = we should try and make the ANCP specifications "mandatory" for box behavior, I think it is much = more important for the=20 working group to make the protocol specifications easy to understand = and get the first documentation finish and published, so the protocol can be used for different sets of = applications, and make sure new applications can be added later.=20 =20 Woj> Indeed the aim of the WG to define a protocol that is relatively = simple and easy to understand, not just to implementers but also to = people using it, and across vendors. Currently, having anyone operating = the device be familiar in what cases a TLV is mandatory and in what = optional requires a thorough understanding of the spec, across = applications. This is not easy, but I'll conceede that for the = applications implemented so far we could live with it.=20 =20 I do think that by documenting if a TLV is mandatory or optional inside = a specific capability type, it is easy to understand what must be sent to support the defined = application/capability type.=20 =20 Woj> Of course it is, the whole spec is about this. The problem comes = when people start to re-use well known TLVs for different applications, = and then trying to make sense of it all becomes non-trivial. Why do you = think both BGP and Diamater, and a number of other protocols have = definied "Mandatory" flags? Just for kicks? It's a well known protocol = design tool, that comes handy when re-using same data across multiple = applications. =20 Then if anybody want to include new capability types or sub-TLVs later = to address specific applications, then I think changes can be discussed at that time instead of trying to = change existing protocol implementations.=20 =20 Woj> Again I ask, where in the proposal did you see *anything* = requiring a change to an existing implementation. Please be specific. I = see that your main objection is on this issue, which means that you = accept proposal 1 (have such a flag for new TLVs/apps). It would also be useful if you indicated whether the list of TLVs = provided below is what you'd expect to be the minimum mandatory set. =20 Cheers, Woj. =20 cheers, Peter =20 =20 =20 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = Of Wojciech Dec (wdec) Sent: 29. april 2008 02:28 To: DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 Stefaan, =20 a number of points: 1. There currently is to my knowledge no implementation of ANCP there = that doesn't send the DSL Line attributes info by default in Port-UP = messages? The support of HS on the NAS is an orthogonal issue. 2. The current ancp protocol draft (02) doesn't say whether the rate = info is optional or mandatory, it only states that the sub-TLVs are = mandatory. Based on this, an implementer can be justified to expect = port-ups to *always* have the rate-info tlv (ie treat them as = mandatory). Equally, she's justified in considering this as optional. 3. The port-up and OAM are best considered as legacy applications for = ANCP. The re-use of any of the GSMP defined fields is already out of the = question due to constrains put in place by the existing use-case = messaging. Needless to say, this wasn't as thoroughly designed as it = should have been, and with the OAM and port-up apps being coupled. 4. It's up to the application to define what TLVs are mandatory and = which aren't, as you also state. The AN does not need to know what the = NAS will do with the info, BUT it needs to send the right TLVs for the = application (eg if we had a hypothetical AN that only sends Port-up's = with line-id, it would be next to useless for the dynamic shaping = application). =20 With all this in mind it's useful to re-read what I proposed = originally below regarding the mandatory flag: 1. "have this TLV Flag be = defined only for new applications" and 2. The notion of the mandatory = flag applying to existing TLVs being "conditional on deriving a = suitable "commonly used" TLV set." The latter point would ensure that = existing implementations do not need to change, but future ones can take = advantage of the extra robustness. =20 Hence, can the WG derive a set of commonly used, i.e. always used, = TLVs for existing implementations? The list I came up is as follows (making them pretty much mandatory = TLVs if it agrees with the views of others); =20 Port-up message (0x80); Extension-TLV (dsl tech type) Access-Loop-circuit-id (0x01) DSL Line Attribute (0x04) with the following sub TLVs; DSL-Type =3D 0x91; Actual-Net-Data-Upstream =3D 0x81; = Actual-Net-Data-Rate-Downstream =3D 0x82 =20 Port-down message (0x81); Extension TLV (dsl tech type) Access-Loop-circuit-id (0x01) DSL Line Attribute (0x04) with the following sub TLVs; DSL line state =3D 0x8F =20 All other TLVs are optional. =20 Would appreciate confirmation from the WG regarding the above. =20 Thanks, Woj. =20 ________________________________ From: DE CNODDER Stefaan = [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Sent: 29 April 2008 09:52 To: Wojciech Dec (wdec); Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 =20 Hi Woj, =20 Take the following example: I have a network with 2 NASses, NAS-A is = doing hierarchical shaping, NAS-B just wants to have the port = information but is not doing hierarchical shaping (it is doing other = things like OAM, ...). This means NAS-A needs the bandwidth, while = NAS-B does not need the bandwidth. How should the flag be set in this = case by the AN? Set to 'Mandatory' for the port up messages to NAS-A, = and set to 'Optional' for port up messages towards NAS-B? Or is it = always set to 'Mandatory'? From your answer below, I understand that it = should be set to 'Optional' towards NAS-B. Is that correct? =20 NAS-B will simply ignore the bandwidth TLV. If such a flag would = exist, and the flag is set to 'Mandatory' by the AN to NAS-B, what = should be the behavior of NAS-B? Should it reject the whole message? = Maybe NAS-B is not supporting hierarchical shaping, so it might not = support the bandwidth TLV. Today, the bandwidht TLV is only mandatory = to be put in the port up messages, but for the receiver there is nothing = mandatory. =20 I believe the original intend of ANCP was that the AN does not need = to know what the NAS is doing with this information, the use of the = bandwidth is also not specified by ANCP, only an example is given (which = is shaping). In the future there may be applications for which TLVs = will be mandatory which are now optional. =20 regards, Stefaan =20 =20 =20 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: maandag 28 april 2008 21:33 To: DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 =20 ________________________________ From: DE CNODDER Stefaan = [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Sent: 28 April 2008 17:15 To: Wojciech Dec (wdec); Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 =20 Take the bandwidth sub-TLV in port up messages as example. The = current protocol spec says that it is mandatory to be sent in port up = messages. that's ok. But it is not mandatory for the receiver to = process the bandwidth sub-TLV. What is done with this information by = the NAS is not specified by ANCP, so you cannot make it mandatory for = the receiver side.=20 =20 Woj> Is the information required by the application? It would appear = for the dynamic shaping use-case to be most certainly so. Hence it is = absolutely mandatory, otherwise the message makes no sense for the = application. In any case, if=20 =20 So it looks to me that the flag can only indicate what the receiver = should do. Then the flag makes sense.=20 =20 Woj> The flag tells the receiver what info the sender thinks is = required to carry out the application. This in almost all cases has to = match up to what the receiver thinks is required. The sender doesn't = tell the receiver what to do with the info. =20 If the receiver knows what is mandatory, then I do not see a reason = why this has to be made explicit in the protocol. It would only = complicate the protocol. As already said by Michael: if a mandatory TLV = is not there, then it is just a bug.=20 =20 Woj> Can you specifically describe what aspect of the protocol does = it complicate? It's just making explicitly clear what the protocol = already has to implement anyway to be of any use. As to whether it is a bug, having such explicit marking makes it = clear what/where the problem is when observing a messaging flow vs a lot = of deduction work. In any case, the other point being made here is that = today the protocol does NOT specify what should happen if a mandatory = TLV is missing. =20 -Woj. =20 regards, Stefaan =20 =20 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: maandag 28 april 2008 16:28 To: DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 It's actually a mix of both. Inline... ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On = Behalf Of DE CNODDER Stefaan Sent: 28 April 2008 16:04 To: Wojciech Dec (wdec); Busser, M; ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 =20 Hi, =20 This new mandatory flag, what is exactly its meaning? =20 (1) if flag set to "mandatory", then the *receiver* of this TLV = MUST process it, and if unrecognized must drop the message=20 =20 If a received TLV is has the "mandatory" flag set then the receiver = MUST drop the message and report an error to the sender if it doesn't = recognize the TLV.=20 If a the receiver expects a "mandatory" TLV but doesn't receive it, = the message MUST be droped and an error report sent to the sender.=20 =20 OR =20 (2) if flag is set to"mandatory", then the *sender* MUST include it = in the message for which it is defined=20 =20 The sender MUST include mandatory TLVs as defined by the = protocol-spec/applications. =20 The current protocols draft says for certain TLVs that they are = mandatory, but that applies to the sender of it (interpretation 2). The = flag would indicate interpretation 1 (like for Radius VSAs?)? =20 If the higher order bit is set to "0" means that it is mandatory, = then currently defined optional defined TLVs suddenly become mandatory = which is not good.=20 =20 Woj> Only the currently used TLVs become mandatory. If they are not = used/implemented we can re-define them as optional (set flag to 1) at no = cost.=20 =20 But I would first to understand the exact meaning of this mandatory = flag. Defining such a flag indeed looks useful but then as = interpretation 1, and I would say that if flag set to 1, then it is = mandatory and actually, it is possible that a TLV is sent sometimes as = optional and sometimes as mandatory.=20 =20 Woj> Precisely, that is possible on a per application basis. Having = the flag would make troubleshooting of a message flow much more explicit = (today, with any problem one has to browse the drafts to figure out what = MUST be there vs what SHOULD be there all while looking what is actually = there) =20 Regards, Woj. =20 regards, Stefaan =20 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On = Behalf Of Wojciech Dec (wdec) Sent: donderdag 24 april 2008 14:19 To: Busser, M; ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 Hi Michael, =20 inline... ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On = Behalf Of Busser, M Sent: 24 April 2008 13:13 To: ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 Hi Woi, all =20 I see the problem but i can not see, how an additional flag will = help solving this problem. =20 Lets assume your first proposal. If an implementation does not send the complete TLV, even it is = defined to be mandatory, I would call this a bug and I can not see, how = an additional flag can help here.=20 =20 Woj> The way it helps, and other protocols bear proof of this = scheme, is that it is easier for implementations to reconcile errors = resulting out of "Mandatory" and "Optional" TLV sets. The key to this = lies on a per application basis. One application may mandate TLV A for = operation, while another might not. Resolving such issues when = implementing or troubleshooting multiple applications is not always = trivial.=20 =20 Your second proposal seems obviously be required to keep existing = things working, if we agree on your first proposal.=20 But from my point of view it also assumes, that all existing = implementations are using the same set of TLVs now.=20 And I am not sure about that. =20 =20 Woj> This would be a good thing for the WG to discuss. There most = evidently is a fair amount of "dead wood" in the current spec, ie stuff = that nobody yet implements or cares about. In the former case, we could = re-cast that material using the new notions/extensions, in the latter = case simply chop it out. =20 Therefore I disagree with your first proposal. I recommend, the = better way will be to be more precise in definitions.=20 In my mind, it is a bug, if a mandatory TLV is missing. It is up to = the robustness of the implementation to deal with this situation. Is it really neccesary to define the behavior of a network element = in this case of failure in the ancp protocol itself? =20 =20 Woj> Other people have faced this problem before, and I would = rather go with the lessons they learned, rather than clinging to hopes = of perfect textual definitions and implementations. Other than backwards = compatibility, I do not see in your statements a valid reason to object = to the 1st proposal, particularly for new applications since it can only = make things more robust. The counter argument of being precise in the = definitions, as evidenced by the current spec, is admirable and needs to = be there, with this proposal providing an extra level of robustness and = visibility of any problems.=20 =20 Thanks, Woj. =20 If optional TLVs are not present in a message, we should describe = some kind of default behaviour, as you already stated. =20 =20 =20 =20 =09 Comments on draft-ietf-ancp-protocol-02.txt: =20 It is not clearly stated, if the TLV "DSL Line Attributes " is = mandatory or optional.=20 In fact it is mandatory because some of its SubTLVs are mandatory.=20 We should spent a sentence to make this clear. =20 It is not clearly stated, if the TLV "Service-Profile-Name" is = mandatory or optional. I prefer mandatory because it is essetial for the use case Line = Config.=20 =09 =20 Section 5.4.3 Line Config, where the TLVs are mentioned (page 35): ...defined in section 5.4.1.... must be corrected to = ...defined in section 5.4.2........ =20 =09 Section 5.4.4 OAM, where the TLVs are mentioned (page 36 and page = 38): ...defined in section 5.4.1.... must be corrected to = ...defined in section 5.4.2........ =20 =20 =20 =20 Best Regards; Freundliche Gr=FC=DFe=20 Michael Busser =09 T-Systems Enterprise Services GmbH=20 Production Line Network Centric Systems ICT-Systems Integration Network Integration Services =20 Br=FCckes 2 -8, 55545 Bad Kreuznach Postfach 9100, 55541 Bad Kreuznach +49 671 8333 8911 (Phone) +49 521 9210 3859 (Fax) +49 151 1211 9689 (Mobile) E-Mail: michael.busser@t-systems.com =09 Internet: http://www.t-systems.com <http://www.t-systems.com/> =20 =09 =20 T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Reinhard Clemens (Vorsitzender)*, Helmut = Binder, Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, = Wilfried Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG =20 Notice: This transmittal and/or attachments may be privileged or = confidential. If you are not the intended recipient, you are hereby = notified that you have received this transmittal in error; any review, = dissemination, or copying is strictly prohibited. If you received this = transmittal in error, please notify us immediately by reply and = immediately delete this message and all its attachments. Thank you.=20 T-Systems - Business flexibility=20 =20 =09 =09 ________________________________ Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im = Auftrag von Wojciech Dec (wdec) Gesendet: Mittwoch, 23. April 2008 14:54 An: ancp@ietf.org Betreff: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal =20 Hi All,=20 Continuing with the series of e-mails regarding basic protocol = issues still to be addressed, I now would now like to ask your feedback = regarding the distinction the protocol places on mandatory TLVs. Given = the length of this mail I'll first cut to the proposal, and after it you = can find the problem description. The proposal which I am putting in front of the WG is to define a = new TLV format which contains at a minimum a Mandatory flag (much like = Radius VSAs do). We could have this TLV Flag be defined only for new = applications. A second proposal would be try to make this flag work with existing = ones by for example defining the highest order bit of the TLV# field to = mean "Mandatory" when set to "0". This would be invisible to exiting = implementations, but newer ones may have problems in communicating with = older ones when the latter do not send all TLVs. But that can also be = addressed by simply forming the set of mandatory TLVs to be the ones = that all implementations currently send by default. Without additional feedback, I will assume that the WG is fine with = the first proposal, and also with the 2nd one conditional on deriving a = suitable "commonly used" TLV set. The problem in more detail:=20 Currently the situation is that Mandatory TLVs are only stated to = be as such in the body of the protocol draft spec, with an implementer = having to scour fairly attentively the text. Eg "Type = (Access-Loop-Circuit-ID =3D 0x01): This is a mandatory TLV", etc. The behaviour of an implementation that receives a message with a = missing mandatory TLV is not defined at all, and the opposite is handled = but not very robustly, i.e. when receiving a TLV but not recognizing it, = and implementation is free to discard it (even if it is mandatory!). = This is a recipe for interoperability problems and an implementation = mine field. This problem is complicated by different applications. For example = the current OAM section states the following regarding TLVs that are to = be carried in the request message (my italics): "=20 Following TLVs can appear in this message:=20 o Type (Access-Loop-Circuit-ID =3D 0x01) : defined in = section 5.4.1 =20 o Type (Access-Aggregation-Circuit-ID-Binary =3D 0x06): = defined in=20 section 5.4.1.=20 =20 o Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03): = defined in section=20 5.4.1. =20 o Type (OAM-Loopback-Test-Parameters =3D 0x07): Parameters = related to =20 loopback test. This is an optional TLV. If this TLV is not = present=20 in the request message, the DSLAM SHOULD use locally = determined=20 default values for the test parameters. =20 "=20 (NOTE: The last "SHOULD" appears to be inappropriate. If the TLV is = missing, the DSLAM MUST have some default parameters, or return an = error) The "can" above indicates that they're all optional, while clearly = the application cannot run its course without one or more of these = fields. Here we have a case where one could have a perfectly compliant = implementation that ignores all these TLVs... -Woj.=20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 ------_=_NextPart_001_01C8AA23.DE24331A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns:v =3D "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word" xmlns:p =3D=20 "urn:schemas-microsoft-com:office:powerpoint"><HEAD><TITLE>Nachricht</TIT= LE> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2900.3314" name=3DGENERATOR><!--[if !mso]> <STYLE>v\:* { BEHAVIOR: url(#default#VML) } o\:* { BEHAVIOR: url(#default#VML) } w\:* { BEHAVIOR: url(#default#VML) } .shape { BEHAVIOR: url(#default#VML) } </STYLE> <![endif]--> <STYLE>@font-face { font-family: Tahoma; } @page Section1 {size: 595.3pt 841.9pt; margin: 70.85pt 70.85pt 2.0cm = 70.85pt; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline } A:visited { COLOR: purple; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline } P { FONT-SIZE: 12pt; MARGIN-LEFT: 0cm; MARGIN-RIGHT: 0cm; FONT-FAMILY: = "Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto } SPAN.E-MailFormatvorlage18 { COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply } DIV.Section1 { page: Section1 } </STYLE> </HEAD> <BODY lang=3DDE vLink=3Dpurple link=3Dblue> <DIV dir=3Dltr align=3Dleft><SPAN class=3D547254517-29042008><FONT = face=3DArial=20 size=3D2>Hi Peter,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D547254517-29042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D547254517-29042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Peter Arberg=20 [mailto:parberg@redback.com] <BR><B>Sent:</B> 29 April 2008=20 19:34<BR><B>To:</B> Wojciech Dec (wdec); DE CNODDER Stefaan; Busser, = M;=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> RE: Re: [ANCP]=20 Mandatory TLVs in draft-ietf-ancp-protocol = proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Hi Woj,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>I agree with Michael and Stefan on this = issue, I do not=20 see a need to change the existing</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>implementation with = a=20 mandatory/optional flag.<SPAN class=3D547254517-29042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D547254517-29042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008><FONT color=3D#000000>Woj> Please = indicate where in=20 my proposal did you see anything about</FONT> <FONT=20 color=3D#000000>changing existing implementaions?=20 </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>I think I understand your arguments, but I do = not agree=20 with them. I think most places in</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>the draft it is = clear what is=20 defined as mandatory and optional.<SPAN = class=3D547254517-29042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>I agree on the point we need to go through = the draft and=20 make clarifications to what TLV's</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>in what capability types are mandatory and = optional, and=20 make more description what should</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>happen if mandatory = TLVs are not=20 included.<SPAN class=3D547254517-29042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D547254517-29042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008><FONT color=3D#000000>Woj>=20 Exactly.</FONT> </SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>I think the DSLF TR-101 document has a good = example of=20 such a description in it's </FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 size=3D2><FONT color=3D#0000ff>"</FONT><FONT face=3DArial-BoldMT = size=3D2><FONT=20 color=3D#0000ff>Table 3 - Access loop characteristics sub-options<SPAN = class=3D058271017-29042008>", and I think if we do the same for=20 each</SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 size=3D2><FONT face=3DArial-BoldMT size=3D2><FONT = color=3D#0000ff><SPAN=20 class=3D058271017-29042008>capability types TLV's in the ANCP draft it = will be a=20 good help.</SPAN></FONT></DIV></FONT></FONT></SPAN> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT face=3DArial color=3D#0000ff = size=3D2><FONT=20 color=3D#000000>Woj></FONT> <FONT color=3D#000000>Indeed, = pre-ceeded by some=20 rationalization. The appears to be no reason for some of the DSLF = "mandatory"=20 TLVs.</FONT></FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>I do not agree with your point that it is not = listed if=20 "rate" is mandatory or optional, it is clearly</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>listed as a mandatory TLV, and as such it = should be=20 included in the port up message, I really</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>do not understand = what confusion=20 you have with this.<SPAN class=3D547254517-29042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D547254517-29042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008><FONT color=3D#000000>Woj> The text=20 = states:  </FONT> </SPAN></FONT></FONT></FONT></SPAN></DIV>= <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D547254517-29042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008><FONT size=3D1><FONT face=3D"Courier New" = color=3D#000000=20 size=3D2>5. Type (DSL Line Attributes =3D 0x04): </FONT></DIV> <P dir=3Dltr align=3Dleft><FONT face=3D"Courier New" color=3D#000000 = size=3D2>Length :=20 variable (up to 1024 bytes) </FONT></P> <P dir=3Dltr align=3Dleft><FONT face=3D"Courier New" color=3D#000000 = size=3D2>Value :=20 This consists of one or more Sub-TLVs corresponding to DSL </FONT></P> <P dir=3Dltr align=3Dleft><FONT face=3D"Courier New" color=3D#000000 = size=3D2>line=20 attributes. No sub-TLVs other than the "DSL type" and "DSL </FONT></P> <P dir=3Dltr align=3Dleft><FONT face=3D"Courier New" color=3D#000000 = size=3D2>line=20 state" SHOULD be included in a PORT DOWN message. </FONT></P> <P dir=3Dltr align=3Dleft><FONT face=3D"Courier New" color=3D#000000 = size=3D2>The=20 general format of the sub-TLVs is identical to the general TLV = </FONT></P> <P dir=3Dltr align=3Dleft><FONT face=3D"Courier New" color=3D#000000 = size=3D2>format.=20 The value field in each sub-TLV is padded to a 4-octet </FONT></P> <P dir=3Dltr align=3Dleft><FONT face=3D"Courier New" color=3D#000000 = size=3D2>alignment.=20 The Length field in each sub-TLV contains the actual </FONT></P> <P dir=3Dltr align=3Dleft><FONT face=3D"Courier New" color=3D#000000 = size=3D2>number of=20 bytes in the TLV (not including the padding if present). </FONT></P> <P dir=3Dltr align=3Dleft><FONT color=3D#000000><FONT face=3D"Courier = New"=20 size=3D2>Current defined sub-TLV types are start from = 0x81.</FONT> <SPAN=20 class=3D547254517-29042008><FONT face=3DArial=20 size=3D2> </FONT></SPAN></FONT></P> <P dir=3Dltr align=3Dleft><FONT color=3D#000000><SPAN = class=3D547254517-29042008><FONT=20 face=3DArial size=3D2>Maybe you can point me to where exatly it is = stated clearly=20 as being mandatory, or otherwise explain why you "not=20 = agree"?</FONT> </SPAN></FONT></P></FONT></SPAN></FONT></FONT></FONT>= </SPAN> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>The fact you say "Port UP" and "OAM" is best = considered=20 as legacy applications, I have some</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>trouble with this as well, since ANCP running = in=20 production networks use them, and as such</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>it is a central part = of the ANCP=20 specifications we need to finish as soon as possible.<SPAN=20 class=3D547254517-29042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D547254517-29042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008><FONT color=3D#000000>Woj> I should have = said legacy=20 applications from a protocol messaging perspective, not usage, nor = support.=20 It's quite clear that GSMP derived messaging has baggage that is un = called for=20 in new applications.</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>I think Stefaan's example is very valid, that = we do not=20 need to make mandatory requirements to </FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>what receivers of ANCP information use such = info.=20 for.  I don't think we should try and make = the</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>ANCP specifications "mandatory" for box = behavior, I think=20 it is much more important for the </FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>working group to make the protocol = specifications easy to=20 understand and get the first documentation</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>finish and published, so the protocol can be = used for=20 different sets of applications, and make sure</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>new applications can = be added=20 later.<SPAN class=3D547254517-29042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D547254517-29042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008><FONT color=3D#000000>Woj> Indeed the = aim of the WG=20 to define a protocol that is relatively simple and easy to understand, = not=20 just to implementers but also to people using it, and across vendors.=20 Currently, having anyone operating the device be familiar in what = cases a TLV=20 is mandatory and in what optional requires a thorough understanding of = the=20 spec, across applications. This is not easy, but I'll conceede that = for the=20 applications implemented so far we could live with it.=20 </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>I do think that by documenting if a TLV is = mandatory or=20 optional inside a specific capability type,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>it is easy to = understand what must=20 be sent to support the defined application/capability type.<SPAN=20 class=3D547254517-29042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D547254517-29042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008><FONT color=3D#000000>Woj> Of course it = is, the=20 whole spec is about this. The problem comes when people start to=20 re-use well known TLVs for different applications, and then = trying to=20 make sense of it all becomes non-trivial. Why do you think both BGP = and=20 Diamater, and a number of other protocols have definied "Mandatory" = flags?=20 Just for kicks? It's a well known protocol design tool, that comes = handy when=20 re-using same data across multiple=20 applications.</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Then if anybody want to include new = capability types or=20 sub-TLVs later to address specific applications,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>then I think changes can be discussed at that = time=20 instead of trying to change existing protocol</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT = size=3D2>implementations.<SPAN=20 class=3D547254517-29042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D547254517-29042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008><FONT color=3D#000000>Woj> Again I ask, = where in the=20 proposal did you see *anything* requiring a change to an existing = implementation. Please be specific.</FONT> <FONT = color=3D#000000>I see that=20 your main objection is on this issue, which means that you accept = proposal 1=20 (have such a flag for new=20 TLVs/apps).</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D058271017-29042008><FONT><FONT=20 face=3DArial><FONT size=3D2><SPAN class=3D547254517-29042008>It would = also be useful=20 if you indicated whether the list of TLVs provided below is what you'd = expect=20 to be the minimum mandatory = set.</SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D058271017-29042008><FONT><FONT=20 face=3DArial><FONT size=3D2><SPAN=20 = class=3D547254517-29042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN = class=3D058271017-29042008><FONT><FONT=20 face=3DArial><FONT size=3D2><SPAN=20 = class=3D547254517-29042008>Cheers,</SPAN></FONT></FONT></FONT></SPAN></DI= V> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D058271017-29042008><FONT><FONT=20 face=3DArial><FONT size=3D2><SPAN=20 = class=3D547254517-29042008>Woj.</SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>cheers,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Peter</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>Wojciech Dec=20 (wdec)<BR><B>Sent:</B> 29. april 2008 02:28<BR><B>To:</B> DE CNODDER = Stefaan; Busser, M; ancp@ietf.org<BR><B>Cc:</B> Haag, = T<BR><B>Subject:</B>=20 Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol=20 proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>Stefaan,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>a number of points:</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>1. There currently is to my knowledge no = implementation of ANCP=20 there that doesn't send the DSL Line attributes info by default in = Port-UP=20 messages? The support of HS on the NAS is an orthogonal=20 issue.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>2. T</FONT></SPAN><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>he current ancp protocol draft (02) doesn't say whether the = rate info=20 is optional or mandatory, it only states that the sub-TLVs are = mandatory.=20 Based on this, an implementer can be justified to expect = port-ups to=20 *always* have the rate-info tlv (ie treat them as mandatory). = Equally, she's=20 justified in considering this  as = optional.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><SPAN=20 class=3D342501308-29042008><FONT face=3DArial = size=3D2>3.<EM> </EM><SPAN=20 class=3D342501308-29042008><FONT face=3DArial size=3D2>The port-up = and OAM=20 are best considered as legacy applications for ANCP. The re-use = of any=20 of the GSMP defined fields is already out of the question due to = constrains=20 put in place by the existing use-case messaging. Needless to say, = this=20 wasn't as thoroughly designed as it should have been, and with the = OAM and=20 port-up apps being coupled.</FONT></SPAN></FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>4. It's up to the application to define what TLVs are = mandatory and=20 which aren't, as you also state. The AN does not need to know = what the=20 NAS will do with the info, BUT it needs to send the right TLVs for = the=20 application (eg if we had a hypothetical AN that only sends = Port-up's=20 with line-id, it would be next to useless for the dynamic shaping=20 application).</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>With all this in mind it's useful to re-read what I = proposed=20 originally below regarding the mandatory flag: 1. "<EM>have = this TLV=20 Flag be defined only for new applications" </EM>and 2. The notion of = the=20 mandatory flag applying to existing TLVs  being = "<EM>conditional on=20 deriving a suitable "commonly used" TLV set." </EM>The latter point = would=20 ensure that existing implementations do not need to change, but = future ones=20 can take advantage of the extra robustness.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2><SPAN class=3D342501308-29042008></SPAN></FONT></SPAN><SPAN = class=3D342501308-29042008><FONT face=3DArial=20 size=3D2><EM></EM></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>Hence, can the WG derive a set of commonly used, i.e. = always used,=20 TLVs for existing implementations?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>The list I came up is as follows (making them pretty much = mandatory=20 TLVs if it agrees with the views of others);</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>Port-up message (0x80);</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>    Extension-TLV (dsl tech = type)</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>    Access-Loop-circuit-id = (0x01)</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>    DSL Line Attribute (0x04) with the = following sub=20 TLVs;</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008> <FONT=20 size=3D2>       DSL-Type =3D 0x91;=20 Actual-Net-Data-Upstream =3D 0x81<SPAN class=3D342501308-29042008>;=20 Actual-Net-Data-Rate-Downstream =3D 0x82</SPAN></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>Port-down message (0x81);</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008>   =20 <FONT face=3DArial size=3D2>Extension  TLV (dsl tech=20 type)</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008>   =20 <FONT face=3DArial size=3D2>Access-Loop-circuit-id = (0x01)</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008>   =20 <FONT face=3DArial size=3D2>DSL Line Attribute (0x04) with the = following sub=20 TLVs;</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN=20 = class=3D342501308-29042008>       <FON= T=20 size=3D2> DSL line state =3D 0x8F</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>All other TLVs are optional.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>Would appreciate confirmation from the WG regarding the=20 above.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>Thanks,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2>Woj.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 = 2px solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> DE CNODDER Stefaan=20 [mailto:stefaan.de_cnodder@alcatel-lucent.be] <BR><B>Sent:</B> 29 = April=20 2008 09:52<BR><B>To:</B> Wojciech Dec (wdec); Busser, M;=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> RE: [ANCP]=20 Mandatory TLVs in draft-ietf-ancp-protocol = proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Hi Woj,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Take the following example: I have a = network with 2=20 NASses, NAS-A is doing hierarchical shaping, NAS-B just wants to = have the=20 port information but is not doing hierarchical shaping (it is = doing other=20 things like OAM, ...).  This means NAS-A needs the bandwidth, = while=20 NAS-B does not need the bandwidth.  How should the flag be = set in=20 this case by the AN?  Set to 'Mandatory' for the port up = messages to=20 NAS-A, and set to 'Optional' for port up messages towards NAS-B? = Or is it=20 always set to 'Mandatory'?  From your answer below, I = understand that=20 it should be set to 'Optional' towards NAS-B.  Is that=20 correct?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>NAS-B will simply ignore the bandwidth = TLV.  If=20 such a flag would exist, and the flag is set to 'Mandatory' by the = AN to=20 NAS-B, what should be the behavior of NAS-B?  Should it = reject the=20 whole message?  Maybe NAS-B is not supporting hierarchical = shaping,=20 so it might not support the bandwidth TLV.  Today, the = bandwidht TLV=20 is only mandatory to be put in the port up messages, but for the = receiver=20 there is nothing mandatory.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>I believe the original intend of ANCP was = that the AN=20 does not need to know what the NAS is doing with this information, = the use=20 of the bandwidth is also not specified by ANCP, only an example is = given=20 (which is shaping).  In the future there may be applications = for=20 which TLVs will be mandatory which are now = optional.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Stefaan</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV><BR> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com] <BR><B>Sent:</B> maandag 28 april 2008=20 21:33<BR><B>To:</B> DE CNODDER Stefaan; Busser, M;=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> RE: [ANCP]=20 Mandatory TLVs in draft-ietf-ancp-protocol = proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial = size=3D2></FONT> </DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 = 2px solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> DE CNODDER Stefaan=20 [mailto:stefaan.de_cnodder@alcatel-lucent.be] <BR><B>Sent:</B> = 28 April=20 2008 17:15<BR><B>To:</B> Wojciech Dec (wdec); Busser, M;=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> RE: = [ANCP]=20 Mandatory TLVs in draft-ietf-ancp-protocol = proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>Take the = bandwidth sub-TLV=20 in port up messages as example.  The current protocol spec = says=20 that it is mandatory to be sent in port up messages.  = that's=20 ok.  But it is not mandatory for the receiver to process = the=20 bandwidth sub-TLV.  What is done with this information by = the NAS=20 is not specified by ANCP, so you cannot make it mandatory for = the=20 receiver side.<SPAN class=3D163161615-28042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D163161615-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008><FONT color=3D#000000>Woj> Is the = information=20 required by the application? It would appear for the dynamic = shaping=20 use-case to be most certainly so. Hence it is absolutely = mandatory,=20 otherwise the message makes no sense for the=20 application.</FONT> <FONT color=3D#000000>In any case, if=20 </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>So it looks to = me that the=20 flag can only indicate what the receiver should do.  Then = the flag=20 makes sense.<SPAN class=3D163161615-28042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D163161615-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008><FONT color=3D#000000>Woj> = </FONT> <FONT=20 color=3D#000000>The flag tells the receiver what info the sender = thinks is=20 required to carry out the application. This in almost all cases = has to=20 match up to what the receiver thinks is required. The=20 sender </FONT></SPAN></FONT></FONT></FONT></SPAN><SPAN=20 class=3D436050615-28042008><FONT color=3D#0000ff><FONT = face=3DArial><FONT=20 size=3D2><SPAN class=3D163161615-28042008><FONT = color=3D#000000>doesn't tell=20 the receiver what to do with the=20 info.</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>If the = receiver knows what=20 is mandatory, then I do not see a reason why this has to be made = explicit in the protocol.  It would only complicate the=20 protocol.  As already said by Michael: if a mandatory TLV = is not=20 there, then it is just a bug.<SPAN = class=3D163161615-28042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D163161615-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008><FONT color=3D#000000>Woj> Can you = specifically describe what aspect of the protocol does it=20 complicate?</FONT> <FONT color=3D#000000>It's just making = explicitly=20 clear what the protocol already has to implement anyway to be of = any=20 use.</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 size=3D+0><FONT face=3DArial><FONT size=3D2><SPAN = class=3D163161615-28042008>As=20 to whether it is a bug, having such explicit marking makes it = clear=20 what/where the problem is when observing a messaging = flow vs a lot=20 of deduction work. In any case, the other point being made = here is=20 that today the protocol does NOT specify what should happen if a = mandatory TLV is = missing.</SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 size=3D+0><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D163161615-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 size=3D+0><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D163161615-28042008>-Woj.</SPAN></FONT></FONT></FONT></SPAN></DIV>= <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT face=3DArial=20 color=3D#0000ff size=3D2>regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT face=3DArial=20 color=3D#0000ff size=3D2>Stefaan</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV><BR> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com] <BR><B>Sent:</B> maandag 28 april 2008=20 16:28<BR><B>To:</B> DE CNODDER Stefaan; Busser, M;=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> RE: = [ANCP]=20 Mandatory TLVs in draft-ietf-ancp-protocol = proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D560491614-28042008><FONT face=3DArial=20 size=3D2>It's actually a mix of both. = Inline...</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: = #000000 2px solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> = ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>DE CNODDER=20 Stefaan<BR><B>Sent:</B> 28 April 2008 16:04<BR><B>To:</B> = Wojciech Dec=20 (wdec); Busser, M; ancp@ietf.org<BR><B>Cc:</B> Haag,=20 T<BR><B>Subject:</B> Re: [ANCP] Mandatory TLVs in=20 draft-ietf-ancp-protocol proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff = size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 face=3DArial color=3D#0000ff size=3D2>Hi,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 face=3DArial color=3D#0000ff size=3D2>This new mandatory flag, = what is=20 exactly its meaning?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>(1) if = flag set to=20 "mandatory", then the *receiver* of this TLV MUST process it, = and if=20 unrecognized must drop the message<SPAN = class=3D560491614-28042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>If a received = TLV is has=20 the "mandatory" flag set then the receiver MUST drop = the=20 message and report an error to the sender if it doesn't = recognize=20 the TLV.</FONT> </SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>If a the = receiver expects=20 a "mandatory" TLV but doesn't receive it, the = message MUST=20 be droped and an error report sent to=20 = the sender.</FONT> </SPAN></FONT></FONT></FONT></SPAN></SPAN></= FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 face=3DArial color=3D#0000ff size=3D2>OR</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>(2) if = flag is set=20 to"mandatory", then the *sender* MUST include it in the = message for=20 which it is defined<SPAN class=3D560491614-28042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>The sender = MUST include=20 mandatory TLVs as defined by the=20 = protocol-spec/applications.</FONT></SPAN></FONT></FONT></FONT></SPAN></DI= V> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 face=3DArial color=3D#0000ff size=3D2>The current protocols = draft says for=20 certain TLVs that they are mandatory, but that applies to the = sender=20 of it (interpretation 2).  The flag would indicate = interpretation=20 1 (like for Radius VSAs?)?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>If the = higher order bit is=20 set to "0" means that it is mandatory, then currently defined = optional=20 defined TLVs suddenly become mandatory which is not good.<SPAN = class=3D560491614-28042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>Woj> Only = the=20 currently used TLVs become mandatory. If they are not=20 used/implemented we can re-define them as optional (set flag = to 1) at=20 no cost. </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>But I would = first to=20 understand the exact meaning of this mandatory flag.  = Defining=20 such a flag indeed looks useful but then as interpretation 1, = and I=20 would say that if flag set to 1, then it is mandatory and = actually, it=20 is possible that a TLV is sent sometimes as optional and = sometimes as=20 mandatory.<SPAN class=3D560491614-28042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>Woj> = Precisely, that=20 is possible on a per application basis.</FONT> <FONT=20 color=3D#000000>Having the flag would make troubleshooting of = a message=20 flow much more explicit (today, with any problem one = has to=20 browse the drafts to figure out what MUST be there vs what = SHOULD be=20 there all while looking what is actually=20 there)</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 = size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 = size=3D2><SPAN=20 = class=3D560491614-28042008>Regards,</SPAN></FONT></FONT></FONT></SPAN></D= IV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 = size=3D2><SPAN=20 = class=3D560491614-28042008>Woj.</SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 = size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2>regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2>Stefaan</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff = size=3D2></FONT> </DIV><BR> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> = ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>Wojciech = Dec=20 (wdec)<BR><B>Sent:</B> donderdag 24 april 2008 = 14:19<BR><B>To:</B>=20 Busser, M; ancp@ietf.org<BR><B>Cc:</B> Haag, = T<BR><B>Subject:</B> Re:=20 [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol=20 proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D709295811-24042008><FONT=20 face=3DArial size=3D2>Hi Michael,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D709295811-24042008><FONT=20 face=3DArial size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D709295811-24042008><FONT=20 face=3DArial size=3D2>inline...</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: = #000000 2px solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> = ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>Busser,=20 M<BR><B>Sent:</B> 24 April 2008 13:13<BR><B>To:</B>=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> Re: = [ANCP]=20 Mandatory TLVs in draft-ietf-ancp-protocol=20 proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Hi Woi,=20 all</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>I see=20 the problem but i can not see, how an additional flag will = help=20 solving this problem.</FONT></SPAN></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Lets=20 assume your first proposal.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT = face=3DArial><FONT=20 size=3D2>If an implementation does not send the=20 complete TLV, even it is defined to=20 be mandatory, I would call this a bug and I = can not=20 see, how an additional flag can help here.<SPAN=20 = class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT = face=3DArial><FONT=20 size=3D2><SPAN=20 = class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT = face=3DArial><FONT=20 size=3D2><SPAN class=3D709295811-24042008>Woj> The way it = helps, and=20 other protocols bear proof of this scheme, is that it is = easier for=20 implementations to reconcile errors resulting out of = "Mandatory" and=20 "Optional" TLV sets. The key to this lies on a per = application=20 basis. One application may mandate TLV A for operation, = while=20 another might not. Resolving such issues when implementing = or=20 troubleshooting multiple applications is not always trivial. = </SPAN></FONT></FONT></SPAN><SPAN = class=3D364043506-24042008><FONT=20 face=3DArial><FONT size=3D2><SPAN=20 = class=3D709295811-24042008></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT = face=3DArial><FONT=20 size=3D2><SPAN=20 = class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Your=20 second proposal seems obviously be required to keep = existing=20 things working, if we agree on your first = proposal.=20 </FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>But from=20 my point of view it also assumes, that all existing=20 implementations are using the same set of TLVs now.=20 </FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT = face=3DArial><FONT=20 size=3D2>And I am not sure about that. <SPAN=20 = class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT = face=3DArial><FONT=20 size=3D2><SPAN=20 = class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT = face=3DArial><FONT=20 size=3D2><SPAN class=3D709295811-24042008>Woj> This would = be a good=20 thing for the WG to discuss. There most evidently is a fair = amount=20 of "dead wood" in the current spec, ie stuff that = nobody=20 yet implements or cares about.  In the former = case, we=20 could re-cast that material using the new = notions/extensions, in the=20 latter case simply chop it = out.</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2><SPAN=20 class=3D364043506-24042008><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV></FONT></SPAN> <DIV><SPAN class=3D364043506-24042008><FONT = face=3DArial><FONT=20 size=3D2>Therefore I disagree with your first proposal. I = recommend,=20 the better way will be to be more precise in = definitions.<SPAN=20 = class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>In my=20 mind, it is a bug, if a mandatory TLV is missing. It is up = to the=20 robustness of the implementation to deal with this=20 situation.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT = face=3DArial><FONT size=3D2>Is=20 it really neccesary to define the behavior of a network = element in=20 this case of failure in the ancp protocol itself? <SPAN = = class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT = face=3DArial><FONT=20 size=3D2><SPAN=20 = class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT = face=3DArial><FONT=20 size=3D2><SPAN class=3D709295811-24042008>Woj> Other = people have=20 faced this problem before, and I would rather go with the = lessons=20 they learned, rather than clinging to hopes of perfect = textual=20 definitions and implementations. Other than backwards = compatibility,=20 I do not see in your statements a valid reason to = object to the=20 1st proposal, particularly for new applications since = it can=20 only make things more robust. The counter argument of being = precise=20 in the definitions, as evidenced by the current spec, is = admirable=20 and needs to be there, with this proposal providing an extra = level=20 of robustness and visibility of any problems.=20 </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT = face=3DArial><FONT=20 size=3D2><SPAN=20 = class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT = face=3DArial><FONT=20 size=3D2><SPAN=20 = class=3D709295811-24042008>Thanks,</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT = face=3DArial><FONT=20 size=3D2><SPAN=20 = class=3D709295811-24042008>Woj.</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>If=20 optional TLVs are not present in a message, we should = describe some=20 kind of default behaviour, as you already=20 stated.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Comments=20 on=20 = draft-ietf-ancp-protocol-02.txt:</FONT></SPAN></DIV></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT = face=3DArial>It=20 is not clearly stated, if the TLV  "<SPAN = lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA">DSL=20 Line Attributes "<FONT face=3DArial> is mandatory or = optional.=20 </FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT=20 face=3DArial><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>In fact it is mandatory because some of its = SubTLVs are=20 mandatory. </FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT=20 face=3DArial><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>We should spent a sentence to make this=20 clear.</FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2><SPAN=20 class=3D364043506-24042008><FONT size=3D2><FONT = face=3DArial>It is not=20 clearly stated, if the TLV  "<SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: = AR-SA">Service-Profile-Name"<FONT=20 face=3DArial> is mandatory or=20 = optional.</FONT></SPAN></FONT></FONT></SPAN></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2><SPAN=20 class=3D364043506-24042008><FONT size=3D2><FONT = face=3DArial><SPAN=20 lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; = mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; = mso-fareast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>I prefer mandatory because it is essetial for = the use=20 case Line=20 = Config. </FONT></SPAN></FONT></FONT></SPAN></DIV></FONT></SPAN><SPAN= =20 class=3D364043506-24042008><FONT face=3DArial = size=3D2></FONT></SPAN> <DIV><SPAN class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Section=20 5.4.3 Line Config, where the TLVs are mentioned (page=20 35):</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2> =20 ...defined in section 5.4.1....    must be = corrected=20 to    ...defined in section=20 5.4.2........</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Section=20 5.4.4 OAM, where the TLVs are mentioned (page 36 and = page=20 38):</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2> =20 ...defined in section 5.4.1....    must be = corrected=20 to    ...defined in section=20 5.4.2........</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV></FONT></SPAN><SPAN class=3D364043506-24042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV></DIV> <DIV><SPAN class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN = class=3D364043506-24042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV align=3Dleft><FONT color=3D#000080 size=3D2> <P align=3Dleft>Best Regards; Freundliche Gr=FC=DFe = </P></FONT><B><FONT=20 color=3D#000080> <P>Michael Busser</P></B></FONT><FONT size=3D1> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: = 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt">T-Systems Enterprise Services GmbH=20 </SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: = 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN = style=3D"FONT-SIZE: 8pt"><FONT=20 size=3D1>Production Line Network Centric = Systems</FONT></SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: = 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN = style=3D"FONT-SIZE: 8pt"><FONT=20 size=3D1>ICT-Systems Integration</FONT></SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: = 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN = style=3D"FONT-SIZE: 8pt"><FONT=20 size=3D1>Network Integration Services</FONT></SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: = 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN = style=3D"FONT-SIZE: 8pt"><FONT=20 size=3D1></FONT><SPAN style=3D"COLOR: navy"></SPAN><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy"><FONT face=3DArial = color=3D#000000=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: = 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN = style=3D"FONT-SIZE: 8pt"><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy"><FONT color=3D#000000 = size=3D1>Br=FCckes 2 -8, 55545 Bad Kreuznach<BR>Postfach = 9100, 55541 Bad=20 Kreuznach<BR>+49 671 8333 8911 (Phone)<BR>+49=20 521 9210 3859 (Fax)<BR>+49 151 1211 9689=20 (Mobile)<BR>E-Mail: <A=20 = href=3D"mailto:michael.busser@t-systems.com">michael.busser@t-systems.com= </A></FONT></SPAN></DIV></SPAN> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: = 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: = 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN></DIV><SPAN=20 style=3D"FONT-SIZE: 8pt">Internet: </SPAN><SPAN=20 style=3D"FONT-SIZE: 8pt"><p:onmouseclick=20 href=3D"http://www.t-systems.com/"=20 hyperlinktype=3D"url"></p:onmouseclick><A=20 onclick=3Dwindow.event.cancelBubble=3Dtrue;=20 href=3D"http://www.t-systems.com/" target=3D_parent><FONT=20 = color=3D#6699ff>http://www.t-systems.com</FONT></A></SPAN><SPAN=20 style=3D"FONT-SIZE: 8pt"> </SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '90 0 50'; mso-margin-left-alt: = 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '90 0 50'; mso-margin-left-alt: = 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN> </DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '90 0 50'; mso-margin-left-alt: = 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN = style=3D"FONT-SIZE: 8pt"><FONT=20 size=3D3><FONT size=3D1><SPAN=20 style=3D"FONT-SIZE: 7.5pt; COLOR: black; FONT-FAMILY: = Arial">T-Systems=20 Enterprise Services GmbH<BR>Aufsichtsrat: Ren=E9 Obermann=20 (Vorsitzender)<BR>Executive Committee: Reinhard Clemens=20 (Vorsitzender)*, Helmut Binder, Albert Henn, Olaf Heyden*, = Katrin=20 Horstmann, Ulrich Kemp, Wilfried Peters*,<BR>Dr. Herbert = Schaaff*,=20 Zvezdana Seeger*<BR>Handelsregister: Amtsgericht Frankfurt = am Main=20 HRB 55933<BR>Sitz der Gesellschaft: Frankfurt am=20 Main<BR>WEEE-Reg.-Nr. DE87523644<BR>*Gesch=E4ftsf=FChrer = gem. =A7 35=20 GmbHG</SPAN></FONT></FONT></SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '90 0 50'; mso-margin-left-alt: = 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN = style=3D"FONT-SIZE: 8pt"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT face=3DArial=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '90 0 50'; mso-margin-left-alt: = 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN = style=3D"FONT-SIZE: 8pt"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT size=3D1>Notice: This = transmittal and/or=20 attachments may be privileged or confidential. If you are = not the=20 intended recipient, you are hereby notified that you have = received=20 this transmittal in error; any review, dissemination, or = copying is=20 strictly prohibited. If you received this transmittal in = error,=20 please notify us immediately by reply and immediately delete = this=20 message and all its attachments. Thank you. </FONT><FONT=20 size=3D1><BR>T-Systems =96 Business flexibility=20 </FONT></DIV></SPAN></SPAN> <DIV><FONT face=3DArial = size=3D2></FONT> </DIV></FONT></DIV> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"> <DIV></DIV> <DIV class=3DOutlookMessageHeader lang=3Dde dir=3Dltr = align=3Dleft> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy = size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: = Arial"><o:p></o:p></SPAN></FONT></P><FONT=20 face=3D"Times New Roman" size=3D3><SPAN = style=3D"FONT-SIZE: 12pt"><FONT=20 face=3DArial size=3D2></FONT> <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2> </SPAN></FONT></DIV> <DIV class=3DSection1> <DIV> <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN = style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: = Tahoma">Von:</SPAN></FONT></B><FONT=20 face=3DTahoma size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">=20 ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] = <B><SPAN=20 style=3D"FONT-WEIGHT: bold">Im Auftrag von = </SPAN></B>Wojciech Dec=20 (wdec)<BR><B><SPAN style=3D"FONT-WEIGHT: = bold">Gesendet:</SPAN></B>=20 Mittwoch, 23. April 2008 14:54<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">An:</SPAN></B> = ancp@ietf.org<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Betreff:</SPAN></B> [ANCP] = Mandatory=20 TLVs in draft-ietf-ancp-protocol=20 proposal</SPAN></FONT><o:p></o:p></P></DIV> <P class=3DMsoNormal><FONT face=3D"Times New Roman" = size=3D3><SPAN=20 style=3D"FONT-SIZE: = 12pt"><o:p> </o:p></SPAN></FONT></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi=20 All,</SPAN></FONT><SPAN lang=3DEN-GB> = </SPAN><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Continuing = with the=20 series of e-mails regarding basic protocol issues still to = be=20 addressed, I now would now like to ask your feedback = regarding the=20 distinction the protocol places on mandatory TLVs. Given = the=20 length of this mail I'll first cut to the proposal, and = after it=20 you can find the problem = description.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The proposal = which I=20 am putting in front of the WG is to define a new TLV = format which=20 contains at a minimum a Mandatory flag (much like Radius = VSAs do).=20 We could have this TLV Flag be defined only for new=20 applications.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">A second = proposal=20 would be try to make this flag work with existing ones by = for=20 example defining the highest order bit of the TLV# field = to mean=20 "Mandatory" when set to "0". This would be invisible to = exiting=20 implementations, but newer ones may have problems in = communicating=20 with older ones when the latter do not send all TLVs. But = that can=20 also be addressed by simply forming the set of mandatory = TLVs to=20 be the ones that all implementations currently send by=20 default.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Without = additional=20 feedback, I will assume that the WG is fine with the first = proposal, and also with the 2nd one conditional on = deriving a=20 suitable "commonly used" TLV = set.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The problem = in more=20 detail: </SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Currently = the=20 situation is that Mandatory TLVs are only stated to be as = such in=20 the body of the protocol draft spec, with an implementer = having to=20 scour fairly attentively the text. Eg "Type=20 (Access-Loop-Circuit-ID =3D 0x01): This is a mandatory = TLV",=20 etc.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The = behaviour of an=20 implementation that receives a message with a missing = mandatory=20 TLV is not defined at all, and the opposite is handled but = not=20 very robustly, i.e. when receiving a TLV but not = recognizing it,=20 and implementation is free to discard it (even if it is=20 mandatory!). This is a recipe for interoperability = problems and an=20 implementation mine field.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">This problem = is=20 complicated by different applications. For example the = current OAM=20 section states the following regarding TLVs that are to be = carried=20 in the request message (my = italics):</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial">"</SPAN></FONT>=20 <BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = 'Courier New'">Following=20 TLVs<B><I><SPAN style=3D"FONT-WEIGHT: bold; FONT-STYLE: = italic">=20 can</SPAN></I></B> appear in this message:=20 </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = 'Courier New'">      =20 o Type (Access-Loop-Circuit-ID =3D 0x01) : defined in = section=20 5.4.1    </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = 'Courier New'">      =20 o Type (Access-Aggregation-Circuit-ID-Binary =3D 0x06): = defined in=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = 'Courier New'">        =20 section 5.4.1. </SPAN></FONT><BR><FONT face=3D"Courier = New"=20 color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = 'Courier New'"> </SPAN></FONT>=20 <BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = 'Courier New'">      =20 o Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03): = defined in=20 section </SPAN></FONT><BR><FONT face=3D"Courier New" = color=3Dblack=20 size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = 'Courier New'">        =20 5.4.1.  </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = 'Courier New'">      =20 o Type (OAM-Loopback-Test-Parameters =3D 0x07): Parameters = related=20 to  </SPAN></FONT><BR><FONT face=3D"Courier New" = color=3Dblack=20 size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = 'Courier New'">        =20 loopback test. This is an optional TLV. If this TLV is not = present=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = 'Courier New'">        =20 in the request message, the DSLAM SHOULD use locally = determined=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = 'Courier New'">        =20 default values for the test parameters. =20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = 'Courier New'">"</SPAN></FONT>=20 <BR><FONT face=3DArial color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = Arial">(NOTE:=20 The last "SHOULD" appears to be inappropriate. If the TLV = is=20 missing, the DSLAM MUST have some default parameters, or = return an=20 error)</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = Arial">The=20 "can" above indicates that they're all optional, while = clearly the=20 application cannot run its course without one or more of = these=20 fields. Here we have a case where one could have a = perfectly=20 compliant implementation that ignores all these=20 TLVs=85</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = Arial">-Woj.</SPAN></FONT><SPAN=20 lang=3DEN-US> </SPAN><o:p></o:p></P> <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><FONT=20 face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: = 12pt"><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><o:p></o:p></SPAN></FONT></= P></DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE>= </BLOCKQUOTE></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C8AA23.DE24331A-- --===============1445035759== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============1445035759==-- From ancp-bounces@ietf.org Tue Apr 29 11:38:46 2008 Return-Path: <ancp-bounces@ietf.org> X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1680028C20D; Tue, 29 Apr 2008 11:38:46 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DE173A6C61 for <ancp@core3.amsl.com>; Tue, 29 Apr 2008 11:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1GY-emIFnaa for <ancp@core3.amsl.com>; Tue, 29 Apr 2008 11:38:36 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 03A4E28C20E for <ancp@ietf.org>; Tue, 29 Apr 2008 11:38:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 3885A360943; Tue, 29 Apr 2008 11:38:39 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03046-10; Tue, 29 Apr 2008 11:38:38 -0700 (PDT) Received: from rbsjx.ad.redback.com (rbsjxh2.redback.com [155.53.14.106]) by prattle.redback.com (Postfix) with ESMTP id E53B1360942; Tue, 29 Apr 2008 11:38:38 -0700 (PDT) Received: from RBSJX.ad.redback.com ([155.53.14.103]) by rbsjxh2.ad.redback.com ([155.53.14.106]) with mapi; Tue, 29 Apr 2008 11:38:38 -0700 From: Peter Arberg <parberg@redback.com> To: "Wojciech Dec (wdec)" <wdec@cisco.com>, DE CNODDER Stefaan <stefaan.de_cnodder@alcatel-lucent.be>, "Busser, M" <Michael.Busser@t-systems.com>, "ancp@ietf.org" <ancp@ietf.org> Date: Tue, 29 Apr 2008 11:38:36 -0700 Thread-Topic: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal Thread-Index: AcilQRMfK4kdawUKQOWs5fdBngS8QQAAr04QACRhApAAC0ujAADNHRywAADiEXAAAbhxoAAAWwcQACIOoKAAAXsqYAASvbCgAAE4sjAAASS6UA== Message-ID: <48C276B536524E478C659685995F6AA539DBB4F25F@RBSJX.ad.redback.com> References: <1B6169C658325341A3B8066E23919E1C01230DC1@S4DE8PSAANK.mitte.t-com.de><1B6169C658325341A3B8066E23919E1CFBC5C4@S4DE8PSAANK.mitte.t-com.de><D9872168DBD43A41BD71FFC4713274D404FA6ACC@xmb-ams-33b.emea.cisco.com><7A6D4815C5E8F74988784FEBD50F2F1E01ABAA16@FRVELSMBS22.ad2.ad.alcatel.com><D9872168DBD43A41BD71FFC4713274D404FF10C1@xmb-ams-33b.emea.cisco.com><7A6D4815C5E8F74988784FEBD50F2F1E01ABAAA4@FRVELSMBS22.ad2.ad.alcatel.com><D9872168DBD43A41BD71FFC4713274D404FF1233@xmb-ams-33b.emea.cisco.com><7A6D4815C5E8F74988784FEBD50F2F1E01ABAC34@FRVELSMBS22.ad2.ad.alcatel.com> <D9872168DBD43A41BD71FFC4713274D404FF13AD@xmb-ams-33b.emea.cisco.com> <48C276B536524E478C659685995F6AA539DBB4F194@RBSJX.ad.redback.com> <D9872168DBD43A41BD71FFC4713274D404FF172D@xmb-ams-33b.emea.cisco.com> In-Reply-To: <D9872168DBD43A41BD71FFC4713274D404FF172D@xmb-ams-33b.emea.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at redback.com Cc: "Haag, T" <Thomas.Haag@t-systems.com> Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list <ancp.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/ancp> List-Post: <mailto:ancp@ietf.org> List-Help: <mailto:ancp-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1047510450==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org --===============1047510450== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_48C276B536524E478C659685995F6AA539DBB4F25FRBSJXadredbac_" --_000_48C276B536524E478C659685995F6AA539DBB4F25FRBSJXadredbac_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Woj, please see inline in your answers ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] Sent: 29. april 2008 11:07 To: Peter Arberg; DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal Hi Peter, ________________________________ From: Peter Arberg [mailto:parberg@redback.com] Sent: 29 April 2008 19:34 To: Wojciech Dec (wdec); DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal Hi Woj, I agree with Michael and Stefan on this issue, I do not see a need to chang= e the existing implementation with a mandatory/optional flag. Woj> Please indicate where in my proposal did you see anything about changi= ng existing implementaions? PAR> I might have misunderstood your email, but I read it as if you sugges= t a high bit value in existing TLV's to be interpreted as a mandatory flag. If you are simply talking about new capability type definitions, then why d= o you not bring up the additional flag in a new internet-draft defining what capability type y= ou have in mind ? I think I understand your arguments, but I do not agree with them. I think = most places in the draft it is clear what is defined as mandatory and optional. I agree on the point we need to go through the draft and make clarification= s to what TLV's in what capability types are mandatory and optional, and make more descript= ion what should happen if mandatory TLVs are not included. Woj> Exactly. I think the DSLF TR-101 document has a good example of such a description i= n it's "Table 3 - Access loop characteristics sub-options", and I think if we do t= he same for each capability types TLV's in the ANCP draft it will be a good help. Woj> Indeed, pre-ceeded by some rationalization. The appears to be no reaso= n for some of the DSLF "mandatory" TLVs. PAR> I do not see a problem with re-visit in the draft if a TLV should be o= ptional or mandatory, so if that is the intend, then I'm all for an email discussion on a TLV by TLV ba= sis if we think it is a manfdatory or optional information inside the specific capability type. I do not agree with your point that it is not listed if "rate" is mandatory= or optional, it is clearly listed as a mandatory TLV, and as such it should be included in the port up= message, I really do not understand what confusion you have with this. Woj> The text states: 5. Type (DSL Line Attributes =3D 0x04): Length : variable (up to 1024 bytes) Value : This consists of one or more Sub-TLVs corresponding to DSL line attributes. No sub-TLVs other than the "DSL type" and "DSL line state" SHOULD be included in a PORT DOWN message. The general format of the sub-TLVs is identical to the general TLV format. The value field in each sub-TLV is padded to a 4-octet alignment. The Length field in each sub-TLV contains the actual number of bytes in the TLV (not including the padding if present). Current defined sub-TLV types are start from 0x81. Maybe you can point me to where exatly it is stated clearly as being mandat= ory, or otherwise explain why you "not agree"? PAR> I think you forgot to read the most important part where the actual TL= V is defined. Type (Actual-Net-Data-Upstream =3D 0x81): Actual upstream net data rate on = a DSL line. This is a mandatory TLV. Length : (4 bytes) Value : (Rate in Kb/sec) Type (Actual-Net-Data-Rate-Downstream =3D 0x82) : Actual downstream net dat= a rate on a DSL line. This is a mandatory TLV. Length : (4 bytes) Value : (Rate in Kb/sec) The fact you say "Port UP" and "OAM" is best considered as legacy applicati= ons, I have some trouble with this as well, since ANCP running in production networks use th= em, and as such it is a central part of the ANCP specifications we need to finish as soon a= s possible. Woj> I should have said legacy applications from a protocol messaging persp= ective, not usage, nor support. It's quite clear that GSMP derived messagin= g has baggage that is un called for in new applications. I think Stefaan's example is very valid, that we do not need to make mandat= ory requirements to what receivers of ANCP information use such info. for. I don't think we sh= ould try and make the ANCP specifications "mandatory" for box behavior, I think it is much more i= mportant for the working group to make the protocol specifications easy to understand and ge= t the first documentation finish and published, so the protocol can be used for different sets of app= lications, and make sure new applications can be added later. Woj> Indeed the aim of the WG to define a protocol that is relatively simpl= e and easy to understand, not just to implementers but also to people using= it, and across vendors. Currently, having anyone operating the device be f= amiliar in what cases a TLV is mandatory and in what optional requires a th= orough understanding of the spec, across applications. This is not easy, bu= t I'll conceede that for the applications implemented so far we could live = with it. I do think that by documenting if a TLV is mandatory or optional inside a s= pecific capability type, it is easy to understand what must be sent to support the defined applicati= on/capability type. Woj> Of course it is, the whole spec is about this. The problem comes when = people start to re-use well known TLVs for different applications, and then= trying to make sense of it all becomes non-trivial. Why do you think both = BGP and Diamater, and a number of other protocols have definied "Mandatory"= flags? Just for kicks? It's a well known protocol design tool, that comes = handy when re-using same data across multiple applications. PAR> I might be wrong, but I think I can find as many or more protocol exam= ples who do not include a mandatory/optional flag, so examples can always be found which will suppo= rt the point you are trying to make. I do not see a problem with a new internet-draft which defines new capabili= ty-types and where a TLV mandatory flag is included, I do see a problem if the intend is to try and = adjust what already exist. Then if anybody want to include new capability types or sub-TLVs later to a= ddress specific applications, then I think changes can be discussed at that time instead of trying to cha= nge existing protocol implementations. Woj> Again I ask, where in the proposal did you see *anything* requiring a = change to an existing implementation. Please be specific. I see that your m= ain objection is on this issue, which means that you accept proposal 1 (hav= e such a flag for new TLVs/apps). It would also be useful if you indicated whether the list of TLVs provided = below is what you'd expect to be the minimum mandatory set. PAR> at the moment I read the draft as having defined the TLVs mandatory as= you describe, except I also read it as the dsl-type =3D 0x91 must be part of the port down. If t= his is needed or not is a different discussion. cheers, Peter Cheers, Woj. cheers, Peter ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Woj= ciech Dec (wdec) Sent: 29. april 2008 02:28 To: DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal Stefaan, a number of points: 1. There currently is to my knowledge no implementation of ANCP there that = doesn't send the DSL Line attributes info by default in Port-UP messages? T= he support of HS on the NAS is an orthogonal issue. 2. The current ancp protocol draft (02) doesn't say whether the rate info i= s optional or mandatory, it only states that the sub-TLVs are mandatory. Ba= sed on this, an implementer can be justified to expect port-ups to *always*= have the rate-info tlv (ie treat them as mandatory). Equally, she's justif= ied in considering this as optional. 3. The port-up and OAM are best considered as legacy applications for ANCP.= The re-use of any of the GSMP defined fields is already out of the questio= n due to constrains put in place by the existing use-case messaging. Needle= ss to say, this wasn't as thoroughly designed as it should have been, and w= ith the OAM and port-up apps being coupled. 4. It's up to the application to define what TLVs are mandatory and which a= ren't, as you also state. The AN does not need to know what the NAS will do= with the info, BUT it needs to send the right TLVs for the application (eg= if we had a hypothetical AN that only sends Port-up's with line-id, it wou= ld be next to useless for the dynamic shaping application). With all this in mind it's useful to re-read what I proposed originally bel= ow regarding the mandatory flag: 1. "have this TLV Flag be defined only for= new applications" and 2. The notion of the mandatory flag applying to exis= ting TLVs being "conditional on deriving a suitable "commonly used" TLV se= t." The latter point would ensure that existing implementations do not need= to change, but future ones can take advantage of the extra robustness. Hence, can the WG derive a set of commonly used, i.e. always used, TLVs for= existing implementations? The list I came up is as follows (making them pretty much mandatory TLVs if= it agrees with the views of others); Port-up message (0x80); Extension-TLV (dsl tech type) Access-Loop-circuit-id (0x01) DSL Line Attribute (0x04) with the following sub TLVs; DSL-Type =3D 0x91; Actual-Net-Data-Upstream =3D 0x81; Actual-Net-Da= ta-Rate-Downstream =3D 0x82 Port-down message (0x81); Extension TLV (dsl tech type) Access-Loop-circuit-id (0x01) DSL Line Attribute (0x04) with the following sub TLVs; DSL line state =3D 0x8F All other TLVs are optional. Would appreciate confirmation from the WG regarding the above. Thanks, Woj. ________________________________ From: DE CNODDER Stefaan [mailto:stefaan.de_cnodder@alcatel-lucent.be] Sent: 29 April 2008 09:52 To: Wojciech Dec (wdec); Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal Hi Woj, Take the following example: I have a network with 2 NASses, NAS-A is doing = hierarchical shaping, NAS-B just wants to have the port information but is = not doing hierarchical shaping (it is doing other things like OAM, ...). T= his means NAS-A needs the bandwidth, while NAS-B does not need the bandwidt= h. How should the flag be set in this case by the AN? Set to 'Mandatory' = for the port up messages to NAS-A, and set to 'Optional' for port up messag= es towards NAS-B? Or is it always set to 'Mandatory'? From your answer bel= ow, I understand that it should be set to 'Optional' towards NAS-B. Is tha= t correct? NAS-B will simply ignore the bandwidth TLV. If such a flag would exist, an= d the flag is set to 'Mandatory' by the AN to NAS-B, what should be the beh= avior of NAS-B? Should it reject the whole message? Maybe NAS-B is not su= pporting hierarchical shaping, so it might not support the bandwidth TLV. = Today, the bandwidht TLV is only mandatory to be put in the port up message= s, but for the receiver there is nothing mandatory. I believe the original intend of ANCP was that the AN does not need to know= what the NAS is doing with this information, the use of the bandwidth is a= lso not specified by ANCP, only an example is given (which is shaping). In= the future there may be applications for which TLVs will be mandatory whic= h are now optional. regards, Stefaan ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] Sent: maandag 28 april 2008 21:33 To: DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal ________________________________ From: DE CNODDER Stefaan [mailto:stefaan.de_cnodder@alcatel-lucent.be] Sent: 28 April 2008 17:15 To: Wojciech Dec (wdec); Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal Take the bandwidth sub-TLV in port up messages as example. The current pro= tocol spec says that it is mandatory to be sent in port up messages. that'= s ok. But it is not mandatory for the receiver to process the bandwidth su= b-TLV. What is done with this information by the NAS is not specified by A= NCP, so you cannot make it mandatory for the receiver side. Woj> Is the information required by the application? It would appear for th= e dynamic shaping use-case to be most certainly so. Hence it is absolutely = mandatory, otherwise the message makes no sense for the application. In any= case, if So it looks to me that the flag can only indicate what the receiver should = do. Then the flag makes sense. Woj> The flag tells the receiver what info the sender thinks is required t= o carry out the application. This in almost all cases has to match up to wh= at the receiver thinks is required. The sender doesn't tell the receiver wh= at to do with the info. If the receiver knows what is mandatory, then I do not see a reason why thi= s has to be made explicit in the protocol. It would only complicate the pr= otocol. As already said by Michael: if a mandatory TLV is not there, then = it is just a bug. Woj> Can you specifically describe what aspect of the protocol does it comp= licate? It's just making explicitly clear what the protocol already has to = implement anyway to be of any use. As to whether it is a bug, having such explicit marking makes it clear what= /where the problem is when observing a messaging flow vs a lot of deduction= work. In any case, the other point being made here is that today the proto= col does NOT specify what should happen if a mandatory TLV is missing. -Woj. regards, Stefaan ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] Sent: maandag 28 april 2008 16:28 To: DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal It's actually a mix of both. Inline... ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of DE = CNODDER Stefaan Sent: 28 April 2008 16:04 To: Wojciech Dec (wdec); Busser, M; ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal Hi, This new mandatory flag, what is exactly its meaning? (1) if flag set to "mandatory", then the *receiver* of this TLV MUST proces= s it, and if unrecognized must drop the message If a received TLV is has the "mandatory" flag set then the receiver MUST dr= op the message and report an error to the sender if it doesn't recognize th= e TLV. If a the receiver expects a "mandatory" TLV but doesn't receive it, the mes= sage MUST be droped and an error report sent to the sender. OR (2) if flag is set to"mandatory", then the *sender* MUST include it in the = message for which it is defined The sender MUST include mandatory TLVs as defined by the protocol-spec/appl= ications. The current protocols draft says for certain TLVs that they are mandatory, = but that applies to the sender of it (interpretation 2). The flag would in= dicate interpretation 1 (like for Radius VSAs?)? If the higher order bit is set to "0" means that it is mandatory, then curr= ently defined optional defined TLVs suddenly become mandatory which is not = good. Woj> Only the currently used TLVs become mandatory. If they are not used/im= plemented we can re-define them as optional (set flag to 1) at no cost. But I would first to understand the exact meaning of this mandatory flag. = Defining such a flag indeed looks useful but then as interpretation 1, and = I would say that if flag set to 1, then it is mandatory and actually, it is= possible that a TLV is sent sometimes as optional and sometimes as mandato= ry. Woj> Precisely, that is possible on a per application basis. Having the fla= g would make troubleshooting of a message flow much more explicit (today, w= ith any problem one has to browse the drafts to figure out what MUST be the= re vs what SHOULD be there all while looking what is actually there) Regards, Woj. regards, Stefaan ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Woj= ciech Dec (wdec) Sent: donderdag 24 april 2008 14:19 To: Busser, M; ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal Hi Michael, inline... ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Bus= ser, M Sent: 24 April 2008 13:13 To: ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal Hi Woi, all I see the problem but i can not see, how an additional flag will help solvi= ng this problem. Lets assume your first proposal. If an implementation does not send the complete TLV, even it is defined to = be mandatory, I would call this a bug and I can not see, how an additional = flag can help here. Woj> The way it helps, and other protocols bear proof of this scheme, is th= at it is easier for implementations to reconcile errors resulting out of "M= andatory" and "Optional" TLV sets. The key to this lies on a per applicatio= n basis. One application may mandate TLV A for operation, while another mig= ht not. Resolving such issues when implementing or troubleshooting multiple= applications is not always trivial. Your second proposal seems obviously be required to keep existing things wo= rking, if we agree on your first proposal. But from my point of view it also assumes, that all existing implementation= s are using the same set of TLVs now. And I am not sure about that. Woj> This would be a good thing for the WG to discuss. There most evidently= is a fair amount of "dead wood" in the current spec, ie stuff that nobody = yet implements or cares about. In the former case, we could re-cast that m= aterial using the new notions/extensions, in the latter case simply chop it= out. Therefore I disagree with your first proposal. I recommend, the better way = will be to be more precise in definitions. In my mind, it is a bug, if a mandatory TLV is missing. It is up to the rob= ustness of the implementation to deal with this situation. Is it really neccesary to define the behavior of a network element in this = case of failure in the ancp protocol itself? Woj> Other people have faced this problem before, and I would rather go wit= h the lessons they learned, rather than clinging to hopes of perfect textua= l definitions and implementations. Other than backwards compatibility, I do= not see in your statements a valid reason to object to the 1st proposal, p= articularly for new applications since it can only make things more robust.= The counter argument of being precise in the definitions, as evidenced by = the current spec, is admirable and needs to be there, with this proposal pr= oviding an extra level of robustness and visibility of any problems. Thanks, Woj. If optional TLVs are not present in a message, we should describe some kind= of default behaviour, as you already stated. Comments on draft-ietf-ancp-protocol-02.txt: It is not clearly stated, if the TLV "DSL Line Attributes " is mandatory o= r optional. In fact it is mandatory because some of its SubTLVs are mandatory. We should spent a sentence to make this clear. It is not clearly stated, if the TLV "Service-Profile-Name" is mandatory o= r optional. I prefer mandatory because it is essetial for the use case Line Config. Section 5.4.3 Line Config, where the TLVs are mentioned (page 35): ...defined in section 5.4.1.... must be corrected to ...defined in = section 5.4.2........ Section 5.4.4 OAM, where the TLVs are mentioned (page 36 and page 38): ...defined in section 5.4.1.... must be corrected to ...defined in = section 5.4.2........ Best Regards; Freundliche Gr=FC=DFe Michael Busser T-Systems Enterprise Services GmbH Production Line Network Centric Systems ICT-Systems Integration Network Integration Services Br=FCckes 2 -8, 55545 Bad Kreuznach Postfach 9100, 55541 Bad Kreuznach +49 671 8333 8911 (Phone) +49 521 9210 3859 (Fax) +49 151 1211 9689 (Mobile) E-Mail: michael.busser@t-systems.com<mailto:michael.busser@t-systems.com> Internet: http://www.t-systems.com<http://www.t-systems.com/> T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Reinhard Clemens (Vorsitzender)*, Helmut Binder, Alber= t Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Wilfried Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG Notice: This transmittal and/or attachments may be privileged or confidenti= al. If you are not the intended recipient, you are hereby notified that you= have received this transmittal in error; any review, dissemination, or cop= ying is strictly prohibited. If you received this transmittal in error, ple= ase notify us immediately by reply and immediately delete this message and = all its attachments. Thank you. T-Systems - Business flexibility ________________________________ Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von Wo= jciech Dec (wdec) Gesendet: Mittwoch, 23. April 2008 14:54 An: ancp@ietf.org Betreff: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal Hi All, Continuing with the series of e-mails regarding basic protocol issues still= to be addressed, I now would now like to ask your feedback regarding the d= istinction the protocol places on mandatory TLVs. Given the length of this = mail I'll first cut to the proposal, and after it you can find the problem = description. The proposal which I am putting in front of the WG is to define a new TLV f= ormat which contains at a minimum a Mandatory flag (much like Radius VSAs d= o). We could have this TLV Flag be defined only for new applications. A second proposal would be try to make this flag work with existing ones by= for example defining the highest order bit of the TLV# field to mean "Mand= atory" when set to "0". This would be invisible to exiting implementations,= but newer ones may have problems in communicating with older ones when the= latter do not send all TLVs. But that can also be addressed by simply form= ing the set of mandatory TLVs to be the ones that all implementations curre= ntly send by default. Without additional feedback, I will assume that the WG is fine with the fir= st proposal, and also with the 2nd one conditional on deriving a suitable "= commonly used" TLV set. The problem in more detail: Currently the situation is that Mandatory TLVs are only stated to be as suc= h in the body of the protocol draft spec, with an implementer having to sco= ur fairly attentively the text. Eg "Type (Access-Loop-Circuit-ID =3D 0x01):= This is a mandatory TLV", etc. The behaviour of an implementation that receives a message with a missing m= andatory TLV is not defined at all, and the opposite is handled but not ver= y robustly, i.e. when receiving a TLV but not recognizing it, and implement= ation is free to discard it (even if it is mandatory!). This is a recipe fo= r interoperability problems and an implementation mine field. This problem is complicated by different applications. For example the curr= ent OAM section states the following regarding TLVs that are to be carried = in the request message (my italics): " Following TLVs can appear in this message: o Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section 5.4.1 o Type (Access-Aggregation-Circuit-ID-Binary =3D 0x06): defined in section 5.4.1. o Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03): defined in se= ction 5.4.1. o Type (OAM-Loopback-Test-Parameters =3D 0x07): Parameters related t= o loopback test. This is an optional TLV. If this TLV is not present in the request message, the DSLAM SHOULD use locally determined default values for the test parameters. " (NOTE: The last "SHOULD" appears to be inappropriate. If the TLV is missing= , the DSLAM MUST have some default parameters, or return an error) The "can" above indicates that they're all optional, while clearly the appl= ication cannot run its course without one or more of these fields. Here we = have a case where one could have a perfectly compliant implementation that = ignores all these TLVs... -Woj. --_000_48C276B536524E478C659685995F6AA539DBB4F25FRBSJXadredbac_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns:v =3D "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word" xmlns:p =3D=20 "urn:schemas-microsoft-com:office:powerpoint"><HEAD><TITLE>Nachricht</TITLE= > <META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1"= > <META content=3D"MSHTML 6.00.6000.16640" name=3DGENERATOR><!--[if !mso]> <STYLE>v\:* { BEHAVIOR: url(#default#VML) } o\:* { BEHAVIOR: url(#default#VML) } w\:* { BEHAVIOR: url(#default#VML) } .shape { BEHAVIOR: url(#default#VML) } </STYLE> <![endif]--> <STYLE>@font-face { font-family: Tahoma; } @page Section1 {size: 595.3pt 841.9pt; margin: 70.85pt 70.85pt 2.0cm 70.85p= t; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline } A:visited { COLOR: purple; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline } P { FONT-SIZE: 12pt; MARGIN-LEFT: 0cm; MARGIN-RIGHT: 0cm; FONT-FAMILY: "Times = New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto } SPAN.E-MailFormatvorlage18 { COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply } DIV.Section1 { page: Section1 } </STYLE> </HEAD> <BODY lang=3DDE vLink=3Dpurple link=3Dblue> <DIV dir=3Dltr align=3Dleft><SPAN class=3D982091818-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>Hi Woj,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D982091818-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D982091818-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>please see inline in your answers</FONT></SPAN></D= IV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D982091818-29042008><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px soli= d; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com] <BR><B>Sent:</B> 29. april 2008 11:07<BR><B>To:</= B>=20 Peter Arberg; DE CNODDER Stefaan; Busser, M; ancp@ietf.org<BR><B>Cc:</B> = Haag,=20 T<BR><B>Subject:</B> RE: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-pro= tocol=20 proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D547254517-29042008><FONT face= =3DArial=20 size=3D2>Hi Peter,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D547254517-29042008><FONT face= =3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D547254517-29042008><FONT face= =3DArial=20 size=3D2></FONT></SPAN> </DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px so= lid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Peter Arberg=20 [mailto:parberg@redback.com] <BR><B>Sent:</B> 29 April 2008=20 19:34<BR><B>To:</B> Wojciech Dec (wdec); DE CNODDER Stefaan; Busser, M;= =20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> RE: Re: [ANCP]=20 Mandatory TLVs in draft-ietf-ancp-protocol proposal<BR></FONT><BR></DIV= > <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2>Hi Woj,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2>I agree with Michael and Stefan on this issue,= I do not=20 see a need to change the existing</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>implementation with a= =20 mandatory/optional flag.<SPAN class=3D547254517-29042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008></SPAN></FONT></FONT></FONT></SPAN> </D= IV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><SPAN class=3D547254517-29042008><FONT face=3DArial><FO= NT=20 size=3D2><FONT color=3D#000000>Woj> Please indicate where in my prop= osal did=20 you see anything about</FONT> <FONT color=3D#000000>changing exist= ing=20 implementaions? </FONT><FONT color=3D#0000ff><SPAN=20 class=3D982091818-29042008> </SPAN></FONT></FONT></FONT></SPAN></F= ONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><SPAN class=3D547254517-29042008><FONT face=3DArial><FO= NT=20 size=3D2><FONT color=3D#0000ff><SPAN=20 class=3D982091818-29042008></SPAN></FONT></FONT></FONT></SPAN></FONT></= SPAN> </DIV></BLOCKQUOTE></BLOCKQUOTE> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT><SPAN=20 class=3D547254517-29042008><FONT><FONT face=3DArial color=3D#0000ff size=3D= 2><SPAN=20 class=3D982091818-29042008>PAR>  I might have misunderstood yo= ur=20 email, but I read it as if you suggest a high=20 bit</SPAN></FONT></FONT></SPAN></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT><SPAN=20 class=3D547254517-29042008><FONT><FONT face=3DArial color=3D#0000ff size=3D= 2><SPAN=20 class=3D982091818-29042008>value in existing TLV's to be interpreted as a=20 mandatory flag.</SPAN></FONT></FONT></SPAN></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT><SPAN=20 class=3D547254517-29042008><FONT><FONT face=3DArial color=3D#0000ff size=3D= 2><SPAN=20 class=3D982091818-29042008></SPAN></FONT></FONT></SPAN></FONT></SPAN> = </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT><SPAN=20 class=3D547254517-29042008><FONT><FONT face=3DArial color=3D#0000ff size=3D= 2><SPAN=20 class=3D982091818-29042008>If you are simply talking about new capability t= ype=20 definitions, then why do you not bring=20 up</SPAN></FONT></FONT></SPAN></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT><SPAN=20 class=3D547254517-29042008><FONT><FONT face=3DArial color=3D#0000ff size=3D= 2><SPAN=20 class=3D982091818-29042008>the additional flag in a new internet-draft defi= ning=20 what capability type you have in mind=20 ?</SPAN></FONT></FONT></SPAN></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT><SPAN=20 class=3D547254517-29042008><FONT><FONT face=3DArial color=3D#0000ff size=3D= 2><SPAN=20 class=3D982091818-29042008> </SPAN></FONT></FONT></SPAN></FONT></SPAN>= </DIV> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px soli= d; MARGIN-RIGHT: 0px"> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px so= lid; MARGIN-RIGHT: 0px"> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2>I think I understand your arguments, but I do = not agree=20 with them. I think most places in</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>the draft it is clear= what is=20 defined as mandatory and optional.<SPAN class=3D547254517-29042008><FON= T=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2>I agree on the point we need to go through the= draft=20 and make clarifications to what TLV's</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2>in what capability types are mandatory and opt= ional,=20 and make more description what should</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>happen if mandatory T= LVs are not=20 included.<SPAN class=3D547254517-29042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008></SPAN></FONT></FONT></FONT></SPAN> </D= IV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008><FONT color=3D#000000>Woj>=20 Exactly.</FONT> </SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2>I think the DSLF TR-101 document has a good ex= ample of=20 such a description in it's </FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 size=3D2><FONT color=3D#0000ff>"</FONT><FONT face=3DArial-BoldMT size= =3D2><FONT=20 color=3D#0000ff>Table 3 - Access loop characteristics sub-options<SPAN= =20 class=3D058271017-29042008>", and I think if we do the same for=20 each</SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 size=3D2><FONT face=3DArial-BoldMT size=3D2><FONT color=3D#0000ff><SPAN= =20 class=3D058271017-29042008>capability types TLV's in the ANCP draft it = will be=20 a good help.</SPAN></FONT></DIV></FONT></FONT></SPAN> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT color=3D#0000ff><FONT face=3DArial><FO= NT=20 size=3D2><FONT color=3D#000000>Woj></FONT> <FONT color=3D#000000>Ind= eed,=20 pre-ceeded by some rationalization. The appears to be no reason for som= e of=20 the DSLF "mandatory" TLVs.</FONT><FONT color=3D#0000ff><SPAN=20 class=3D982091818-29042008> </SPAN></FONT></FONT></FONT></FONT></S= PAN></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT color=3D#0000ff><FONT face=3DArial><FO= NT=20 size=3D2><FONT color=3D#0000ff><SPAN=20 class=3D982091818-29042008></SPAN></FONT></FONT></FONT></FONT></SPAN></= SPAN> </DIV></BLOCKQUOTE></BLOCKQUOTE> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT color= =3D#0000ff><SPAN=20 class=3D058271017-29042008><SPAN class=3D547254517-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><FONT color=3D#0000ff><SP= AN=20 class=3D982091818-29042008>PAR> I do not see a problem with re-visit in = the=20 draft if a TLV should be optional or mandatory, so=20 if</SPAN></FONT></FONT></FONT></FONT></SPAN></SPAN></FONT></FONT></FONT></D= IV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT color= =3D#0000ff><SPAN=20 class=3D058271017-29042008><SPAN class=3D547254517-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><FONT color=3D#0000ff><SP= AN=20 class=3D982091818-29042008>that is the intend, then I'm all for an email=20 discussion on a TLV by TLV basis if we think it is a=20 </SPAN></FONT></FONT></FONT></FONT></SPAN></SPAN></FONT></FONT></FONT></DIV= > <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT color= =3D#0000ff><SPAN=20 class=3D058271017-29042008><SPAN class=3D547254517-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><FONT color=3D#0000ff><SP= AN=20 class=3D982091818-29042008>manfdatory or optional information inside the sp= ecific=20 capability=20 type.</SPAN></FONT></FONT></FONT></FONT></SPAN></SPAN></FONT></FONT></FONT>= </DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT color= =3D#0000ff><SPAN=20 class=3D058271017-29042008><SPAN class=3D547254517-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><FONT color=3D#0000ff><SP= AN=20 class=3D982091818-29042008></SPAN></FONT></FONT></FONT></FONT></SPAN></SPAN= ></FONT></FONT></FONT> </DIV> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px soli= d; MARGIN-RIGHT: 0px"> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px so= lid; MARGIN-RIGHT: 0px"> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT color=3D#0000ff><FONT face=3DArial><FO= NT=20 size=3D2><FONT color=3D#0000ff><SPAN=20 class=3D982091818-29042008> </SPAN></FONT></FONT></FONT></FONT></S= PAN></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2>I do not agree with your point that it is not = listed if=20 "rate" is mandatory or optional, it is clearly</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2>listed as a mandatory TLV, and as such it shou= ld be=20 included in the port up message, I really</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>do not understand wha= t confusion=20 you have with this.<SPAN class=3D547254517-29042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008></SPAN></FONT></FONT></FONT></SPAN> </D= IV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008><FONT color=3D#000000>Woj> The text=20 states:  </FONT> </SPAN></FONT></FONT></FONT></SPAN></DI= V> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008></SPAN></FONT></FONT></FONT></SPAN> </D= IV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008><FONT size=3D1><FONT face=3D"Courier New" co= lor=3D#000000=20 size=3D2>5. Type (DSL Line Attributes =3D 0x04): </FONT></DIV> <P dir=3Dltr align=3Dleft><FONT face=3D"Courier New" color=3D#000000 si= ze=3D2>Length :=20 variable (up to 1024 bytes) </FONT></P> <P dir=3Dltr align=3Dleft><FONT face=3D"Courier New" color=3D#000000 si= ze=3D2>Value :=20 This consists of one or more Sub-TLVs corresponding to DSL </FONT></P> <P dir=3Dltr align=3Dleft><FONT face=3D"Courier New" color=3D#000000 si= ze=3D2>line=20 attributes. No sub-TLVs other than the "DSL type" and "DSL </FONT></P> <P dir=3Dltr align=3Dleft><FONT face=3D"Courier New" color=3D#000000 si= ze=3D2>line=20 state" SHOULD be included in a PORT DOWN message. </FONT></P> <P dir=3Dltr align=3Dleft><FONT face=3D"Courier New" color=3D#000000 si= ze=3D2>The=20 general format of the sub-TLVs is identical to the general TLV </FONT><= /P> <P dir=3Dltr align=3Dleft><FONT face=3D"Courier New" color=3D#000000 si= ze=3D2>format.=20 The value field in each sub-TLV is padded to a 4-octet </FONT></P> <P dir=3Dltr align=3Dleft><FONT face=3D"Courier New" color=3D#000000=20 size=3D2>alignment. The Length field in each sub-TLV contains the actua= l=20 </FONT></P> <P dir=3Dltr align=3Dleft><FONT face=3D"Courier New" color=3D#000000 si= ze=3D2>number=20 of bytes in the TLV (not including the padding if present). </FONT></P> <P dir=3Dltr align=3Dleft><FONT color=3D#000000><FONT face=3D"Courier N= ew"=20 size=3D2>Current defined sub-TLV types are start from 0x81.</FONT> = ;<SPAN=20 class=3D547254517-29042008><FONT face=3DArial=20 size=3D2> </FONT></SPAN></FONT></P> <P dir=3Dltr align=3Dleft><FONT color=3D#000000><SPAN=20 class=3D547254517-29042008><FONT face=3DArial size=3D2>Maybe you can po= int me to=20 where exatly it is stated clearly as being mandatory, or otherwise expl= ain=20 why you "not agree"?</FONT> <SPAN class=3D982091818-29042008><FONT= =20 face=3DArial color=3D#0000ff size=3D2> </FONT></SPAN></SPAN></FONT= ></P> <P dir=3Dltr align=3Dleft><FONT color=3D#000000><SPAN=20 class=3D547254517-29042008><SPAN=20 class=3D982091818-29042008></SPAN></SPAN></FONT> </P></BLOCKQUOTE>= </BLOCKQUOTE> <DIV dir=3Dltr align=3Dleft><FONT color=3D#000000 size=3D2><SPAN=20 class=3D547254517-29042008><SPAN class=3D982091818-29042008>PAR> I think= you=20 forgot to read the most important part where the actual TLV is=20 defined.</SPAN></SPAN></FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT color=3D#000000 size=3D2><SPAN=20 class=3D547254517-29042008><SPAN=20 class=3D982091818-29042008></SPAN></SPAN></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><FONT color=3D#000000 size=3D2><SPAN=20 class=3D547254517-29042008><SPAN class=3D982091818-29042008>Type=20 (Actual-Net-Data-Upstream =3D 0x81): Actual upstream net data rate on = a DSL=20 line. </SPAN></SPAN></FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT color=3D#000000 size=3D2><SPAN=20 class=3D547254517-29042008><SPAN class=3D982091818-29042008>This is a manda= tory=20 TLV.  </SPAN></SPAN></FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><FONT color=3D#000000 size=3D2><SPAN=20 class=3D547254517-29042008><SPAN class=3D982091818-29042008>Length  :&= nbsp; (4=20 bytes) </SPAN></SPAN></FONT></DIV> <DIV><FONT color=3D#000000 size=3D2><SPAN class=3D547254517-29042008><SPAN= =20 class=3D982091818-29042008>Value   : (Rate in Kb/sec)=20 </SPAN></SPAN></FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><FONT color=3D#000000 size=3D2><SPAN=20 class=3D547254517-29042008><SPAN class=3D982091818-29042008>Type=20 (Actual-Net-Data-Rate-Downstream =3D 0x82) : Actual downstream net data rat= e on a=20 DSL line. </SPAN></SPAN></FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT color=3D#000000 size=3D2><SPAN=20 class=3D547254517-29042008><SPAN class=3D982091818-29042008>This is a manda= tory TLV.=20 </SPAN></SPAN></FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><FONT color=3D#000000 size=3D2><SPAN=20 class=3D547254517-29042008><SPAN class=3D982091818-29042008>Length :  = (4 bytes)=20 </SPAN></SPAN></FONT></DIV> <DIV><FONT color=3D#000000 size=3D2><SPAN class=3D547254517-29042008><SPAN= =20 class=3D982091818-29042008>Value  :  (Rate in Kb/sec)=20 </SPAN></SPAN></FONT></DIV> <DIV><FONT color=3D#000000 size=3D2><SPAN class=3D547254517-29042008><SPAN= =20 class=3D982091818-29042008> </SPAN></SPAN></FONT></DIV> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px soli= d; MARGIN-RIGHT: 0px"> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px so= lid; MARGIN-RIGHT: 0px"><FONT=20 size=3D2></FONT><FONT size=3D2></FONT></FONT></SPAN></FONT></FONT></FON= T></SPAN> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2>The fact you say "Port UP" and "OAM" is best c= onsidered=20 as legacy applications, I have some</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2>trouble with this as well, since ANCP running = in=20 production networks use them, and as such</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>it is a central part = of the ANCP=20 specifications we need to finish as soon as possible.<SPAN=20 class=3D547254517-29042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008></SPAN></FONT></FONT></FONT></SPAN> </D= IV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008><FONT color=3D#000000>Woj> I should have = said=20 legacy applications from a protocol messaging perspective, not usage, n= or=20 support. It's quite clear that GSMP derived messaging has baggage that = is un=20 called for in new=20 applications.</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2>I think Stefaan's example is very valid, that = we do not=20 need to make mandatory requirements to </FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2>what receivers of ANCP information use such in= fo.=20 for.  I don't think we should try and make the</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2>ANCP specifications "mandatory" for box behavi= or, I=20 think it is much more important for the </FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2>working group to make the protocol specificati= ons easy=20 to understand and get the first documentation</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2>finish and published, so the protocol can be u= sed for=20 different sets of applications, and make sure</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>new applications can = be added=20 later.<SPAN class=3D547254517-29042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008></SPAN></FONT></FONT></FONT></SPAN> </D= IV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008><FONT color=3D#000000>Woj> Indeed the aim= of the=20 WG to define a protocol that is relatively simple and easy to understan= d,=20 not just to implementers but also to people using it, and across vendor= s.=20 Currently, having anyone operating the device be familiar in what cases= a=20 TLV is mandatory and in what optional requires a thorough understanding= of=20 the spec, across applications. This is not easy, but I'll conceede that= for=20 the applications implemented so far we could live with it.=20 </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2>I do think that by documenting if a TLV is man= datory or=20 optional inside a specific capability type,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>it is easy to underst= and what=20 must be sent to support the defined application/capability type.<SPAN=20 class=3D547254517-29042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008></SPAN></FONT></FONT></FONT></SPAN> </D= IV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><SPAN class=3D547254517-29042008><FONT color=3D#000000>= <FONT=20 face=3DArial><FONT size=3D2>Woj> Of course it is, the whole spe= c is=20 about this. The problem comes when people start to re-use well kno= wn=20 TLVs for different applications, and then trying to make sense of it al= l=20 becomes non-trivial. Why do you think both BGP and Diamater, and a numb= er of=20 other protocols have definied "Mandatory" flags? Just for kicks? It's a= well=20 known protocol design tool, that comes handy when re-using same data ac= ross=20 multiple applications.<SPAN class=3D982091818-29042008><FONT=20 color=3D#0000ff> </FONT></SPAN></FONT></FONT></FONT></SPAN></FONT>= </SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><SPAN class=3D547254517-29042008><FONT color=3D#000000>= <FONT=20 face=3DArial><FONT size=3D2><SPAN=20 class=3D982091818-29042008></SPAN></FONT></FONT></FONT></SPAN></FONT></= SPAN> </DIV></BLOCKQUOTE></BLOCKQUOTE> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT color= =3D#0000ff><SPAN=20 class=3D058271017-29042008><FONT color=3D#0000ff><SPAN=20 class=3D547254517-29042008><FONT color=3D#000000><FONT face=3DArial><FONT s= ize=3D2><SPAN=20 class=3D982091818-29042008>PAR> I might be wrong, but I think I can find= as=20 many or more protocol examples who do not=20 include</SPAN></FONT></FONT></FONT></SPAN></FONT></SPAN></FONT></FONT></FON= T></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT color= =3D#0000ff><SPAN=20 class=3D058271017-29042008><FONT color=3D#0000ff><SPAN=20 class=3D547254517-29042008><FONT color=3D#000000><FONT face=3DArial><FONT s= ize=3D2><SPAN=20 class=3D982091818-29042008>a mandatory/optional flag, so examples can alway= s be=20 found which will support the point you are=20 trying</SPAN></FONT></FONT></FONT></SPAN></FONT></SPAN></FONT></FONT></FONT= ></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT color= =3D#0000ff><SPAN=20 class=3D058271017-29042008><FONT color=3D#0000ff><SPAN=20 class=3D547254517-29042008><FONT color=3D#000000><FONT face=3DArial><FONT s= ize=3D2><SPAN=20 class=3D982091818-29042008>to=20 make.</SPAN></FONT></FONT></FONT></SPAN></FONT></SPAN></FONT></FONT></FONT>= </DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT color= =3D#0000ff><SPAN=20 class=3D058271017-29042008><FONT color=3D#0000ff><SPAN=20 class=3D547254517-29042008><FONT color=3D#000000><FONT face=3DArial><FONT s= ize=3D2><SPAN=20 class=3D982091818-29042008></SPAN></FONT></FONT></FONT></SPAN></FONT></SPAN= ></FONT></FONT></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT color= =3D#0000ff><SPAN=20 class=3D058271017-29042008><FONT color=3D#0000ff><SPAN=20 class=3D547254517-29042008><FONT color=3D#000000><FONT face=3DArial><FONT s= ize=3D2><SPAN=20 class=3D982091818-29042008>I do not see a problem with a new internet-draft= which=20 defines new capability-types and where a=20 TLV</SPAN></FONT></FONT></FONT></SPAN></FONT></SPAN></FONT></FONT></FONT></= DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT color= =3D#0000ff><SPAN=20 class=3D058271017-29042008><FONT color=3D#0000ff><SPAN=20 class=3D547254517-29042008><FONT color=3D#000000><FONT face=3DArial><FONT s= ize=3D2><SPAN=20 class=3D982091818-29042008>mandatory flag is included, I do see a problem i= f the=20 intend is to try and adjust what already=20 exist. </SPAN></FONT></FONT></FONT></SPAN></FONT></SPAN></FONT></FONT>= </FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT color= =3D#0000ff><SPAN=20 class=3D058271017-29042008><FONT color=3D#0000ff><SPAN=20 class=3D547254517-29042008><FONT color=3D#000000><FONT face=3DArial><FONT s= ize=3D2><SPAN=20 class=3D982091818-29042008></SPAN></FONT></FONT></FONT></SPAN></FONT></SPAN= ></FONT></FONT></FONT> </DIV> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px soli= d; MARGIN-RIGHT: 0px"> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px so= lid; MARGIN-RIGHT: 0px"> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><SPAN class=3D547254517-29042008><FONT color=3D#000000>= <FONT=20 face=3DArial><FONT size=3D2><SPAN=20 class=3D982091818-29042008> </SPAN></FONT></FONT></FONT></SPAN></F= ONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2>Then if anybody want to include new capability= types or=20 sub-TLVs later to address specific applications,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2>then I think changes can be discussed at that = time=20 instead of trying to change existing protocol</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>implementations.<SPAN= =20 class=3D547254517-29042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008></SPAN></FONT></FONT></FONT></SPAN> </D= IV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008><FONT color=3D#000000>Woj> Again I ask, w= here in=20 the proposal did you see *anything* requiring a change to an exist= ing=20 implementation. Please be specific.</FONT> <FONT color=3D#000000>I= see=20 that your main objection is on this issue, which means that you accept= =20 proposal 1 (have such a flag for new=20 TLVs/apps).</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT face=3DArial><FONT size=3D2>It would a= lso be=20 useful if you indicated whether the list of TLVs provided below is what= =20 you'd expect to be the minimum mandatory set.<SPAN=20 class=3D982091818-29042008><FONT=20 color=3D#0000ff> </FONT></SPAN></FONT></FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D982091818-29042008></SPAN></FONT></FONT></SPAN></SPAN> </D= IV></BLOCKQUOTE></BLOCKQUOTE> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT><FONT face=3DArial color=3D#0000ff size=3D= 2><SPAN=20 class=3D982091818-29042008>PAR> at the moment I read the draft as=20 having defined the TLVs mandatory as you describe,=20 except</SPAN></FONT></FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT><FONT face=3DArial color=3D#0000ff size=3D= 2><SPAN=20 class=3D982091818-29042008>I also read it as the dsl-type =3D 0x91 mus= t be part=20 of the port down. If this is needed or not is a=20 different</SPAN></FONT></FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT><FONT face=3DArial color=3D#0000ff size=3D= 2><SPAN=20 class=3D982091818-29042008>discussion.</SPAN></FONT></FONT></SPAN></SPAN></= DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT><FONT face=3DArial color=3D#0000ff size=3D= 2><SPAN=20 class=3D982091818-29042008></SPAN></FONT></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT><FONT face=3DArial color=3D#0000ff size=3D= 2><SPAN=20 class=3D982091818-29042008>cheers,</SPAN></FONT></FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT><FONT face=3DArial color=3D#0000ff size=3D= 2><SPAN=20 class=3D982091818-29042008>Peter</SPAN></FONT></FONT></SPAN></SPAN><SPAN=20 class=3D058271017-29042008><SPAN class=3D547254517-29042008><FONT><FONT fac= e=3DArial=20 color=3D#0000ff size=3D2><SPAN=20 class=3D982091818-29042008> </SPAN></FONT></FONT></SPAN></SPAN></DIV> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px soli= d; MARGIN-RIGHT: 0px"> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px so= lid; MARGIN-RIGHT: 0px"> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT size= =3D+0><FONT=20 face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008></SPAN></FONT></FONT></FONT></SPAN> </D= IV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT size= =3D+0><FONT=20 face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008>Cheers,</SPAN></FONT></FONT></FONT></SPAN></= DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT size= =3D+0><FONT=20 face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008>Woj.</SPAN></FONT></FONT></FONT></SPAN></DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2>cheers,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2>Peter</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT face= =3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft= > <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>Wojciech Dec=20 (wdec)<BR><B>Sent:</B> 29. april 2008 02:28<BR><B>To:</B> DE CNODDER= =20 Stefaan; Busser, M; ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject= :</B>=20 Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol=20 proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT fa= ce=3DArial=20 size=3D2>Stefaan,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT fa= ce=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT fa= ce=3DArial=20 size=3D2>a number of points:</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT fa= ce=3DArial=20 size=3D2>1. There currently is to my knowledge no implementation= of=20 ANCP there that doesn't send the DSL Line attributes info by default = in=20 Port-UP messages? The support of HS on the NAS is an orthogonal=20 issue.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT fa= ce=3DArial=20 size=3D2>2. T</FONT></SPAN><SPAN class=3D342501308-29042008><FONT fac= e=3DArial=20 size=3D2>he current ancp protocol draft (02) doesn't say whether the = rate=20 info is optional or mandatory, it only states that the sub-TLVs are=20 mandatory. Based on this, an implementer can be justified to exp= ect=20 port-ups to *always* have the rate-info tlv (ie treat them as mandato= ry).=20 Equally, she's justified in considering this  as=20 optional.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><SPAN=20 class=3D342501308-29042008><FONT face=3DArial size=3D2>3.<EM> </= EM><SPAN=20 class=3D342501308-29042008><FONT face=3DArial size=3D2>The port-up an= d OAM=20 are best considered as legacy applications for ANCP. The re-use = of=20 any of the GSMP defined fields is already out of the question due to= =20 constrains put in place by the existing use-case messaging. Needless = to=20 say, this wasn't as thoroughly designed as it should have been, and w= ith=20 the OAM and port-up apps being=20 coupled.</FONT></SPAN></FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT fa= ce=3DArial=20 size=3D2>4. It's up to the application to define what TLVs are mandat= ory and=20 which aren't, as you also state. The AN does not need to know wh= at=20 the NAS will do with the info, BUT it needs to send the right TLVs fo= r the=20 application (eg if we had a hypothetical AN that only sends Port= -up's=20 with line-id, it would be next to useless for the dynamic shaping=20 application).</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT fa= ce=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT fa= ce=3DArial=20 size=3D2>With all this in mind it's useful to re-read what I proposed= =20 originally below regarding the mandatory flag: 1. "<EM>have this= TLV=20 Flag be defined only for new applications" </EM>and 2. The notion of = the=20 mandatory flag applying to existing TLVs  being "<EM>conditional= on=20 deriving a suitable "commonly used" TLV set." </EM>The latter point w= ould=20 ensure that existing implementations do not need to change, but futur= e=20 ones can take advantage of the extra robustness.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT fa= ce=3DArial=20 size=3D2><SPAN class=3D342501308-29042008></SPAN></FONT></SPAN><SPAN= =20 class=3D342501308-29042008><FONT face=3DArial=20 size=3D2><EM></EM></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT fa= ce=3DArial=20 size=3D2>Hence, can the WG derive a set of commonly used, i.e. always= used,=20 TLVs for existing implementations?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT fa= ce=3DArial=20 size=3D2>The list I came up is as follows (making them pretty much ma= ndatory=20 TLVs if it agrees with the views of others);</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT fa= ce=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT fa= ce=3DArial=20 size=3D2>Port-up message (0x80);</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT fa= ce=3DArial=20 size=3D2>    Extension-TLV (dsl tech=20 type)</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT fa= ce=3DArial=20 size=3D2>    Access-Loop-circuit-id=20 (0x01)</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT fa= ce=3DArial=20 size=3D2>    DSL Line Attribute (0x04) with the follow= ing sub=20 TLVs;</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008> <F= ONT=20 size=3D2>       DSL-Type =3D 0x91;=20 Actual-Net-Data-Upstream =3D 0x81<SPAN class=3D342501308-29042008>;=20 Actual-Net-Data-Rate-Downstream =3D 0x82</SPAN></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT fa= ce=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT fa= ce=3DArial=20 size=3D2>Port-down message (0x81);</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008> &n= bsp; =20 <FONT face=3DArial size=3D2>Extension  TLV (dsl tech=20 type)</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008> &n= bsp; =20 <FONT face=3DArial size=3D2>Access-Loop-circuit-id (0x01)</FONT></SPA= N></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008> &n= bsp; =20 <FONT face=3DArial size=3D2>DSL Line Attribute (0x04) with the follow= ing sub=20 TLVs;</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN=20 class=3D342501308-29042008>       = <FONT=20 size=3D2> DSL line state =3D 0x8F</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT fa= ce=3DArial=20 size=3D2>All other TLVs are optional.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT fa= ce=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT fa= ce=3DArial=20 size=3D2>Would appreciate confirmation from the WG regarding the=20 above.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT fa= ce=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT fa= ce=3DArial=20 size=3D2>Thanks,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT fa= ce=3DArial=20 size=3D2>Woj.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D342501308-29042008><FONT fa= ce=3DArial=20 size=3D2></FONT></SPAN> </DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2p= x solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dle= ft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> DE CNODDER Stefaan=20 [mailto:stefaan.de_cnodder@alcatel-lucent.be] <BR><B>Sent:</B> 29 A= pril=20 2008 09:52<BR><B>To:</B> Wojciech Dec (wdec); Busser, M;=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> RE: [ANCP]=20 Mandatory TLVs in draft-ietf-ancp-protocol proposal<BR></FONT><BR><= /DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Hi Woj,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Take the following example: I have a netwo= rk with 2=20 NASses, NAS-A is doing hierarchical shaping, NAS-B just wants to ha= ve=20 the port information but is not doing hierarchical shaping (it is d= oing=20 other things like OAM, ...).  This means NAS-A needs the bandw= idth,=20 while NAS-B does not need the bandwidth.  How should the flag = be=20 set in this case by the AN?  Set to 'Mandatory' for the port u= p=20 messages to NAS-A, and set to 'Optional' for port up messages towar= ds=20 NAS-B? Or is it always set to 'Mandatory'?  From your answer b= elow,=20 I understand that it should be set to 'Optional' towards NAS-B.&nbs= p; Is=20 that correct?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>NAS-B will simply ignore the bandwidth TLV= . =20 If such a flag would exist, and the flag is set to 'Mandatory' by t= he AN=20 to NAS-B, what should be the behavior of NAS-B?  Should it rej= ect=20 the whole message?  Maybe NAS-B is not supporting hierarchical= =20 shaping, so it might not support the bandwidth TLV.  Today, th= e=20 bandwidht TLV is only mandatory to be put in the port up messages, = but=20 for the receiver there is nothing mandatory.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>I believe the original intend of ANCP was = that the=20 AN does not need to know what the NAS is doing with this informatio= n,=20 the use of the bandwidth is also not specified by ANCP, only an exa= mple=20 is given (which is shaping).  In the future there may be=20 applications for which TLVs will be mandatory which are now=20 optional.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Stefaan</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D853253107-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV><BR> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dle= ft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com] <BR><B>Sent:</B> maandag 28 april 2008=20 21:33<BR><B>To:</B> DE CNODDER Stefaan; Busser, M;=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> RE: [ANCP]=20 Mandatory TLVs in draft-ietf-ancp-protocol proposal<BR></FONT><BR><= /DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial size=3D2></FONT>&nbs= p;</DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 = 2px solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3D= left> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> DE CNODDER Stefaan=20 [mailto:stefaan.de_cnodder@alcatel-lucent.be] <BR><B>Sent:</B> 28= =20 April 2008 17:15<BR><B>To:</B> Wojciech Dec (wdec); Busser, M;=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> RE: [ANCP]= =20 Mandatory TLVs in draft-ietf-ancp-protocol=20 proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FON= T=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>Take the bandwi= dth sub-TLV=20 in port up messages as example.  The current protocol spec s= ays=20 that it is mandatory to be sent in port up messages.  t= hat's=20 ok.  But it is not mandatory for the receiver to process the= =20 bandwidth sub-TLV.  What is done with this information by th= e NAS=20 is not specified by ANCP, so you cannot make it mandatory for the= =20 receiver side.<SPAN class=3D163161615-28042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN><= /DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FON= T=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008></SPAN></FONT></FONT></FONT></SPAN>&nb= sp;</DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FON= T=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008><FONT color=3D#000000>Woj> Is the=20 information required by the application? It would appear for the= =20 dynamic shaping use-case to be most certainly so. Hence it is=20 absolutely mandatory, otherwise the message makes no sense for th= e=20 application.</FONT> <FONT color=3D#000000>In any case, if=20 </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FON= T=20 face=3DArial color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FON= T=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>So it looks to = me that the=20 flag can only indicate what the receiver should do.  Then th= e=20 flag makes sense.<SPAN class=3D163161615-28042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN><= /DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FON= T=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008></SPAN></FONT></FONT></FONT></SPAN>&nb= sp;</DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FON= T=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008><FONT color=3D#000000>Woj>=20 </FONT> <FONT color=3D#000000>The flag tells the receiver wh= at info=20 the sender thinks is required to carry out the application. This = in=20 almost all cases has to match up to what the receiver thinks is=20 required. The=20 sender </FONT></SPAN></FONT></FONT></FONT></SPAN><SPAN=20 class=3D436050615-28042008><FONT color=3D#0000ff><FONT face=3DAri= al><FONT=20 size=3D2><SPAN class=3D163161615-28042008><FONT color=3D#000000>d= oesn't tell=20 the receiver what to do with the=20 info.</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FON= T=20 face=3DArial color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FON= T=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>If the receiver= knows what=20 is mandatory, then I do not see a reason why this has to be made= =20 explicit in the protocol.  It would only complicate the=20 protocol.  As already said by Michael: if a mandatory TLV is= not=20 there, then it is just a bug.<SPAN class=3D163161615-28042008><FO= NT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN><= /DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FON= T=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008></SPAN></FONT></FONT></FONT></SPAN>&nb= sp;</DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FON= T=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008><FONT color=3D#000000>Woj> Can you= =20 specifically describe what aspect of the protocol does it=20 complicate?</FONT> <FONT color=3D#000000>It's just making=20 explicitly clear what the protocol already has to implement anywa= y to=20 be of any use.</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FON= T=20 size=3D+0><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008>As to whether it is a bug, having such= =20 explicit marking makes it clear what/where the problem is when=20 observing a messaging flow vs a lot of deduction work. In an= y=20 case, the other point being made here is that today the prot= ocol=20 does NOT specify what should happen if a mandatory TLV is=20 missing.</SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FON= T=20 size=3D+0><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008></SPAN></FONT></FONT></FONT></SPAN>&nb= sp;</DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FON= T=20 size=3D+0><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008>-Woj.</SPAN></FONT></FONT></FONT></SPA= N></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FON= T=20 face=3DArial color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FON= T=20 face=3DArial color=3D#0000ff size=3D2>regards,</FONT></SPAN></DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FON= T=20 face=3DArial color=3D#0000ff size=3D2>Stefaan</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FON= T=20 face=3DArial color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D436050615-28042008><FON= T=20 face=3DArial color=3D#0000ff size=3D2></FONT></SPAN> </DIV><= BR> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3D= left> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com] <BR><B>Sent:</B> maandag 28 april 2008=20 16:28<BR><B>To:</B> DE CNODDER Stefaan; Busser, M;=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> RE: [ANCP]= =20 Mandatory TLVs in draft-ietf-ancp-protocol=20 proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D560491614-28042008><FON= T=20 face=3DArial size=3D2>It's actually a mix of both.=20 Inline...</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #00000= 0 2px solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align= =3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ancp-bounces@ietf.org= =20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>DE CNODDER=20 Stefaan<BR><B>Sent:</B> 28 April 2008 16:04<BR><B>To:</B> Wojci= ech=20 Dec (wdec); Busser, M; ancp@ietf.org<BR><B>Cc:</B> Haag,=20 T<BR><B>Subject:</B> Re: [ANCP] Mandatory TLVs in=20 draft-ietf-ancp-protocol proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff= =20 size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><F= ONT=20 face=3DArial color=3D#0000ff size=3D2>Hi,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><F= ONT=20 face=3DArial color=3D#0000ff size=3D2></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><F= ONT=20 face=3DArial color=3D#0000ff size=3D2>This new mandatory flag, = what is=20 exactly its meaning?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><F= ONT=20 face=3DArial color=3D#0000ff size=3D2></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><F= ONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>(1) if f= lag set to=20 "mandatory", then the *receiver* of this TLV MUST process it, a= nd if=20 unrecognized must drop the message<SPAN=20 class=3D560491614-28042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN= ></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><F= ONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN>&= nbsp;</DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><F= ONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>If a received = TLV is=20 has the "mandatory" flag set then the receiver MUST d= rop=20 the message and report an error to the sender if it doesn'= t=20 recognize the=20 TLV.</FONT> </SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><F= ONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><SPAN class=3D487325113-28042008><FO= NT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>If a the recei= ver=20 expects a "mandatory" TLV but doesn't receive it, the= =20 message MUST be droped and an error report = sent=20 to=20 the sender.</FONT> </SPAN></FONT></FONT></FONT></SPAN= ></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><F= ONT=20 face=3DArial color=3D#0000ff size=3D2></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><F= ONT=20 face=3DArial color=3D#0000ff size=3D2>OR</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><F= ONT=20 face=3DArial color=3D#0000ff size=3D2></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><F= ONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>(2) if f= lag is set=20 to"mandatory", then the *sender* MUST include it in the message= for=20 which it is defined<SPAN class=3D560491614-28042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN= ></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><F= ONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN>&= nbsp;</DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><F= ONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>The sender MUS= T include=20 mandatory TLVs as defined by the=20 protocol-spec/applications.</FONT></SPAN></FONT></FONT></FONT><= /SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><F= ONT=20 face=3DArial color=3D#0000ff size=3D2></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><F= ONT=20 face=3DArial color=3D#0000ff size=3D2>The current protocols dra= ft says for=20 certain TLVs that they are mandatory, but that applies to the s= ender=20 of it (interpretation 2).  The flag would indicate=20 interpretation 1 (like for Radius VSAs?)?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><F= ONT=20 face=3DArial color=3D#0000ff size=3D2></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><F= ONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>If the higher= order bit=20 is set to "0" means that it is mandatory, then currently define= d=20 optional defined TLVs suddenly become mandatory which is not=20 good.<SPAN class=3D560491614-28042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN= ></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><F= ONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN>&= nbsp;</DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><F= ONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>Woj> Only t= he=20 currently used TLVs become mandatory. If they are not=20 used/implemented we can re-define them as optional (set flag to= 1)=20 at no cost. </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><F= ONT=20 face=3DArial color=3D#0000ff size=3D2></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><F= ONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>But I would f= irst to=20 understand the exact meaning of this mandatory flag.  Defi= ning=20 such a flag indeed looks useful but then as interpretation 1, a= nd I=20 would say that if flag set to 1, then it is mandatory and actua= lly,=20 it is possible that a TLV is sent sometimes as optional and=20 sometimes as mandatory.<SPAN class=3D560491614-28042008><FONT=20 color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN= ></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><F= ONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN>&= nbsp;</DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><F= ONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>Woj> Precis= ely, that=20 is possible on a per application basis.</FONT> <FONT=20 color=3D#000000>Having the flag would make troubleshooting of a= =20 message flow much more explicit (today, with any=20 problem one has to browse the drafts to figure out what MU= ST be=20 there vs what SHOULD be there all while looking what = is=20 actually there)</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><F= ONT=20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 size= =3D2><SPAN=20 class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN>&= nbsp;</DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><F= ONT=20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 size= =3D2><SPAN=20 class=3D560491614-28042008>Regards,</SPAN></FONT></FONT></FONT>= </SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><F= ONT=20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 size= =3D2><SPAN=20 class=3D560491614-28042008>Woj.</SPAN></FONT></FONT></FONT></SP= AN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><F= ONT=20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 size= =3D2><SPAN=20 class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN>&= nbsp;</DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><F= ONT=20 face=3DArial color=3D#0000ff size=3D2>regards,</FONT></SPAN></D= IV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D487325113-28042008><F= ONT=20 face=3DArial color=3D#0000ff size=3D2>Stefaan</FONT></SPAN></DI= V> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff= =20 size=3D2></FONT> </DIV><BR> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align= =3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ancp-bounces@ietf.org= =20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>Wojciech Dec= =20 (wdec)<BR><B>Sent:</B> donderdag 24 april 2008 14:19<BR><B>To:<= /B>=20 Busser, M; ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</= B>=20 Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol=20 proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D709295811-24042008><F= ONT=20 face=3DArial size=3D2>Hi Michael,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D709295811-24042008><F= ONT=20 face=3DArial size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D709295811-24042008><F= ONT=20 face=3DArial size=3D2>inline...</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000= 000 2px solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr alig= n=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ancp-bounces@ietf.o= rg=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>Busser,=20 M<BR><B>Sent:</B> 24 April 2008 13:13<BR><B>To:</B>=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> Re: [A= NCP]=20 Mandatory TLVs in draft-ietf-ancp-protocol=20 proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size= =3D2>Hi=20 Woi, all</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size= =3D2>I see=20 the problem but i can not see, how an additional flag will he= lp=20 solving this problem.</FONT></SPAN></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size= =3D2>Lets=20 assume your first proposal.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FON= T=20 size=3D2>If an implementation does not send the=20 complete TLV, even it is defined to=20 be mandatory, I would call this a bug and I ca= n not=20 see, how an additional flag can help here.<SPAN=20 class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN>= </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FON= T=20 size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> = </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FON= T=20 size=3D2><SPAN class=3D709295811-24042008>Woj> The way it = helps,=20 and other protocols bear proof of this scheme, is that it is= =20 easier for implementations to reconcile errors resulting out = of=20 "Mandatory" and "Optional" TLV sets. The key to this lie= s on=20 a per application basis. One application may mandate TLV A fo= r=20 operation, while another might not. Resolving such issues whe= n=20 implementing or troubleshooting multiple applications is not= =20 always trivial. </SPAN></FONT></FONT></SPAN><SPAN=20 class=3D364043506-24042008><FONT face=3DArial><FONT size=3D2>= <SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FON= T=20 size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> = </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size= =3D2>Your=20 second proposal seems obviously be required to keep exis= ting=20 things working, if we agree on your first proposal.= =20 </FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size= =3D2>But=20 from my point of view it also assumes, that all existing= =20 implementations are using the same set of TLVs now.=20 </FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FON= T=20 size=3D2>And I am not sure about that. <SPAN=20 class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN>= </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FON= T=20 size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> = </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FON= T=20 size=3D2><SPAN class=3D709295811-24042008>Woj> This would = be a good=20 thing for the WG to discuss. There most evidently is a fair a= mount=20 of "dead wood" in the current spec, ie stuff that nobody= =20 yet implements or cares about.  In the former case,= we=20 could re-cast that material using the new notions/extensions,= in=20 the latter case simply chop it=20 out.</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size= =3D2><SPAN=20 class=3D364043506-24042008><FONT face=3DArial color=3D#0000ff= =20 size=3D2></FONT></SPAN> </DIV></FONT></SPAN> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FON= T=20 size=3D2>Therefore I disagree with your first proposal. I rec= ommend,=20 the better way will be to be more precise in=20 definitions.<SPAN=20 class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN>= </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size= =3D2>In my=20 mind, it is a bug, if a mandatory TLV is missing. It is up to= the=20 robustness of the implementation to deal with this=20 situation.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FON= T=20 size=3D2>Is it really neccesary to define the behavior of a n= etwork=20 element in this case of failure in the ancp protocol=20 itself? <SPAN=20 class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN>= </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FON= T=20 size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> = </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FON= T=20 size=3D2><SPAN class=3D709295811-24042008>Woj> Other peopl= e have=20 faced this problem before, and I would rather go with the les= sons=20 they learned, rather than clinging to hopes of perfect textua= l=20 definitions and implementations. Other than backwards=20 compatibility, I do not see in your statements a valid=20 reason to object to the 1st proposal, particularly = for=20 new applications since it can only make things more robust. T= he=20 counter argument of being precise in the definitions, as evid= enced=20 by the current spec, is admirable and needs to be there, with= this=20 proposal providing an extra level of robustness and visibilit= y of=20 any problems. </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FON= T=20 size=3D2><SPAN=20 class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> = </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FON= T=20 size=3D2><SPAN=20 class=3D709295811-24042008>Thanks,</SPAN></FONT></FONT></SPAN= ></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial><FON= T=20 size=3D2><SPAN=20 class=3D709295811-24042008>Woj.</SPAN></FONT></FONT></SPAN></= DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size= =3D2>If=20 optional TLVs are not present in a message, we should describ= e=20 some kind of default behaviour, as you already=20 stated.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size= =3D2> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2>Comments on=20 draft-ietf-ancp-protocol-02.txt:</FONT></SPAN></DIV></FONT></= SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT=20 face=3DArial>It is not clearly stated, if the TLV  = "<SPAN=20 lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; mso= -fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fare= ast-language: DE; mso-bidi-language: AR-SA">DSL=20 Line Attributes "<FONT face=3DArial> is mandatory or optional= .=20 </FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT=20 face=3DArial><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; mso= -fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fare= ast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>In fact it is mandatory because some of its SubT= LVs are=20 mandatory. </FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2><FONT=20 face=3DArial><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; mso= -fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fare= ast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>We should spent a sentence to make this=20 clear.</FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size= =3D2><SPAN=20 class=3D364043506-24042008><FONT size=3D2><FONT face=3DArial>= It is not=20 clearly stated, if the TLV  "<SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; mso= -fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fare= ast-language: DE; mso-bidi-language: AR-SA">Service-Profile-Name"<FONT=20 face=3DArial> is mandatory or=20 optional.</FONT></SPAN></FONT></FONT></SPAN></FONT></SPAN></D= IV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size= =3D2><SPAN=20 class=3D364043506-24042008><FONT size=3D2><FONT face=3DArial>= <SPAN=20 lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; mso= -fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fare= ast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>I prefer mandatory because it is essetial for th= e use=20 case Line=20 Config. </FONT></SPAN></FONT></FONT></SPAN></DIV></FONT>= </SPAN><SPAN=20 class=3D364043506-24042008><FONT face=3DArial size=3D2></FONT= ></SPAN> <DIV><SPAN class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2>Section 5.4.3 Line Config, where the TLVs are mentio= ned=20 (page 35):</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size= =3D2> =20 ...defined in section 5.4.1....    must be=20 corrected to    ...defined in section=20 5.4.2........</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2>Section 5.4.4 OAM, where the TLVs are mentioned= (page=20 36 and page 38):</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial size= =3D2> =20 ...defined in section 5.4.1....    must be=20 corrected to    ...defined in section=20 5.4.2........</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV></FONT></SPAN><SPAN class=3D364043506-24042008><FONT fac= e=3DArial=20 size=3D2></FONT></SPAN> </DIV></DIV> <DIV><SPAN class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008><FONT face=3DArial color=3D#0000ff= =20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial colo= r=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV align=3Dleft><FONT color=3D#000080 size=3D2> <P align=3Dleft>Best Regards; Freundliche Gr=FC=DFe </P></FON= T><B><FONT=20 color=3D#000080> <P>Michael Busser</P></B></FONT><FONT size=3D1> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: 169= "=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt">T-Systems Enterprise Services GmbH=20 </SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: 169= "=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT size=3D1>Production Line Netwo= rk=20 Centric Systems</FONT></SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: 169= "=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT size=3D1>ICT-Systems=20 Integration</FONT></SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: 169= "=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT size=3D1>Network Integration=20 Services</FONT></SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: 169= "=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT size=3D1></FONT><SPAN=20 style=3D"COLOR: navy"></SPAN><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy"><FONT face=3DArial=20 color=3D#000000 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: 169= "=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy"><FONT color=3D#000000= =20 size=3D1>Br=FCckes 2 -8, 55545 Bad Kreuznach<BR>Postfach 9100= , 55541=20 Bad Kreuznach<BR>+49 671 8333 8911 (Phone)<BR>+49=20 521 9210 3859 (Fax)<BR>+49 151 1211 9689=20 (Mobile)<BR>E-Mail: <A=20 href=3D"mailto:michael.busser@t-systems.com">michael.busser@t= -systems.com</A></FONT></SPAN></DIV></SPAN> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: 169= "=20 align=3Dleft v:shape=3D"_x0000_s1026"> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; mso-margin-left-alt: 169= "=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN></DIV><SPAN=20 style=3D"FONT-SIZE: 8pt">Internet: </SPAN><SPAN=20 style=3D"FONT-SIZE: 8pt"><p:onmouseclick hyperlinktype=3D"url= "=20 href=3D"http://www.t-systems.com/"></p:onmouseclick><A=20 onclick=3Dwindow.event.cancelBubble=3Dtrue;=20 href=3D"http://www.t-systems.com/" target=3D_parent><FONT=20 color=3D#6699ff>http://www.t-systems.com</FONT></A></SPAN><SP= AN=20 style=3D"FONT-SIZE: 8pt"> </SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '90 0 50'; mso-margin-left-alt: 16= 9"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '90 0 50'; mso-margin-left-alt: 16= 9"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN> </DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '90 0 50'; mso-margin-left-alt: 16= 9"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT size=3D3><FONT size=3D1><SPAN= =20 style=3D"FONT-SIZE: 7.5pt; COLOR: black; FONT-FAMILY: Arial">= T-Systems=20 Enterprise Services GmbH<BR>Aufsichtsrat: Ren=E9 Obermann=20 (Vorsitzender)<BR>Executive Committee: Reinhard Clemens=20 (Vorsitzender)*, Helmut Binder, Albert Henn, Olaf Heyden*, Ka= trin=20 Horstmann, Ulrich Kemp, Wilfried Peters*,<BR>Dr. Herbert Scha= aff*,=20 Zvezdana Seeger*<BR>Handelsregister: Amtsgericht Frankfurt am= Main=20 HRB 55933<BR>Sitz der Gesellschaft: Frankfurt am=20 Main<BR>WEEE-Reg.-Nr. DE87523644<BR>*Gesch=E4ftsf=FChrer gem.= =A7 35=20 GmbHG</SPAN></FONT></FONT></SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '90 0 50'; mso-margin-left-alt: 16= 9"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"><SPAN style=3D"FONT-SIZE: 8pt"><FONT= =20 face=3DArial size=3D2></FONT></SPAN></SPAN> </DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '90 0 50'; mso-margin-left-alt: 16= 9"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"><SPAN style=3D"FONT-SIZE: 8pt"><FONT= =20 size=3D1>Notice: This transmittal and/or attachments may be=20 privileged or confidential. If you are not the intended recip= ient,=20 you are hereby notified that you have received this transmitt= al in=20 error; any review, dissemination, or copying is strictly=20 prohibited. If you received this transmittal in error, please= =20 notify us immediately by reply and immediately delete this me= ssage=20 and all its attachments. Thank you. </FONT><FONT=20 size=3D1><BR>T-Systems =96 Business flexibility=20 </FONT></DIV></SPAN></SPAN> <DIV><FONT face=3DArial size=3D2></FONT> </DIV></FONT></= DIV> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"> <DIV></DIV> <DIV class=3DOutlookMessageHeader lang=3Dde dir=3Dltr align= =3Dleft> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size= =3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">= <o:p></o:p></SPAN></FONT></P><FONT=20 face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"><FONT face=3DArial size=3D2></FON= T> <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2> </SPAN></FONT></DIV> <DIV class=3DSection1> <DIV> <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN= =20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: T= ahoma">Von:</SPAN></FONT></B><FONT=20 face=3DTahoma size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">=20 ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] <B><SP= AN=20 style=3D"FONT-WEIGHT: bold">Im Auftrag von </SPAN></B>Wojci= ech Dec=20 (wdec)<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Gesendet:</SPAN></B> Mittwoch, = 23.=20 April 2008 14:54<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">An:</SPAN></B>=20 ancp@ietf.org<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Betreff:</SPAN></B> [ANCP] Mand= atory=20 TLVs in draft-ietf-ancp-protocol=20 proposal</SPAN></FONT><o:p></o:p></P></DIV> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D= 3><SPAN=20 style=3D"FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></= P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi=20 All,</SPAN></FONT><SPAN lang=3DEN-GB> </SPAN><o:p></o:p></P= > <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Continuing wi= th the=20 series of e-mails regarding basic protocol issues still to = be=20 addressed, I now would now like to ask your feedback regard= ing=20 the distinction the protocol places on mandatory TLVs. Give= n the=20 length of this mail I'll first cut to the proposal, and aft= er it=20 you can find the problem=20 description.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The proposal = which I=20 am putting in front of the WG is to define a new TLV format= =20 which contains at a minimum a Mandatory flag (much like Rad= ius=20 VSAs do). We could have this TLV Flag be defined only for n= ew=20 applications.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">A second prop= osal=20 would be try to make this flag work with existing ones by f= or=20 example defining the highest order bit of the TLV# field to= mean=20 "Mandatory" when set to "0". This would be invisible to exi= ting=20 implementations, but newer ones may have problems in=20 communicating with older ones when the latter do not send a= ll=20 TLVs. But that can also be addressed by simply forming the = set=20 of mandatory TLVs to be the ones that all implementations=20 currently send by default.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Without addit= ional=20 feedback, I will assume that the WG is fine with the first= =20 proposal, and also with the 2nd one conditional on deriving= a=20 suitable "commonly used" TLV set.</SPAN></FONT><o:p></o:p><= /P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The problem i= n more=20 detail: </SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Currently the= =20 situation is that Mandatory TLVs are only stated to be as s= uch=20 in the body of the protocol draft spec, with an implementer= =20 having to scour fairly attentively the text. Eg "Type=20 (Access-Loop-Circuit-ID =3D 0x01): This is a mandatory TLV"= ,=20 etc.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The behaviour= of an=20 implementation that receives a message with a missing manda= tory=20 TLV is not defined at all, and the opposite is handled but = not=20 very robustly, i.e. when receiving a TLV but not recognizin= g it,=20 and implementation is free to discard it (even if it is=20 mandatory!). This is a recipe for interoperability problems= and=20 an implementation mine field.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">This problem = is=20 complicated by different applications. For example the curr= ent=20 OAM section states the following regarding TLVs that are to= be=20 carried in the request message (my=20 italics):</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">"</SPAN></FON= T>=20 <BR><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN= lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Couri= er New'">Following=20 TLVs<B><I><SPAN style=3D"FONT-WEIGHT: bold; FONT-STYLE: ita= lic">=20 can</SPAN></I></B> appear in this message:=20 </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Couri= er New'">      =20 o Type (Access-Loop-Circuit-ID =3D 0x01) : defined in secti= on=20 5.4.1    </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Couri= er New'">      =20 o Type (Access-Aggregation-Circuit-ID-Binary =3D 0x06): def= ined in=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack= =20 size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Couri= er New'">        =20 section 5.4.1. </SPAN></FONT><BR><FONT face=3D"Courier New"= =20 color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Couri= er New'"> </SPAN></FONT>=20 <BR><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN= lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Couri= er New'">      =20 o Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03): defi= ned in=20 section </SPAN></FONT><BR><FONT face=3D"Courier New" color= =3Dblack=20 size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Couri= er New'">        =20 5.4.1.  </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Couri= er New'">      =20 o Type (OAM-Loopback-Test-Parameters =3D 0x07): Parameters = related=20 to  </SPAN></FONT><BR><FONT face=3D"Courier New" color= =3Dblack=20 size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Couri= er New'">        =20 loopback test. This is an optional TLV. If this TLV is not= =20 present </SPAN></FONT><BR><FONT face=3D"Courier New" color= =3Dblack=20 size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Couri= er New'">        =20 in the request message, the DSLAM SHOULD use locally determ= ined=20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack= =20 size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Couri= er New'">        =20 default values for the test parameters. =20 </SPAN></FONT><BR><FONT face=3D"Courier New" color=3Dblack= =20 size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Couri= er New'">"</SPAN></FONT>=20 <BR><FONT face=3DArial color=3Dblack size=3D2><SPAN lang=3D= EN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial"= >(NOTE:=20 The last "SHOULD" appears to be inappropriate. If the TLV i= s=20 missing, the DSLAM MUST have some default parameters, or re= turn=20 an error)</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial color=3Dblack size=3D2><SPAN lang=3DE= N-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial"= >The=20 "can" above indicates that they're all optional, while clea= rly=20 the application cannot run its course without one or more o= f=20 these fields. Here we have a case where one could have a=20 perfectly compliant implementation that ignores all these=20 TLVs=85</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial color=3Dblack size=3D2><SPAN lang=3DE= N-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial"= >-Woj.</SPAN></FONT><SPAN=20 lang=3DEN-US> </SPAN><o:p></o:p></P> <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><FONT=20 face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"><BR><BR><BR><BR><BR><BR><BR><BR><= BR><BR><o:p></o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCK= QUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BO= DY></HTML> --_000_48C276B536524E478C659685995F6AA539DBB4F25FRBSJXadredbac_-- --===============1047510450== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============1047510450==-- From ancp-bounces@ietf.org Tue Apr 29 12:04:55 2008 Return-Path: <ancp-bounces@ietf.org> X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71E3F28C2B1; Tue, 29 Apr 2008 12:04:55 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0249D3A6AD8 for <ancp@core3.amsl.com>; Tue, 29 Apr 2008 12:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHNfLftbicqX for <ancp@core3.amsl.com>; Tue, 29 Apr 2008 12:04:35 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0C87F3A6EEB for <ancp@ietf.org>; Tue, 29 Apr 2008 12:03:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,723,1199660400"; d="scan'208,217";a="7654470" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 29 Apr 2008 21:03:35 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3TJ3ZmH031739; Tue, 29 Apr 2008 21:03:35 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3TJ3Zbg006756; Tue, 29 Apr 2008 19:03:35 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Apr 2008 21:03:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Apr 2008 21:03:28 +0200 Message-ID: <D9872168DBD43A41BD71FFC4713274D404FF1751@xmb-ams-33b.emea.cisco.com> In-Reply-To: <48C276B536524E478C659685995F6AA539DBB4F25F@RBSJX.ad.redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal thread-index: AcilQRMfK4kdawUKQOWs5fdBngS8QQAAr04QACRhApAAC0ujAADNHRywAADiEXAAAbhxoAAAWwcQACIOoKAAAXsqYAASvbCgAAE4sjAAASS6UAABRQpQ References: <1B6169C658325341A3B8066E23919E1C01230DC1@S4DE8PSAANK.mitte.t-com.de><1B6169C658325341A3B8066E23919E1CFBC5C4@S4DE8PSAANK.mitte.t-com.de><D9872168DBD43A41BD71FFC4713274D404FA6ACC@xmb-ams-33b.emea.cisco.com><7A6D4815C5E8F74988784FEBD50F2F1E01ABAA16@FRVELSMBS22.ad2.ad.alcatel.com><D9872168DBD43A41BD71FFC4713274D404FF10C1@xmb-ams-33b.emea.cisco.com><7A6D4815C5E8F74988784FEBD50F2F1E01ABAAA4@FRVELSMBS22.ad2.ad.alcatel.com><D9872168DBD43A41BD71FFC4713274D404FF1233@xmb-ams-33b.emea.cisco.com><7A6D4815C5E8F74988784FEBD50F2F1E01ABAC34@FRVELSMBS22.ad2.ad.alcatel.com><D9872168DBD43A41BD71FFC4713274D404FF13AD@xmb-ams-33b.emea.cisco.com><48C276B536524E478C659685995F6AA539DBB4F194@RBSJX.ad.redback.com><D9872168DBD43A41BD71FFC4713274D404FF172D@xmb-ams-33b.emea.cisco.com> <48C276B536524E478C659685995F6AA539DBB4F25F@RBSJX.ad.redback.com> From: "Wojciech Dec (wdec)" <wdec@cisco.com> To: "Peter Arberg" <parberg@redback.com>, "DE CNODDER Stefaan" <stefaan.de_cnodder@alcatel-lucent.be>, "Busser, M" <Michael.Busser@t-systems.com>, <ancp@ietf.org> X-OriginalArrivalTime: 29 Apr 2008 19:03:35.0769 (UTC) FILETIME=[B9CE7490:01C8AA2B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=144085; t=1209495815; x=1210359815; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20<wdec@cisco.com> |Subject:=20RE=3A=20[ANCP]=20Mandatory=20TLVs=20in=20draft- ietf-ancp-protocol=20proposal |Sender:=20; bh=L0G9toZQ/c9dpBGtHkBwcdLZsz0nIe8k5FI9AIgJ0HY=; b=DtYfwSsn+Q+J71nAofMJdR9fZZnuGrf/1TzBnc20xmiLiHIc1kpnuxOQGk rtmclvyaIeUA4slfHclppUoyofpYN0ObCLiw/kDCZVg96M+A++u12rZueIDy BYFJIttp/h; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: "Haag, T" <Thomas.Haag@t-systems.com> Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list <ancp.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/ancp> List-Post: <mailto:ancp@ietf.org> List-Help: <mailto:ancp-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1709113559==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1709113559== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8AA2B.B969F0C3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8AA2B.B969F0C3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Peter, =20 continued inline... ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = Peter Arberg Sent: 29 April 2008 20:39 To: Wojciech Dec (wdec); DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal =09 =09 Hi Woj, =20 please see inline in your answers =20 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: 29. april 2008 11:07 To: Peter Arberg; DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 Hi Peter, =20 =20 ________________________________ From: Peter Arberg [mailto:parberg@redback.com]=20 Sent: 29 April 2008 19:34 To: Wojciech Dec (wdec); DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 Hi Woj, =20 I agree with Michael and Stefan on this issue, I do not see a need to = change the existing implementation with a mandatory/optional flag.=20 =20 Woj> Please indicate where in my proposal did you see anything about = changing existing implementaions? =20 =20 PAR> I might have misunderstood your email, but I read it as if you = suggest a high bit value in existing TLV's to be interpreted as a mandatory flag.=20 =20 Woj#2> Yes, I suggested (in proposal 2) that *if* the WG found there to = be a common set of TLVs currently in use, then the high-order bit set to = "0" (ie as today) could be interpreted as "mandatory", and the rest of = the TLV's redefined with a high order "1". To extsing implementations, = the "new" TLVs would just look like a different TLV#, while anyone = wishing to implement the more robust error cheking logic based on this = bit, would be free to do so.=20 =20 If you are simply talking about new capability type definitions, then = why do you not bring up the additional flag in a new internet-draft defining what capability = type you have in mind ?=20 =20 Woj#2> No, a new capability was not intended, but could also be = considered. =20 =20 I think I understand your arguments, but I do not agree with them. I = think most places in the draft it is clear what is defined as mandatory and optional.=20 =20 I agree on the point we need to go through the draft and make = clarifications to what TLV's in what capability types are mandatory and optional, and make more = description what should happen if mandatory TLVs are not included.=20 =20 Woj> Exactly.=20 =20 I think the DSLF TR-101 document has a good example of such a = description in it's=20 "Table 3 - Access loop characteristics sub-options", and I think if = we do the same for each capability types TLV's in the ANCP draft it will be a good help. =20 Woj> Indeed, pre-ceeded by some rationalization. The appears to be no = reason for some of the DSLF "mandatory" TLVs.=20 =20 PAR> I do not see a problem with re-visit in the draft if a TLV should = be optional or mandatory, so if that is the intend, then I'm all for an email discussion on a TLV by = TLV basis if we think it is a=20 manfdatory or optional information inside the specific capability type. = =20 Woj#2> Great, because any change to the mandated set *will* affect = existing implementation . =20 =20 =20 I do not agree with your point that it is not listed if "rate" is = mandatory or optional, it is clearly listed as a mandatory TLV, and as such it should be included in the = port up message, I really do not understand what confusion you have with this.=20 =20 Woj> The text states: =20 =20 5. Type (DSL Line Attributes =3D 0x04):=20 Length : variable (up to 1024 bytes)=20 Value : This consists of one or more Sub-TLVs corresponding to DSL=20 line attributes. No sub-TLVs other than the "DSL type" and "DSL=20 line state" SHOULD be included in a PORT DOWN message.=20 The general format of the sub-TLVs is identical to the general TLV=20 format. The value field in each sub-TLV is padded to a 4-octet=20 alignment. The Length field in each sub-TLV contains the actual=20 number of bytes in the TLV (not including the padding if present).=20 Current defined sub-TLV types are start from 0x81. =20 Maybe you can point me to where exatly it is stated clearly as being = mandatory, or otherwise explain why you "not agree"? =20 =20 PAR> I think you forgot to read the most important part where the = actual TLV is defined.=20 =20 Woj#2> I didn't. This part talks about the sub-TLV, not the main TLV = 0x04. Do you see my point now? =20 =20 Type (Actual-Net-Data-Upstream =3D 0x81): Actual upstream net data rate = on a DSL line.=20 This is a mandatory TLV. =20 =20 Length : (4 bytes)=20 Value : (Rate in Kb/sec)=20 =20 Type (Actual-Net-Data-Rate-Downstream =3D 0x82) : Actual downstream net = data rate on a DSL line.=20 This is a mandatory TLV.=20 =20 Length : (4 bytes)=20 Value : (Rate in Kb/sec)=20 =20 =09 =20 The fact you say "Port UP" and "OAM" is best considered as legacy = applications, I have some trouble with this as well, since ANCP running in production networks = use them, and as such it is a central part of the ANCP specifications we need to finish as = soon as possible.=20 =20 Woj> I should have said legacy applications from a protocol messaging = perspective, not usage, nor support. It's quite clear that GSMP derived = messaging has baggage that is un called for in new applications. =20 I think Stefaan's example is very valid, that we do not need to make = mandatory requirements to=20 what receivers of ANCP information use such info. for. I don't think = we should try and make the ANCP specifications "mandatory" for box behavior, I think it is much = more important for the=20 working group to make the protocol specifications easy to understand = and get the first documentation finish and published, so the protocol can be used for different sets = of applications, and make sure new applications can be added later.=20 =20 Woj> Indeed the aim of the WG to define a protocol that is relatively = simple and easy to understand, not just to implementers but also to = people using it, and across vendors. Currently, having anyone operating = the device be familiar in what cases a TLV is mandatory and in what = optional requires a thorough understanding of the spec, across = applications. This is not easy, but I'll conceede that for the = applications implemented so far we could live with it.=20 =20 I do think that by documenting if a TLV is mandatory or optional = inside a specific capability type, it is easy to understand what must be sent to support the defined = application/capability type.=20 =20 Woj> Of course it is, the whole spec is about this. The problem comes = when people start to re-use well known TLVs for different applications, = and then trying to make sense of it all becomes non-trivial. Why do you = think both BGP and Diamater, and a number of other protocols have = definied "Mandatory" flags? Just for kicks? It's a well known protocol = design tool, that comes handy when re-using same data across multiple = applications.=20 =20 PAR> I might be wrong, but I think I can find as many or more protocol = examples who do not include a mandatory/optional flag, so examples can always be found which will = support the point you are trying to make. =20 I do not see a problem with a new internet-draft which defines new = capability-types and where a TLV mandatory flag is included, I do see a problem if the intend is to try = and adjust what already exist. =20 =20 Woj#2> Ok, so if adjusting is only scoped to what doesn't exist, as my = proposal laid out conditionally, you're fine. =20 =20 =20 Then if anybody want to include new capability types or sub-TLVs = later to address specific applications, then I think changes can be discussed at that time instead of trying = to change existing protocol implementations.=20 =20 Woj> Again I ask, where in the proposal did you see *anything* = requiring a change to an existing implementation. Please be specific. I = see that your main objection is on this issue, which means that you = accept proposal 1 (have such a flag for new TLVs/apps). It would also be useful if you indicated whether the list of TLVs = provided below is what you'd expect to be the minimum mandatory set.=20 =20 PAR> at the moment I read the draft as having defined the TLVs = mandatory as you describe, except I also read it as the dsl-type =3D 0x91 must be part of the port down. = If this is needed or not is a different discussion. =20 =20 Woj#2> Ok. Thanks. But please do come back to me if you see that the = proposal impacts an exiting implementation. I conclude that there is no = problem with doing changes to stuff that isn't currently used. Woj. =20 cheers, Peter=20 =20 Cheers, Woj. =20 cheers, Peter =20 =20 =20 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = Of Wojciech Dec (wdec) Sent: 29. april 2008 02:28 To: DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 Stefaan, =20 a number of points: 1. There currently is to my knowledge no implementation of ANCP = there that doesn't send the DSL Line attributes info by default in = Port-UP messages? The support of HS on the NAS is an orthogonal issue. 2. The current ancp protocol draft (02) doesn't say whether the rate = info is optional or mandatory, it only states that the sub-TLVs are = mandatory. Based on this, an implementer can be justified to expect = port-ups to *always* have the rate-info tlv (ie treat them as = mandatory). Equally, she's justified in considering this as optional. 3. The port-up and OAM are best considered as legacy applications = for ANCP. The re-use of any of the GSMP defined fields is already out of = the question due to constrains put in place by the existing use-case = messaging. Needless to say, this wasn't as thoroughly designed as it = should have been, and with the OAM and port-up apps being coupled. 4. It's up to the application to define what TLVs are mandatory and = which aren't, as you also state. The AN does not need to know what the = NAS will do with the info, BUT it needs to send the right TLVs for the = application (eg if we had a hypothetical AN that only sends Port-up's = with line-id, it would be next to useless for the dynamic shaping = application). =20 With all this in mind it's useful to re-read what I proposed = originally below regarding the mandatory flag: 1. "have this TLV Flag be = defined only for new applications" and 2. The notion of the mandatory = flag applying to existing TLVs being "conditional on deriving a = suitable "commonly used" TLV set." The latter point would ensure that = existing implementations do not need to change, but future ones can take = advantage of the extra robustness. =20 Hence, can the WG derive a set of commonly used, i.e. always used, = TLVs for existing implementations? The list I came up is as follows (making them pretty much mandatory = TLVs if it agrees with the views of others); =20 Port-up message (0x80); Extension-TLV (dsl tech type) Access-Loop-circuit-id (0x01) DSL Line Attribute (0x04) with the following sub TLVs; DSL-Type =3D 0x91; Actual-Net-Data-Upstream =3D 0x81; = Actual-Net-Data-Rate-Downstream =3D 0x82 =20 Port-down message (0x81); Extension TLV (dsl tech type) Access-Loop-circuit-id (0x01) DSL Line Attribute (0x04) with the following sub TLVs; DSL line state =3D 0x8F =20 All other TLVs are optional. =20 Would appreciate confirmation from the WG regarding the above. =20 Thanks, Woj. =20 ________________________________ From: DE CNODDER Stefaan = [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Sent: 29 April 2008 09:52 To: Wojciech Dec (wdec); Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 =20 Hi Woj, =20 Take the following example: I have a network with 2 NASses, NAS-A = is doing hierarchical shaping, NAS-B just wants to have the port = information but is not doing hierarchical shaping (it is doing other = things like OAM, ...). This means NAS-A needs the bandwidth, while = NAS-B does not need the bandwidth. How should the flag be set in this = case by the AN? Set to 'Mandatory' for the port up messages to NAS-A, = and set to 'Optional' for port up messages towards NAS-B? Or is it = always set to 'Mandatory'? From your answer below, I understand that it = should be set to 'Optional' towards NAS-B. Is that correct? =20 NAS-B will simply ignore the bandwidth TLV. If such a flag would = exist, and the flag is set to 'Mandatory' by the AN to NAS-B, what = should be the behavior of NAS-B? Should it reject the whole message? = Maybe NAS-B is not supporting hierarchical shaping, so it might not = support the bandwidth TLV. Today, the bandwidht TLV is only mandatory = to be put in the port up messages, but for the receiver there is nothing = mandatory. =20 I believe the original intend of ANCP was that the AN does not need = to know what the NAS is doing with this information, the use of the = bandwidth is also not specified by ANCP, only an example is given (which = is shaping). In the future there may be applications for which TLVs = will be mandatory which are now optional. =20 regards, Stefaan =20 =20 =20 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: maandag 28 april 2008 21:33 To: DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 =20 ________________________________ From: DE CNODDER Stefaan = [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Sent: 28 April 2008 17:15 To: Wojciech Dec (wdec); Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 =20 Take the bandwidth sub-TLV in port up messages as example. The = current protocol spec says that it is mandatory to be sent in port up = messages. that's ok. But it is not mandatory for the receiver to = process the bandwidth sub-TLV. What is done with this information by = the NAS is not specified by ANCP, so you cannot make it mandatory for = the receiver side.=20 =20 Woj> Is the information required by the application? It would = appear for the dynamic shaping use-case to be most certainly so. Hence = it is absolutely mandatory, otherwise the message makes no sense for the = application. In any case, if=20 =20 So it looks to me that the flag can only indicate what the receiver = should do. Then the flag makes sense.=20 =20 Woj> The flag tells the receiver what info the sender thinks is = required to carry out the application. This in almost all cases has to = match up to what the receiver thinks is required. The sender doesn't = tell the receiver what to do with the info. =20 If the receiver knows what is mandatory, then I do not see a reason = why this has to be made explicit in the protocol. It would only = complicate the protocol. As already said by Michael: if a mandatory TLV = is not there, then it is just a bug.=20 =20 Woj> Can you specifically describe what aspect of the protocol does = it complicate? It's just making explicitly clear what the protocol = already has to implement anyway to be of any use. As to whether it is a bug, having such explicit marking makes it = clear what/where the problem is when observing a messaging flow vs a lot = of deduction work. In any case, the other point being made here is that = today the protocol does NOT specify what should happen if a mandatory = TLV is missing. =20 -Woj. =20 regards, Stefaan =20 =20 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: maandag 28 april 2008 16:28 To: DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 It's actually a mix of both. Inline... ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On = Behalf Of DE CNODDER Stefaan Sent: 28 April 2008 16:04 To: Wojciech Dec (wdec); Busser, M; ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 =20 Hi, =20 This new mandatory flag, what is exactly its meaning? =20 (1) if flag set to "mandatory", then the *receiver* of this TLV = MUST process it, and if unrecognized must drop the message=20 =20 If a received TLV is has the "mandatory" flag set then the receiver = MUST drop the message and report an error to the sender if it doesn't = recognize the TLV.=20 If a the receiver expects a "mandatory" TLV but doesn't receive it, = the message MUST be droped and an error report sent to the sender.=20 =20 OR =20 (2) if flag is set to"mandatory", then the *sender* MUST include it = in the message for which it is defined=20 =20 The sender MUST include mandatory TLVs as defined by the = protocol-spec/applications. =20 The current protocols draft says for certain TLVs that they are = mandatory, but that applies to the sender of it (interpretation 2). The = flag would indicate interpretation 1 (like for Radius VSAs?)? =20 If the higher order bit is set to "0" means that it is mandatory, = then currently defined optional defined TLVs suddenly become mandatory = which is not good.=20 =20 Woj> Only the currently used TLVs become mandatory. If they are not = used/implemented we can re-define them as optional (set flag to 1) at no = cost.=20 =20 But I would first to understand the exact meaning of this mandatory = flag. Defining such a flag indeed looks useful but then as = interpretation 1, and I would say that if flag set to 1, then it is = mandatory and actually, it is possible that a TLV is sent sometimes as = optional and sometimes as mandatory.=20 =20 Woj> Precisely, that is possible on a per application basis. Having = the flag would make troubleshooting of a message flow much more explicit = (today, with any problem one has to browse the drafts to figure out what = MUST be there vs what SHOULD be there all while looking what is actually = there) =20 Regards, Woj. =20 regards, Stefaan =20 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On = Behalf Of Wojciech Dec (wdec) Sent: donderdag 24 april 2008 14:19 To: Busser, M; ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 Hi Michael, =20 inline... ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On = Behalf Of Busser, M Sent: 24 April 2008 13:13 To: ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =09 =09 Hi Woi, all =20 I see the problem but i can not see, how an additional flag will = help solving this problem. =20 Lets assume your first proposal. If an implementation does not send the complete TLV, even it is = defined to be mandatory, I would call this a bug and I can not see, how = an additional flag can help here.=20 =20 Woj> The way it helps, and other protocols bear proof of this = scheme, is that it is easier for implementations to reconcile errors = resulting out of "Mandatory" and "Optional" TLV sets. The key to this = lies on a per application basis. One application may mandate TLV A for = operation, while another might not. Resolving such issues when = implementing or troubleshooting multiple applications is not always = trivial.=20 =20 Your second proposal seems obviously be required to keep existing = things working, if we agree on your first proposal.=20 But from my point of view it also assumes, that all existing = implementations are using the same set of TLVs now.=20 And I am not sure about that. =20 =20 Woj> This would be a good thing for the WG to discuss. There most = evidently is a fair amount of "dead wood" in the current spec, ie stuff = that nobody yet implements or cares about. In the former case, we could = re-cast that material using the new notions/extensions, in the latter = case simply chop it out. =20 Therefore I disagree with your first proposal. I recommend, the = better way will be to be more precise in definitions.=20 In my mind, it is a bug, if a mandatory TLV is missing. It is up to = the robustness of the implementation to deal with this situation. Is it really neccesary to define the behavior of a network element = in this case of failure in the ancp protocol itself? =20 =20 Woj> Other people have faced this problem before, and I would = rather go with the lessons they learned, rather than clinging to hopes = of perfect textual definitions and implementations. Other than backwards = compatibility, I do not see in your statements a valid reason to object = to the 1st proposal, particularly for new applications since it can only = make things more robust. The counter argument of being precise in the = definitions, as evidenced by the current spec, is admirable and needs to = be there, with this proposal providing an extra level of robustness and = visibility of any problems.=20 =20 Thanks, Woj. =20 If optional TLVs are not present in a message, we should describe = some kind of default behaviour, as you already stated. =20 =20 =20 =20 =09 Comments on draft-ietf-ancp-protocol-02.txt: =20 It is not clearly stated, if the TLV "DSL Line Attributes " is = mandatory or optional.=20 In fact it is mandatory because some of its SubTLVs are mandatory.=20 We should spent a sentence to make this clear. =20 It is not clearly stated, if the TLV "Service-Profile-Name" is = mandatory or optional. I prefer mandatory because it is essetial for the use case Line = Config.=20 =09 =20 Section 5.4.3 Line Config, where the TLVs are mentioned (page 35): ...defined in section 5.4.1.... must be corrected to = ...defined in section 5.4.2........ =20 =09 Section 5.4.4 OAM, where the TLVs are mentioned (page 36 and page = 38): ...defined in section 5.4.1.... must be corrected to = ...defined in section 5.4.2........ =20 =20 =20 =20 Best Regards; Freundliche Gr=FC=DFe=20 Michael Busser =09 T-Systems Enterprise Services GmbH=20 Production Line Network Centric Systems ICT-Systems Integration Network Integration Services =20 Br=FCckes 2 -8, 55545 Bad Kreuznach Postfach 9100, 55541 Bad Kreuznach +49 671 8333 8911 (Phone) +49 521 9210 3859 (Fax) +49 151 1211 9689 (Mobile) E-Mail: michael.busser@t-systems.com =09 Internet: http://www.t-systems.com <http://www.t-systems.com/> =20 =09 =20 T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Reinhard Clemens (Vorsitzender)*, Helmut = Binder, Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, = Wilfried Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG =20 Notice: This transmittal and/or attachments may be privileged or = confidential. If you are not the intended recipient, you are hereby = notified that you have received this transmittal in error; any review, = dissemination, or copying is strictly prohibited. If you received this = transmittal in error, please notify us immediately by reply and = immediately delete this message and all its attachments. Thank you.=20 T-Systems - Business flexibility=20 =20 =09 =09 ________________________________ Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im = Auftrag von Wojciech Dec (wdec) Gesendet: Mittwoch, 23. April 2008 14:54 An: ancp@ietf.org Betreff: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal =20 Hi All,=20 Continuing with the series of e-mails regarding basic protocol = issues still to be addressed, I now would now like to ask your feedback = regarding the distinction the protocol places on mandatory TLVs. Given = the length of this mail I'll first cut to the proposal, and after it you = can find the problem description. The proposal which I am putting in front of the WG is to define a = new TLV format which contains at a minimum a Mandatory flag (much like = Radius VSAs do). We could have this TLV Flag be defined only for new = applications. A second proposal would be try to make this flag work with existing = ones by for example defining the highest order bit of the TLV# field to = mean "Mandatory" when set to "0". This would be invisible to exiting = implementations, but newer ones may have problems in communicating with = older ones when the latter do not send all TLVs. But that can also be = addressed by simply forming the set of mandatory TLVs to be the ones = that all implementations currently send by default. Without additional feedback, I will assume that the WG is fine with = the first proposal, and also with the 2nd one conditional on deriving a = suitable "commonly used" TLV set. The problem in more detail:=20 Currently the situation is that Mandatory TLVs are only stated to = be as such in the body of the protocol draft spec, with an implementer = having to scour fairly attentively the text. Eg "Type = (Access-Loop-Circuit-ID =3D 0x01): This is a mandatory TLV", etc. The behaviour of an implementation that receives a message with a = missing mandatory TLV is not defined at all, and the opposite is handled = but not very robustly, i.e. when receiving a TLV but not recognizing it, = and implementation is free to discard it (even if it is mandatory!). = This is a recipe for interoperability problems and an implementation = mine field. This problem is complicated by different applications. For example = the current OAM section states the following regarding TLVs that are to = be carried in the request message (my italics): "=20 Following TLVs can appear in this message:=20 o Type (Access-Loop-Circuit-ID =3D 0x01) : defined in = section 5.4.1 =20 o Type (Access-Aggregation-Circuit-ID-Binary =3D 0x06): = defined in=20 section 5.4.1.=20 =20 o Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03): = defined in section=20 5.4.1. =20 o Type (OAM-Loopback-Test-Parameters =3D 0x07): Parameters = related to =20 loopback test. This is an optional TLV. If this TLV is not = present=20 in the request message, the DSLAM SHOULD use locally = determined=20 default values for the test parameters. =20 "=20 (NOTE: The last "SHOULD" appears to be inappropriate. If the TLV is = missing, the DSLAM MUST have some default parameters, or return an = error) The "can" above indicates that they're all optional, while clearly = the application cannot run its course without one or more of these = fields. Here we have a case where one could have a perfectly compliant = implementation that ignores all these TLVs... -Woj.=20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 ------_=_NextPart_001_01C8AA2B.B969F0C3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns:v =3D "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word" xmlns:p =3D=20 "urn:schemas-microsoft-com:office:powerpoint"><HEAD><TITLE>Nachricht</TIT= LE> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2900.3314" name=3DGENERATOR><!--[if !mso]> <STYLE>v\:* { BEHAVIOR: url(#default#VML) } o\:* { BEHAVIOR: url(#default#VML) } w\:* { BEHAVIOR: url(#default#VML) } .shape { BEHAVIOR: url(#default#VML) } </STYLE> <![endif]--> <STYLE>@font-face { font-family: Tahoma; } @page Section1 {size: 595.3pt 841.9pt; margin: 70.85pt 70.85pt 2.0cm = 70.85pt; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline } A:visited { COLOR: purple; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline } P { FONT-SIZE: 12pt; MARGIN-LEFT: 0cm; MARGIN-RIGHT: 0cm; FONT-FAMILY: = "Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto } SPAN.E-MailFormatvorlage18 { COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply } DIV.Section1 { page: Section1 } </STYLE> </HEAD> <BODY lang=3DDE vLink=3Dpurple link=3Dblue> <DIV dir=3Dltr align=3Dleft><SPAN class=3D366315418-29042008><FONT = face=3DArial=20 size=3D2>Hi Peter,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D366315418-29042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D366315418-29042008><FONT = face=3DArial=20 size=3D2>continued inline...</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>Peter=20 Arberg<BR><B>Sent:</B> 29 April 2008 20:39<BR><B>To:</B> Wojciech Dec = (wdec);=20 DE CNODDER Stefaan; Busser, M; ancp@ietf.org<BR><B>Cc:</B> Haag,=20 T<BR><B>Subject:</B> Re: [ANCP] Mandatory TLVs in = draft-ietf-ancp-protocol=20 proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D982091818-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Hi Woj,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D982091818-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D982091818-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>please see inline in your = answers</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D982091818-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com] <BR><B>Sent:</B> 29. april 2008 = 11:07<BR><B>To:</B>=20 Peter Arberg; DE CNODDER Stefaan; Busser, M; = ancp@ietf.org<BR><B>Cc:</B>=20 Haag, T<BR><B>Subject:</B> RE: Re: [ANCP] Mandatory TLVs in=20 draft-ietf-ancp-protocol proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D547254517-29042008><FONT = face=3DArial=20 size=3D2>Hi Peter,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D547254517-29042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D547254517-29042008><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 = 2px solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Peter Arberg=20 [mailto:parberg@redback.com] <BR><B>Sent:</B> 29 April 2008=20 19:34<BR><B>To:</B> Wojciech Dec (wdec); DE CNODDER Stefaan; = Busser, M;=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> RE: Re: = [ANCP]=20 Mandatory TLVs in draft-ietf-ancp-protocol = proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Hi Woj,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>I agree with Michael and Stefan on this = issue, I do=20 not see a need to change the existing</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2>implementation = with a=20 mandatory/optional flag.<SPAN class=3D547254517-29042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D547254517-29042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><SPAN class=3D547254517-29042008><FONT = face=3DArial><FONT=20 size=3D2><FONT color=3D#000000>Woj> Please indicate where in my = proposal=20 did you see anything about</FONT> <FONT = color=3D#000000>changing=20 existing implementaions? </FONT><FONT color=3D#0000ff><SPAN=20 = class=3D982091818-29042008> </SPAN></FONT></FONT></FONT></SPAN></FON= T></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><SPAN class=3D547254517-29042008><FONT = face=3DArial><FONT=20 size=3D2><FONT color=3D#0000ff><SPAN=20 = class=3D982091818-29042008></SPAN></FONT></FONT></FONT></SPAN></FONT></SP= AN> </DIV></BLOCKQUOTE></BLOCKQUOTE> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = size=3D+0><SPAN=20 class=3D547254517-29042008><FONT size=3D+0><FONT face=3DArial = color=3D#0000ff=20 size=3D2><SPAN class=3D982091818-29042008>PAR>  I might = have=20 misunderstood your email, but I read it as if you suggest a high=20 bit</SPAN></FONT></FONT></SPAN></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT color=3D#0000ff><SPAN=20 class=3D982091818-29042008><FONT face=3DArial><FONT size=3D2>value in = existing TLV's=20 to be interpreted as a mandatory flag.<SPAN = class=3D366315418-29042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></SPAN></FONT></SPAN></= SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT color=3D#0000ff><SPAN=20 class=3D982091818-29042008><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D366315418-29042008></SPAN></FONT></FONT></SPAN></FONT></SPAN></SP= AN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT color=3D#0000ff><SPAN=20 class=3D982091818-29042008><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D366315418-29042008><FONT color=3D#000000>Woj#2> Yes, I = suggested (in=20 proposal 2) that *if* the WG found there to be a common set of TLVs = currently=20 in use, then the high-order bit set to "0" (ie as today) could be = interpreted=20 as "mandatory", and the rest of the TLV's redefined with a high order = "1". To=20 extsing implementations, the "new" TLVs would just look like a = different TLV#,=20 while anyone wishing to implement the more robust error cheking = logic=20 based on this bit, would be free to do=20 = so.</FONT> </SPAN></FONT></FONT></SPAN></FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = size=3D+0><SPAN=20 class=3D547254517-29042008><FONT size=3D+0><FONT face=3DArial = color=3D#0000ff=20 size=3D2><SPAN=20 = class=3D982091818-29042008></SPAN></FONT></FONT></SPAN></FONT></SPAN>&nbs= p;</DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = size=3D+0><SPAN=20 class=3D547254517-29042008><FONT size=3D+0><FONT face=3DArial = color=3D#0000ff=20 size=3D2><SPAN class=3D982091818-29042008>If you are simply talking = about new=20 capability type definitions, then why do you not bring=20 up</SPAN></FONT></FONT></SPAN></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT color=3D#0000ff><SPAN=20 class=3D982091818-29042008><FONT face=3DArial><FONT size=3D2>the = additional flag in=20 a new internet-draft defining what capability type you have in mind = ?<SPAN=20 class=3D366315418-29042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></SPAN></FONT></SPAN></= SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT color=3D#0000ff><SPAN=20 class=3D982091818-29042008><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D366315418-29042008></SPAN></FONT></FONT></SPAN></FONT></SPAN></SP= AN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT color=3D#0000ff><SPAN=20 class=3D982091818-29042008><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D366315418-29042008><FONT color=3D#000000>Woj#2> No, a new = capability=20 was not intended, but could also be=20 = considered.</FONT></SPAN></FONT></FONT></SPAN></FONT></SPAN></SPAN></DIV>= <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = size=3D+0><SPAN=20 class=3D547254517-29042008><FONT size=3D+0><FONT face=3DArial = color=3D#0000ff=20 size=3D2><SPAN=20 = class=3D982091818-29042008></SPAN></FONT></FONT></SPAN></FONT></SPAN>&nbs= p;</DIV> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 = 2px solid; MARGIN-RIGHT: 0px"> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>I think I understand your arguments, but = I do not=20 agree with them. I think most places in</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2>the draft it is = clear what is=20 defined as mandatory and optional.<SPAN = class=3D547254517-29042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>I agree on the point we need to go = through the draft=20 and make clarifications to what TLV's</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>in what capability types are mandatory = and optional,=20 and make more description what should</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2>happen if = mandatory TLVs are=20 not included.<SPAN class=3D547254517-29042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D547254517-29042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008><FONT color=3D#000000>Woj>=20 Exactly.</FONT> </SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>I think the DSLF TR-101 document has a = good example=20 of such a description in it's </FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 size=3D2><FONT color=3D#0000ff>"</FONT><FONT face=3DArial-BoldMT = size=3D2><FONT=20 color=3D#0000ff>Table 3 - Access loop characteristics = sub-options<SPAN=20 class=3D058271017-29042008>", and I think if we do the same for=20 each</SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 size=3D2><FONT face=3DArial-BoldMT size=3D2><FONT = color=3D#0000ff><SPAN=20 class=3D058271017-29042008>capability types TLV's in the ANCP = draft it will=20 be a good help.</SPAN></FONT></DIV></FONT></FONT></SPAN> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN = class=3D547254517-29042008><FONT color=3D#0000ff><FONT = face=3DArial><FONT=20 size=3D2><FONT color=3D#000000>Woj></FONT> <FONT = color=3D#000000>Indeed,=20 pre-ceeded by some rationalization. The appears to be no reason = for some=20 of the DSLF "mandatory" TLVs.</FONT><FONT color=3D#0000ff><SPAN=20 = class=3D982091818-29042008> </SPAN></FONT></FONT></FONT></FONT></SPA= N></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN = class=3D547254517-29042008><FONT color=3D#0000ff><FONT = face=3DArial><FONT=20 size=3D2><FONT color=3D#0000ff><SPAN=20 = class=3D982091818-29042008></SPAN></FONT></FONT></FONT></FONT></SPAN></SP= AN> </DIV></BLOCKQUOTE></BLOCKQUOTE> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT=20 color=3D#0000ff><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT color=3D#0000ff><FONT = face=3DArial><FONT=20 size=3D2><FONT color=3D#0000ff><SPAN = class=3D982091818-29042008>PAR> I do not see=20 a problem with re-visit in the draft if a TLV should be optional or = mandatory,=20 so=20 = if</SPAN></FONT></FONT></FONT></FONT></SPAN></SPAN></FONT></FONT></FONT><= /DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT=20 color=3D#0000ff><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT color=3D#0000ff><FONT = face=3DArial><FONT=20 size=3D2><FONT color=3D#0000ff><SPAN class=3D982091818-29042008>that = is the intend,=20 then I'm all for an email discussion on a TLV by TLV basis if we think = it is a=20 = </SPAN></FONT></FONT></FONT></FONT></SPAN></SPAN></FONT></FONT></FONT></D= IV> <DIV dir=3Dltr align=3Dleft><FONT color=3D#0000ff><SPAN=20 class=3D058271017-29042008><SPAN class=3D547254517-29042008><FONT=20 color=3D#0000ff><FONT color=3D#0000ff><SPAN = class=3D982091818-29042008><FONT=20 face=3DArial><FONT size=3D2>manfdatory or optional information inside = the specific=20 capability type.<SPAN class=3D366315418-29042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></SPAN></FONT></FONT></= SPAN></SPAN></FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT color=3D#0000ff><SPAN=20 class=3D058271017-29042008><SPAN class=3D547254517-29042008><FONT=20 color=3D#0000ff><FONT color=3D#0000ff><SPAN = class=3D982091818-29042008><FONT=20 face=3DArial><FONT size=3D2><SPAN=20 = class=3D366315418-29042008></SPAN></FONT></FONT></SPAN></FONT></FONT></SP= AN></SPAN></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><FONT color=3D#0000ff><SPAN=20 class=3D058271017-29042008><SPAN class=3D547254517-29042008><FONT=20 color=3D#0000ff><FONT color=3D#0000ff><SPAN = class=3D982091818-29042008><FONT=20 face=3DArial><FONT size=3D2><SPAN class=3D366315418-29042008><FONT=20 color=3D#000000>Woj#2> Great, because any change to the mandated=20 set *will* affect existing implementation</FONT> <FONT=20 = color=3D#000000>.</FONT></SPAN></FONT></FONT></SPAN></FONT></FONT></SPAN>= </SPAN></FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT=20 color=3D#0000ff><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT color=3D#0000ff><FONT = face=3DArial><FONT=20 size=3D2><FONT color=3D#0000ff><SPAN=20 = class=3D982091818-29042008></SPAN></FONT></FONT></FONT></FONT></SPAN></SP= AN></FONT></FONT></FONT> </DIV> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 = 2px solid; MARGIN-RIGHT: 0px"> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN = class=3D547254517-29042008><FONT color=3D#0000ff><FONT = face=3DArial><FONT=20 size=3D2><FONT color=3D#0000ff><SPAN=20 = class=3D982091818-29042008></SPAN></FONT></FONT></FONT></FONT></SPAN></SP= AN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>I do not agree with your point that it is = not listed=20 if "rate" is mandatory or optional, it is = clearly</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>listed as a mandatory TLV, and as such it = should be=20 included in the port up message, I really</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2>do not = understand what=20 confusion you have with this.<SPAN = class=3D547254517-29042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D547254517-29042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008><FONT color=3D#000000>Woj> The text=20 = states:  </FONT> </SPAN></FONT></FONT></FONT></SPAN></DIV>= <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D547254517-29042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008><FONT size=3D1><FONT face=3D"Courier = New"=20 color=3D#000000 size=3D2>5. Type (DSL Line Attributes =3D 0x04): = </FONT></DIV> <P dir=3Dltr align=3Dleft><FONT face=3D"Courier New" = color=3D#000000 size=3D2>Length=20 : variable (up to 1024 bytes) </FONT></P> <P dir=3Dltr align=3Dleft><FONT face=3D"Courier New" = color=3D#000000 size=3D2>Value=20 : This consists of one or more Sub-TLVs corresponding to DSL = </FONT></P> <P dir=3Dltr align=3Dleft><FONT face=3D"Courier New" = color=3D#000000 size=3D2>line=20 attributes. No sub-TLVs other than the "DSL type" and "DSL = </FONT></P> <P dir=3Dltr align=3Dleft><FONT face=3D"Courier New" = color=3D#000000 size=3D2>line=20 state" SHOULD be included in a PORT DOWN message. </FONT></P> <P dir=3Dltr align=3Dleft><FONT face=3D"Courier New" = color=3D#000000 size=3D2>The=20 general format of the sub-TLVs is identical to the general TLV = </FONT></P> <P dir=3Dltr align=3Dleft><FONT face=3D"Courier New" = color=3D#000000=20 size=3D2>format. The value field in each sub-TLV is padded to a = 4-octet=20 </FONT></P> <P dir=3Dltr align=3Dleft><FONT face=3D"Courier New" = color=3D#000000=20 size=3D2>alignment. The Length field in each sub-TLV contains the = actual=20 </FONT></P> <P dir=3Dltr align=3Dleft><FONT face=3D"Courier New" = color=3D#000000 size=3D2>number=20 of bytes in the TLV (not including the padding if present). = </FONT></P> <P dir=3Dltr align=3Dleft><FONT color=3D#000000><FONT = face=3D"Courier New"=20 size=3D2>Current defined sub-TLV types are start from=20 0x81.</FONT> <SPAN class=3D547254517-29042008><FONT = face=3DArial=20 size=3D2> </FONT></SPAN></FONT></P> <P dir=3Dltr align=3Dleft><FONT color=3D#000000><SPAN=20 class=3D547254517-29042008><FONT face=3DArial size=3D2>Maybe you = can point me to=20 where exatly it is stated clearly as being mandatory, or otherwise = explain=20 why you "not agree"?</FONT> <SPAN = class=3D982091818-29042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2> </FONT></SPAN></SPAN></FONT></P> <P dir=3Dltr align=3Dleft><FONT color=3D#000000><SPAN=20 class=3D547254517-29042008><SPAN=20 = class=3D982091818-29042008></SPAN></SPAN></FONT> </P></BLOCKQUOTE></= BLOCKQUOTE> <DIV dir=3Dltr align=3Dleft><SPAN class=3D547254517-29042008><SPAN=20 class=3D982091818-29042008><FONT color=3D#000000><FONT = size=3D2>PAR> I think you=20 forgot to read the most important part where the actual TLV is = defined.<SPAN=20 = class=3D366315418-29042008> </SPAN></FONT></FONT></SPAN></SPAN></DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D547254517-29042008><SPAN=20 class=3D982091818-29042008><FONT color=3D#000000><FONT size=3D2><SPAN=20 = class=3D366315418-29042008></SPAN></FONT></FONT></SPAN></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D547254517-29042008><SPAN=20 class=3D982091818-29042008><FONT color=3D#000000><FONT size=3D2><SPAN=20 class=3D366315418-29042008>Woj#2> I didn't. This part talks = about the=20 sub-TLV, not the main TLV 0x04. Do you see my point=20 now?</SPAN></FONT></FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D547254517-29042008><SPAN=20 class=3D982091818-29042008><FONT color=3D#000000><FONT size=3D2><SPAN=20 = class=3D366315418-29042008></SPAN></FONT></FONT></SPAN></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><FONT color=3D#000000 size=3D2><SPAN=20 class=3D547254517-29042008><SPAN=20 class=3D982091818-29042008></SPAN></SPAN></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><FONT color=3D#000000 size=3D2><SPAN=20 class=3D547254517-29042008><SPAN class=3D982091818-29042008>Type=20 (Actual-Net-Data-Upstream =3D 0x81): Actual upstream net = data rate on a DSL=20 line. </SPAN></SPAN></FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT color=3D#000000 size=3D2><SPAN=20 class=3D547254517-29042008><SPAN class=3D982091818-29042008>This is a = mandatory=20 TLV.  </SPAN></SPAN></FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><FONT color=3D#000000 size=3D2><SPAN=20 class=3D547254517-29042008><SPAN = class=3D982091818-29042008>Length  : =20 (4 bytes) </SPAN></SPAN></FONT></DIV> <DIV><FONT color=3D#000000 size=3D2><SPAN = class=3D547254517-29042008><SPAN=20 class=3D982091818-29042008>Value   : (Rate in Kb/sec)=20 </SPAN></SPAN></FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><FONT color=3D#000000 size=3D2><SPAN=20 class=3D547254517-29042008><SPAN class=3D982091818-29042008>Type=20 (Actual-Net-Data-Rate-Downstream =3D 0x82) : Actual downstream net = data rate on=20 a DSL line. </SPAN></SPAN></FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT color=3D#000000 size=3D2><SPAN=20 class=3D547254517-29042008><SPAN class=3D982091818-29042008>This is a = mandatory=20 TLV. </SPAN></SPAN></FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><FONT color=3D#000000 size=3D2><SPAN=20 class=3D547254517-29042008><SPAN class=3D982091818-29042008>Length = :  (4=20 bytes) </SPAN></SPAN></FONT></DIV> <DIV><FONT color=3D#000000 size=3D2><SPAN = class=3D547254517-29042008><SPAN=20 class=3D982091818-29042008>Value  :  (Rate in Kb/sec)=20 </SPAN></SPAN></FONT></DIV> <DIV><FONT color=3D#000000 size=3D2><SPAN = class=3D547254517-29042008><SPAN=20 class=3D982091818-29042008></SPAN></SPAN></FONT> </DIV> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 = 2px solid; MARGIN-RIGHT: 0px"><FONT=20 size=3D2></FONT><FONT=20 size=3D2></FONT></FONT></SPAN></FONT></FONT></FONT></SPAN> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>The fact you say "Port UP" and "OAM" is = best=20 considered as legacy applications, I have some</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>trouble with this as well, since ANCP = running in=20 production networks use them, and as such</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2>it is a central = part of the=20 ANCP specifications we need to finish as soon as possible.<SPAN=20 class=3D547254517-29042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D547254517-29042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008><FONT color=3D#000000>Woj> I should = have said=20 legacy applications from a protocol messaging perspective, not = usage, nor=20 support. It's quite clear that GSMP derived messaging has baggage = that is=20 un called for in new=20 applications.</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>I think Stefaan's example is very valid, = that we do=20 not need to make mandatory requirements to </FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>what receivers of ANCP information use = such info.=20 for.  I don't think we should try and make = the</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>ANCP specifications "mandatory" for box = behavior, I=20 think it is much more important for the </FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>working group to make the protocol = specifications=20 easy to understand and get the first = documentation</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>finish and published, so the protocol can = be used for=20 different sets of applications, and make sure</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2>new applications = can be added=20 later.<SPAN class=3D547254517-29042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D547254517-29042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008><FONT color=3D#000000>Woj> Indeed = the aim of the=20 WG to define a protocol that is relatively simple and easy to = understand,=20 not just to implementers but also to people using it, and across = vendors.=20 Currently, having anyone operating the device be familiar in what = cases a=20 TLV is mandatory and in what optional requires a thorough = understanding of=20 the spec, across applications. This is not easy, but I'll conceede = that=20 for the applications implemented so far we could live with it.=20 </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>I do think that by documenting if a TLV = is mandatory=20 or optional inside a specific capability type,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2>it is easy to = understand what=20 must be sent to support the defined application/capability = type.<SPAN=20 class=3D547254517-29042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D547254517-29042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><SPAN class=3D547254517-29042008><FONT = color=3D#000000><FONT=20 face=3DArial><FONT size=3D2>Woj> Of course it is, the = whole spec is=20 about this. The problem comes when people start to = re-use well known=20 TLVs for different applications, and then trying to make sense of = it all=20 becomes non-trivial. Why do you think both BGP and Diamater, and a = number=20 of other protocols have definied "Mandatory" flags? Just for = kicks? It's a=20 well known protocol design tool, that comes handy when re-using = same data=20 across multiple applications.<SPAN = class=3D982091818-29042008><FONT=20 = color=3D#0000ff> </FONT></SPAN></FONT></FONT></FONT></SPAN></FONT></= SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><SPAN class=3D547254517-29042008><FONT = color=3D#000000><FONT=20 face=3DArial><FONT size=3D2><SPAN=20 = class=3D982091818-29042008></SPAN></FONT></FONT></FONT></SPAN></FONT></SP= AN> </DIV></BLOCKQUOTE></BLOCKQUOTE> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT=20 color=3D#0000ff><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><SPAN=20 class=3D547254517-29042008><FONT color=3D#000000><FONT = face=3DArial><FONT=20 size=3D2><SPAN class=3D982091818-29042008>PAR> I might be wrong, = but I think I=20 can find as many or more protocol examples who do not=20 = include</SPAN></FONT></FONT></FONT></SPAN></FONT></SPAN></FONT></FONT></F= ONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT=20 color=3D#0000ff><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><SPAN=20 class=3D547254517-29042008><FONT color=3D#000000><FONT = face=3DArial><FONT=20 size=3D2><SPAN class=3D982091818-29042008>a mandatory/optional flag, = so examples=20 can always be found which will support the point you are=20 = trying</SPAN></FONT></FONT></FONT></SPAN></FONT></SPAN></FONT></FONT></FO= NT></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT=20 color=3D#0000ff><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><SPAN=20 class=3D547254517-29042008><FONT color=3D#000000><FONT = face=3DArial><FONT=20 size=3D2><SPAN class=3D982091818-29042008>to=20 = make.</SPAN></FONT></FONT></FONT></SPAN></FONT></SPAN></FONT></FONT></FON= T></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT face=3DArial size=3D2><SPAN=20 class=3D982091818-29042008><SPAN=20 class=3D366315418-29042008></SPAN></SPAN></FONT></SPAN></SPAN><FONT=20 face=3DArial><FONT size=3D2><FONT color=3D#0000ff><SPAN=20 class=3D058271017-29042008><FONT color=3D#0000ff><SPAN=20 class=3D547254517-29042008><FONT color=3D#000000><FONT = face=3DArial><FONT=20 size=3D2><SPAN=20 = class=3D982091818-29042008></SPAN></FONT></FONT></FONT></SPAN></FONT></SP= AN></FONT></FONT></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT=20 color=3D#0000ff><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><SPAN=20 class=3D547254517-29042008><FONT color=3D#000000><FONT = face=3DArial><FONT=20 size=3D2><SPAN class=3D982091818-29042008>I do not see a problem with = a new=20 internet-draft which defines new capability-types and where a=20 = TLV</SPAN></FONT></FONT></FONT></SPAN></FONT></SPAN></FONT></FONT></FONT>= </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><SPAN class=3D982091818-29042008><FONT = face=3DArial><FONT=20 size=3D2>mandatory flag is included, I do see a problem if the intend = is to try=20 and adjust what already exist. <SPAN=20 = class=3D366315418-29042008> </SPAN></FONT></FONT></SPAN></SPAN></SPA= N></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><SPAN class=3D982091818-29042008><FONT = face=3DArial><FONT=20 size=3D2><SPAN=20 = class=3D366315418-29042008></SPAN></FONT></FONT></SPAN></SPAN></SPAN>&nbs= p;</DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><SPAN class=3D982091818-29042008><FONT = face=3DArial><FONT=20 size=3D2><SPAN class=3D366315418-29042008>Woj#2> Ok, so if = adjusting is only=20 scoped to what doesn't exist, as my proposal laid = out conditionally,=20 you're fine.</SPAN></FONT></FONT></SPAN></SPAN></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT=20 color=3D#0000ff><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><SPAN=20 class=3D547254517-29042008><FONT color=3D#000000><FONT = face=3DArial><FONT=20 size=3D2><SPAN=20 = class=3D982091818-29042008></SPAN></FONT></FONT></FONT></SPAN></FONT></SP= AN></FONT></FONT></FONT> </DIV> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 = 2px solid; MARGIN-RIGHT: 0px"> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><SPAN class=3D547254517-29042008><FONT = color=3D#000000><FONT=20 face=3DArial><FONT size=3D2><SPAN=20 = class=3D982091818-29042008></SPAN></FONT></FONT></FONT></SPAN></FONT></SP= AN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Then if anybody want to include new = capability types=20 or sub-TLVs later to address specific = applications,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>then I think changes can be discussed at = that time=20 instead of trying to change existing protocol</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT = size=3D2>implementations.<SPAN=20 class=3D547254517-29042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D547254517-29042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D547254517-29042008><FONT color=3D#000000>Woj> Again I = ask, where in=20 the proposal did you see *anything* requiring a change to an = existing=20 implementation. Please be specific.</FONT> <FONT = color=3D#000000>I see=20 that your main objection is on this issue, which means that you = accept=20 proposal 1 (have such a flag for new=20 TLVs/apps).</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN = class=3D547254517-29042008><FONT face=3DArial><FONT size=3D2>It = would also be=20 useful if you indicated whether the list of TLVs provided below is = what=20 you'd expect to be the minimum mandatory set.<SPAN=20 class=3D982091818-29042008><FONT=20 = color=3D#0000ff> </FONT></SPAN></FONT></FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN = class=3D547254517-29042008><FONT face=3DArial><FONT size=3D2><SPAN = = class=3D982091818-29042008></SPAN></FONT></FONT></SPAN></SPAN> </DIV= ></BLOCKQUOTE></BLOCKQUOTE> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT size=3D+0><FONT face=3DArial = color=3D#0000ff=20 size=3D2><SPAN class=3D982091818-29042008>PAR> at the moment I read = the draft=20 as having defined the TLVs mandatory as you describe,=20 except</SPAN></FONT></FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT size=3D+0><FONT face=3DArial = color=3D#0000ff=20 size=3D2><SPAN class=3D982091818-29042008>I also read it as the = dsl-type =3D=20 0x91 must be part of the port down. If this is needed or not is a=20 different</SPAN></FONT></FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT size=3D+0><FONT face=3DArial = color=3D#0000ff=20 size=3D2><SPAN=20 = class=3D982091818-29042008>discussion.</SPAN></FONT></FONT></SPAN></SPAN>= </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT size=3D+0><FONT face=3DArial = color=3D#0000ff=20 size=3D2><SPAN=20 = class=3D982091818-29042008></SPAN></FONT></FONT></SPAN></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT size=3D+0><FONT face=3DArial = color=3D#0000ff=20 size=3D2><SPAN=20 = class=3D982091818-29042008></SPAN></FONT></FONT></SPAN></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT face=3DArial color=3D#0000ff = size=3D2><SPAN=20 class=3D982091818-29042008><SPAN class=3D366315418-29042008>Woj#2> = Ok. Thanks.=20 But please do come back to me if you see that the proposal impacts an = exiting=20 implementation. I conclude that there is no problem with doing changes = to=20 stuff that isn't currently = used.</SPAN></SPAN></FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT face=3DArial color=3D#0000ff = size=3D2><SPAN=20 class=3D982091818-29042008><SPAN=20 = class=3D366315418-29042008>Woj.</SPAN></SPAN></FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT size=3D+0><FONT face=3DArial = color=3D#0000ff=20 size=3D2><SPAN=20 = class=3D982091818-29042008></SPAN></FONT></FONT></SPAN></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT size=3D+0><FONT face=3DArial = color=3D#0000ff=20 size=3D2><SPAN=20 = class=3D982091818-29042008>cheers,</SPAN></FONT></FONT></SPAN></SPAN></DI= V> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><SPAN=20 class=3D547254517-29042008><FONT size=3D+0><FONT face=3DArial = color=3D#0000ff=20 size=3D2><SPAN=20 = class=3D982091818-29042008>Peter</SPAN></FONT></FONT></SPAN></SPAN><SPAN = class=3D058271017-29042008><SPAN class=3D547254517-29042008><FONT = size=3D+0><FONT=20 face=3DArial color=3D#0000ff size=3D2><SPAN=20 = class=3D982091818-29042008> </SPAN></FONT></FONT></SPAN></SPAN></DIV= > <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 = 2px solid; MARGIN-RIGHT: 0px"> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = size=3D+0><FONT=20 face=3DArial><FONT size=3D2><SPAN=20 = class=3D547254517-29042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = size=3D+0><FONT=20 face=3DArial><FONT size=3D2><SPAN=20 = class=3D547254517-29042008>Cheers,</SPAN></FONT></FONT></FONT></SPAN></DI= V> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = size=3D+0><FONT=20 face=3DArial><FONT size=3D2><SPAN=20 = class=3D547254517-29042008>Woj.</SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>cheers,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Peter</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D058271017-29042008><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff = 2px solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>Wojciech Dec=20 (wdec)<BR><B>Sent:</B> 29. april 2008 02:28<BR><B>To:</B> DE = CNODDER=20 Stefaan; Busser, M; ancp@ietf.org<BR><B>Cc:</B> Haag,=20 T<BR><B>Subject:</B> Re: [ANCP] Mandatory TLVs in=20 draft-ietf-ancp-protocol proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008><FONT face=3DArial=20 size=3D2>Stefaan,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008><FONT face=3DArial=20 size=3D2>a number of points:</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008><FONT face=3DArial=20 size=3D2>1. There currently is to my knowledge no = implementation of=20 ANCP there that doesn't send the DSL Line attributes info by = default in=20 Port-UP messages? The support of HS on the NAS is an orthogonal=20 issue.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008><FONT face=3DArial=20 size=3D2>2. T</FONT></SPAN><SPAN = class=3D342501308-29042008><FONT face=3DArial=20 size=3D2>he current ancp protocol draft (02) doesn't say whether = the rate=20 info is optional or mandatory, it only states that the sub-TLVs = are=20 mandatory. Based on this, an implementer can be justified = to expect=20 port-ups to *always* have the rate-info tlv (ie treat them as=20 mandatory). Equally, she's justified in considering = this  as=20 optional.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008><SPAN=20 class=3D342501308-29042008><FONT face=3DArial = size=3D2>3.<EM> </EM><SPAN=20 class=3D342501308-29042008><FONT face=3DArial size=3D2>The = port-up and OAM=20 are best considered as legacy applications for ANCP. The = re-use of=20 any of the GSMP defined fields is already out of the question = due to=20 constrains put in place by the existing use-case messaging. = Needless to=20 say, this wasn't as thoroughly designed as it should have been, = and with=20 the OAM and port-up apps being=20 coupled.</FONT></SPAN></FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008><FONT face=3DArial=20 size=3D2>4. It's up to the application to define what TLVs are = mandatory=20 and which aren't, as you also state. The AN does not need = to know=20 what the NAS will do with the info, BUT it needs to send the = right TLVs=20 for the application (eg if we had a hypothetical AN that = only sends=20 Port-up's with line-id, it would be next to useless for the = dynamic=20 shaping application).</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008><FONT face=3DArial=20 size=3D2>With all this in mind it's useful to re-read what I = proposed=20 originally below regarding the mandatory flag: 1. "<EM>have = this=20 TLV Flag be defined only for new applications" </EM>and 2. The = notion of=20 the mandatory flag applying to existing TLVs  being=20 "<EM>conditional on deriving a suitable "commonly used" TLV = set."=20 </EM>The latter point would ensure that existing implementations = do not=20 need to change, but future ones can take advantage of the extra=20 robustness.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008><FONT face=3DArial=20 size=3D2><SPAN = class=3D342501308-29042008></SPAN></FONT></SPAN><SPAN=20 class=3D342501308-29042008><FONT face=3DArial=20 size=3D2><EM></EM></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008><FONT face=3DArial=20 size=3D2>Hence, can the WG derive a set of commonly used, i.e. = always=20 used, TLVs for existing implementations?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008><FONT face=3DArial=20 size=3D2>The list I came up is as follows (making them pretty = much=20 mandatory TLVs if it agrees with the views of=20 others);</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008><FONT face=3DArial=20 size=3D2>Port-up message (0x80);</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008><FONT face=3DArial=20 size=3D2>    Extension-TLV (dsl tech=20 type)</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008><FONT face=3DArial=20 size=3D2>    Access-Loop-circuit-id=20 (0x01)</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008><FONT face=3DArial=20 size=3D2>    DSL Line Attribute (0x04) with the = following=20 sub TLVs;</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008> <FONT=20 size=3D2>       DSL-Type =3D 0x91; = Actual-Net-Data-Upstream =3D 0x81<SPAN = class=3D342501308-29042008>;=20 Actual-Net-Data-Rate-Downstream =3D = 0x82</SPAN></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008><FONT face=3DArial=20 size=3D2>Port-down message (0x81);</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN=20 class=3D342501308-29042008>    <FONT face=3DArial = size=3D2>Extension  TLV (dsl tech type)</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN=20 class=3D342501308-29042008>    <FONT face=3DArial = size=3D2>Access-Loop-circuit-id (0x01)</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN=20 class=3D342501308-29042008>    <FONT face=3DArial = size=3D2>DSL=20 Line Attribute (0x04) with the following sub = TLVs;</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN=20 = class=3D342501308-29042008>       <FON= T=20 size=3D2> DSL line state =3D 0x8F</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008><FONT=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008><FONT face=3DArial=20 size=3D2>All other TLVs are optional.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008><FONT face=3DArial=20 size=3D2>Would appreciate confirmation from the WG regarding the = above.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008><FONT face=3DArial=20 size=3D2>Thanks,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008><FONT face=3DArial=20 size=3D2>Woj.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D342501308-29042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: = #000000 2px solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> DE CNODDER Stefaan=20 [mailto:stefaan.de_cnodder@alcatel-lucent.be] <BR><B>Sent:</B> = 29=20 April 2008 09:52<BR><B>To:</B> Wojciech Dec (wdec); Busser, M; = ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> RE: = [ANCP]=20 Mandatory TLVs in draft-ietf-ancp-protocol=20 proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff = size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D853253107-29042008><FONT=20 face=3DArial color=3D#0000ff size=3D2>Hi = Woj,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D853253107-29042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D853253107-29042008><FONT=20 face=3DArial color=3D#0000ff size=3D2>Take the following = example: I have a=20 network with 2 NASses, NAS-A is doing hierarchical shaping, = NAS-B just=20 wants to have the port information but is not doing = hierarchical=20 shaping (it is doing other things like OAM, ...).  This = means=20 NAS-A needs the bandwidth, while NAS-B does not need the=20 bandwidth.  How should the flag be set in this case by = the=20 AN?  Set to 'Mandatory' for the port up messages to = NAS-A, and=20 set to 'Optional' for port up messages towards NAS-B? Or is it = always=20 set to 'Mandatory'?  From your answer below, I understand = that it=20 should be set to 'Optional' towards NAS-B.  Is that=20 correct?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D853253107-29042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D853253107-29042008><FONT=20 face=3DArial color=3D#0000ff size=3D2>NAS-B will simply ignore = the bandwidth=20 TLV.  If such a flag would exist, and the flag is set to=20 'Mandatory' by the AN to NAS-B, what should be the behavior of = NAS-B?  Should it reject the whole message?  Maybe = NAS-B is=20 not supporting hierarchical shaping, so it might not support = the=20 bandwidth TLV.  Today, the bandwidht TLV is only = mandatory to be=20 put in the port up messages, but for the receiver there is = nothing=20 mandatory.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D853253107-29042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D853253107-29042008><FONT=20 face=3DArial color=3D#0000ff size=3D2>I believe the original = intend of ANCP=20 was that the AN does not need to know what the NAS is doing = with this=20 information, the use of the bandwidth is also not specified by = ANCP,=20 only an example is given (which is shaping).  In the = future there=20 may be applications for which TLVs will be mandatory which are = now=20 optional.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D853253107-29042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D853253107-29042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2>regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D853253107-29042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2>Stefaan</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D853253107-29042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D853253107-29042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D853253107-29042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV><BR> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com] <BR><B>Sent:</B> maandag 28 april 2008 = 21:33<BR><B>To:</B> DE CNODDER Stefaan; Busser, M;=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> RE: = [ANCP]=20 Mandatory TLVs in draft-ietf-ancp-protocol=20 proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial=20 size=3D2></FONT> </DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: = #000000 2px solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> DE CNODDER Stefaan = [mailto:stefaan.de_cnodder@alcatel-lucent.be] = <BR><B>Sent:</B> 28=20 April 2008 17:15<BR><B>To:</B> Wojciech Dec (wdec); Busser, = M;=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> RE: = [ANCP]=20 Mandatory TLVs in draft-ietf-ancp-protocol=20 proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>Take the = bandwidth=20 sub-TLV in port up messages as example.  The current = protocol=20 spec says that it is mandatory to be sent in port up=20 messages.  that's ok.  But it is not mandatory for = the=20 receiver to process the bandwidth sub-TLV.  What is = done with=20 this information by the NAS is not specified by ANCP, so you = cannot=20 make it mandatory for the receiver side.<SPAN=20 class=3D163161615-28042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D163161615-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008><FONT color=3D#000000>Woj> Is = the=20 information required by the application? It would appear for = the=20 dynamic shaping use-case to be most certainly so. Hence it = is=20 absolutely mandatory, otherwise the message makes no sense = for the=20 application.</FONT> <FONT color=3D#000000>In any case, = if=20 </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>So it = looks to me that=20 the flag can only indicate what the receiver should = do.  Then=20 the flag makes sense.<SPAN class=3D163161615-28042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D163161615-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008><FONT color=3D#000000>Woj>=20 </FONT> <FONT color=3D#000000>The flag tells the = receiver what=20 info the sender thinks is required to carry out the = application.=20 This in almost all cases has to match up to what the = receiver thinks=20 is required. The=20 sender </FONT></SPAN></FONT></FONT></FONT></SPAN><SPAN=20 class=3D436050615-28042008><FONT color=3D#0000ff><FONT = face=3DArial><FONT=20 size=3D2><SPAN class=3D163161615-28042008><FONT = color=3D#000000>doesn't=20 tell the receiver what to do with the=20 info.</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>If the = receiver knows=20 what is mandatory, then I do not see a reason why this has = to be=20 made explicit in the protocol.  It would only = complicate the=20 protocol.  As already said by Michael: if a mandatory = TLV is=20 not there, then it is just a bug.<SPAN=20 class=3D163161615-28042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D163161615-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008><FONT color=3D#000000>Woj> Can = you=20 specifically describe what aspect of the protocol does it=20 complicate?</FONT> <FONT color=3D#000000>It's just = making=20 explicitly clear what the protocol already has to implement = anyway=20 to be of any = use.</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 size=3D+0><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D163161615-28042008>As to whether it is a bug, having = such=20 explicit marking makes it clear what/where the problem is = when=20 observing a messaging flow vs a lot of deduction work. = In any=20 case, the other point being made here is that today the = protocol does NOT specify what should happen if a mandatory = TLV is=20 missing.</SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 size=3D+0><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D163161615-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 size=3D+0><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D163161615-28042008>-Woj.</SPAN></FONT></FONT></FONT></SPAN></DIV>= <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2>regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2>Stefaan</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D436050615-28042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV><BR> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Wojciech Dec = (wdec)=20 [mailto:wdec@cisco.com] <BR><B>Sent:</B> maandag 28 april = 2008=20 16:28<BR><B>To:</B> DE CNODDER Stefaan; Busser, M;=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> RE: = [ANCP]=20 Mandatory TLVs in draft-ietf-ancp-protocol=20 proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D560491614-28042008><FONT=20 face=3DArial size=3D2>It's actually a mix of both.=20 Inline...</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: = #000000 2px solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> = ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of </B>DE = CNODDER=20 Stefaan<BR><B>Sent:</B> 28 April 2008 16:04<BR><B>To:</B> = Wojciech=20 Dec (wdec); Busser, M; ancp@ietf.org<BR><B>Cc:</B> Haag,=20 T<BR><B>Subject:</B> Re: [ANCP] Mandatory TLVs in=20 draft-ietf-ancp-protocol proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2>Hi,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 face=3DArial color=3D#0000ff size=3D2>This new mandatory = flag, what is=20 exactly its meaning?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT = size=3D2>(1) if flag set=20 to "mandatory", then the *receiver* of this TLV MUST = process it,=20 and if unrecognized must drop the message<SPAN=20 class=3D560491614-28042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>If a = received TLV is=20 has the "mandatory" flag set then the receiver = MUST drop=20 the message and report an error to the sender if it = doesn't=20 recognize the=20 TLV.</FONT> </SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>If a the = receiver=20 expects a "mandatory" TLV but doesn't receive = it, the=20 message MUST be droped and an error=20 report sent to=20 = the sender.</FONT> </SPAN></FONT></FONT></FONT></SPAN></SPAN></= FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2>OR</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT = size=3D2>(2) if flag is=20 set to"mandatory", then the *sender* MUST include it in = the=20 message for which it is defined<SPAN=20 class=3D560491614-28042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>The = sender MUST=20 include mandatory TLVs as defined by the=20 = protocol-spec/applications.</FONT></SPAN></FONT></FONT></FONT></SPAN></DI= V> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 face=3DArial color=3D#0000ff size=3D2>The current = protocols draft says=20 for certain TLVs that they are mandatory, but that applies = to the=20 sender of it (interpretation 2).  The flag would = indicate=20 interpretation 1 (like for Radius = VSAs?)?</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>If the = higher order=20 bit is set to "0" means that it is mandatory, then = currently=20 defined optional defined TLVs suddenly become mandatory = which is=20 not good.<SPAN class=3D560491614-28042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>Woj> = Only the=20 currently used TLVs become mandatory. If they are not = used/implemented we can re-define them as optional (set = flag to 1)=20 at no cost. = </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2>But I = would first to=20 understand the exact meaning of this mandatory flag.  = Defining such a flag indeed looks useful but then as=20 interpretation 1, and I would say that if flag set to 1, = then it=20 is mandatory and actually, it is possible that a TLV is = sent=20 sometimes as optional and sometimes as mandatory.<SPAN=20 class=3D560491614-28042008><FONT=20 = color=3D#000000> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D560491614-28042008><FONT color=3D#000000>Woj> = Precisely,=20 that is possible on a per application = basis.</FONT> <FONT=20 color=3D#000000>Having the flag would make troubleshooting = of a=20 message flow much more explicit (today, with any=20 problem one has to browse the drafts to figure out = what MUST=20 be there vs what SHOULD be there all while = looking what=20 is actually = there)</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 = size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 = size=3D2><SPAN=20 = class=3D560491614-28042008>Regards,</SPAN></FONT></FONT></FONT></SPAN></D= IV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 = size=3D2><SPAN=20 = class=3D560491614-28042008>Woj.</SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 color=3D#0000ff><FONT face=3DArial><FONT color=3D#000000 = size=3D2><SPAN=20 = class=3D560491614-28042008></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2>regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D487325113-28042008><FONT=20 face=3DArial color=3D#0000ff = size=3D2>Stefaan</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT> </DIV><BR> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> = ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of = </B>Wojciech Dec=20 (wdec)<BR><B>Sent:</B> donderdag 24 april 2008 = 14:19<BR><B>To:</B>=20 Busser, M; ancp@ietf.org<BR><B>Cc:</B> Haag, = T<BR><B>Subject:</B>=20 Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol=20 proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D709295811-24042008><FONT=20 face=3DArial size=3D2>Hi Michael,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D709295811-24042008><FONT=20 face=3DArial size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D709295811-24042008><FONT=20 face=3DArial size=3D2>inline...</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: = #000000 2px solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> = ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] <B>On Behalf Of = </B>Busser,=20 M<BR><B>Sent:</B> 24 April 2008 13:13<BR><B>To:</B>=20 ancp@ietf.org<BR><B>Cc:</B> Haag, T<BR><B>Subject:</B> = Re:=20 [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol=20 proposal<BR></FONT><BR></DIV> <DIV></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Hi=20 Woi, all</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>I=20 see the problem but i can not see, how an additional = flag will=20 help solving this problem.</FONT></SPAN></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Lets=20 assume your first proposal.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT = face=3DArial><FONT=20 size=3D2>If an implementation does not send the=20 complete TLV, even it is defined to=20 be mandatory, I would call this a bug = and I can=20 not see, how an additional flag can help here.<SPAN=20 = class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT = face=3DArial><FONT=20 size=3D2><SPAN=20 = class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT = face=3DArial><FONT=20 size=3D2><SPAN class=3D709295811-24042008>Woj> The = way it helps,=20 and other protocols bear proof of this scheme, is that = it is=20 easier for implementations to reconcile errors resulting = out of=20 "Mandatory" and "Optional" TLV sets. The key to = this lies=20 on a per application basis. One application may mandate = TLV A=20 for operation, while another might not. Resolving such = issues=20 when implementing or troubleshooting multiple = applications is=20 not always trivial. </SPAN></FONT></FONT></SPAN><SPAN=20 class=3D364043506-24042008><FONT face=3DArial><FONT = size=3D2><SPAN=20 = class=3D709295811-24042008></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT = face=3DArial><FONT=20 size=3D2><SPAN=20 = class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Your=20 second proposal seems obviously be required to keep = existing things working, if we agree on your = first=20 proposal. </FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>But=20 from my point of view it also assumes, that all = existing=20 implementations are using the same set of TLVs now.=20 </FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT = face=3DArial><FONT=20 size=3D2>And I am not sure = about that. <SPAN=20 = class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT = face=3DArial><FONT=20 size=3D2><SPAN=20 = class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT = face=3DArial><FONT=20 size=3D2><SPAN class=3D709295811-24042008>Woj> This = would be a=20 good thing for the WG to discuss. There most evidently = is a fair=20 amount of "dead wood" in the current spec, ie stuff = that=20 nobody yet implements or cares about.  In the = former=20 case, we could re-cast that material using the new=20 notions/extensions, in the latter case simply chop it=20 out.</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2><SPAN class=3D364043506-24042008><FONT = face=3DArial=20 color=3D#0000ff = size=3D2></FONT></SPAN> </DIV></FONT></SPAN> <DIV><SPAN class=3D364043506-24042008><FONT = face=3DArial><FONT=20 size=3D2>Therefore I disagree with your first proposal. = I=20 recommend, the better way will be to be more = precise in=20 definitions.<SPAN=20 = class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>In=20 my mind, it is a bug, if a mandatory TLV is missing. It = is up to=20 the robustness of the implementation to deal with = this=20 situation.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT = face=3DArial><FONT=20 size=3D2>Is it really neccesary to define the behavior = of a=20 network element in this case of failure in the ancp = protocol=20 itself? <SPAN=20 = class=3D709295811-24042008> </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT = face=3DArial><FONT=20 size=3D2><SPAN=20 = class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT = face=3DArial><FONT=20 size=3D2><SPAN class=3D709295811-24042008>Woj> Other = people have=20 faced this problem before, and I would rather go with = the=20 lessons they learned, rather than clinging to hopes of = perfect=20 textual definitions and implementations. Other than = backwards=20 compatibility, I do not see in your statements a valid=20 reason to object to the 1st proposal, = particularly for=20 new applications since it can only make things more = robust. The=20 counter argument of being precise in the definitions, as = evidenced by the current spec, is admirable and needs to = be=20 there, with this proposal providing an extra level of = robustness=20 and visibility of any problems.=20 </SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT = face=3DArial><FONT=20 size=3D2><SPAN=20 = class=3D709295811-24042008></SPAN></FONT></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT = face=3DArial><FONT=20 size=3D2><SPAN=20 = class=3D709295811-24042008>Thanks,</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT = face=3DArial><FONT=20 size=3D2><SPAN=20 = class=3D709295811-24042008>Woj.</SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>If=20 optional TLVs are not present in a message, we should = describe=20 some kind of default behaviour, as you already=20 stated.</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2></FONT></SPAN> </DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Comments on=20 = draft-ietf-ancp-protocol-02.txt:</FONT></SPAN></DIV></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT = size=3D2><FONT=20 face=3DArial>It is not clearly stated, if the TLV=20  "<SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New = Roman'; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: = EN-GB; mso-fareast-language: DE; mso-bidi-language: AR-SA">DSL=20 Line Attributes "<FONT face=3DArial> is mandatory or = optional.=20 </FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT = size=3D2><FONT=20 face=3DArial><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New = Roman'; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: = EN-GB; mso-fareast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>In fact it is mandatory because some of its = SubTLVs=20 are mandatory. </FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT = size=3D2><FONT=20 face=3DArial><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New = Roman'; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: = EN-GB; mso-fareast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>We should spent a sentence to make this=20 clear.</FONT></SPAN></FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2><SPAN class=3D364043506-24042008><FONT = size=3D2><FONT=20 face=3DArial>It is not clearly stated, if the TLV=20  "<SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New = Roman'; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: = EN-GB; mso-fareast-language: DE; mso-bidi-language: = AR-SA">Service-Profile-Name"<FONT=20 face=3DArial> is mandatory or=20 = optional.</FONT></SPAN></FONT></FONT></SPAN></FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2><SPAN class=3D364043506-24042008><FONT = size=3D2><FONT=20 face=3DArial><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New = Roman'; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: = EN-GB; mso-fareast-language: DE; mso-bidi-language: AR-SA"><FONT=20 face=3DArial>I prefer mandatory because it is essetial = for the use=20 case Line=20 = Config. </FONT></SPAN></FONT></FONT></SPAN></DIV></FONT></SPAN><SPAN= =20 class=3D364043506-24042008><FONT face=3DArial = size=3D2></FONT></SPAN> <DIV><SPAN class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Section 5.4.3 Line Config, where the TLVs are = mentioned=20 (page 35):</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>  ...defined in section = 5.4.1....   =20 must be corrected to    ...defined in = section=20 5.4.2........</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT size=3D2> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>Section 5.4.4 OAM, where the TLVs are = mentioned=20 (page 36 and page 38):</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2>  ...defined in section = 5.4.1....   =20 must be corrected to    ...defined in = section=20 5.4.2........</FONT></SPAN></DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = size=3D2></FONT></SPAN> </DIV> <DIV></FONT></SPAN><SPAN = class=3D364043506-24042008><FONT=20 face=3DArial size=3D2></FONT></SPAN> </DIV></DIV> <DIV><SPAN class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008></SPAN><SPAN=20 class=3D364043506-24042008><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D364043506-24042008><FONT face=3DArial = color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV align=3Dleft><FONT color=3D#000080 size=3D2> <P align=3Dleft>Best Regards; Freundliche Gr=FC=DFe=20 </P></FONT><B><FONT color=3D#000080> <P>Michael Busser</P></B></FONT><FONT size=3D1> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt">T-Systems Enterprise Services = GmbH=20 </SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT size=3D1>Production Line = Network=20 Centric Systems</FONT></SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT size=3D1>ICT-Systems=20 Integration</FONT></SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT size=3D1>Network = Integration=20 Services</FONT></SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT size=3D1></FONT><SPAN=20 style=3D"COLOR: navy"></SPAN><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy"><FONT = face=3DArial=20 color=3D#000000 = size=3D2></FONT></SPAN></SPAN> </DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy"><FONT = color=3D#000000=20 size=3D1>Br=FCckes 2 -8, 55545 Bad Kreuznach<BR>Postfach = 9100, 55541=20 Bad Kreuznach<BR>+49 671 8333 8911 (Phone)<BR>+49=20 521 9210 3859 (Fax)<BR>+49 151 1211 9689=20 (Mobile)<BR>E-Mail: <A=20 = href=3D"mailto:michael.busser@t-systems.com">michael.busser@t-systems.com= </A></FONT></SPAN></DIV></SPAN> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"> <DIV class=3DO=20 style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN></DIV><SPAN=20 style=3D"FONT-SIZE: 8pt">Internet: </SPAN><SPAN=20 style=3D"FONT-SIZE: 8pt"><p:onmouseclick=20 href=3D"http://www.t-systems.com/"=20 hyperlinktype=3D"url"></p:onmouseclick><A=20 onclick=3Dwindow.event.cancelBubble=3Dtrue;=20 href=3D"http://www.t-systems.com/" = target=3D_parent><FONT=20 = color=3D#6699ff>http://www.t-systems.com</FONT></A></SPAN><SPAN=20 style=3D"FONT-SIZE: 8pt"> </SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN> </DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT size=3D3><FONT = size=3D1><SPAN=20 style=3D"FONT-SIZE: 7.5pt; COLOR: black; FONT-FAMILY: = Arial">T-Systems=20 Enterprise Services GmbH<BR>Aufsichtsrat: Ren=E9 = Obermann=20 (Vorsitzender)<BR>Executive Committee: Reinhard Clemens=20 (Vorsitzender)*, Helmut Binder, Albert Henn, Olaf = Heyden*,=20 Katrin Horstmann, Ulrich Kemp, Wilfried Peters*,<BR>Dr. = Herbert=20 Schaaff*, Zvezdana Seeger*<BR>Handelsregister: = Amtsgericht=20 Frankfurt am Main HRB 55933<BR>Sitz der Gesellschaft: = Frankfurt=20 am Main<BR>WEEE-Reg.-Nr. = DE87523644<BR>*Gesch=E4ftsf=FChrer gem. =A7=20 35 GmbHG</SPAN></FONT></FONT></SPAN></DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 face=3DArial size=3D2></FONT></SPAN></SPAN> </DIV> <DIV class=3DO=20 style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1>Notice: This transmittal and/or attachments may = be=20 privileged or confidential. If you are not the intended=20 recipient, you are hereby notified that you have = received this=20 transmittal in error; any review, dissemination, or = copying is=20 strictly prohibited. If you received this transmittal in = error,=20 please notify us immediately by reply and immediately = delete=20 this message and all its attachments. Thank you. = </FONT><FONT=20 size=3D1><BR>T-Systems =96 Business flexibility=20 </FONT></DIV></SPAN></SPAN> <DIV><FONT face=3DArial = size=3D2></FONT> </DIV></FONT></DIV> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"> <DIV></DIV> <DIV class=3DOutlookMessageHeader lang=3Dde dir=3Dltr = align=3Dleft> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy = size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: = Arial"><o:p></o:p></SPAN></FONT></P><FONT=20 face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"><FONT face=3DArial = size=3D2></FONT> <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" = SIZE=3D2> </SPAN></FONT></DIV> <DIV class=3DSection1> <DIV> <P class=3DMsoNormal><B><FONT face=3DTahoma = size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; = FONT-FAMILY: Tahoma">Von:</SPAN></FONT></B><FONT=20 face=3DTahoma size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">=20 ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] = <B><SPAN=20 style=3D"FONT-WEIGHT: bold">Im Auftrag von = </SPAN></B>Wojciech=20 Dec (wdec)<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Gesendet:</SPAN></B> = Mittwoch, 23.=20 April 2008 14:54<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">An:</SPAN></B>=20 ancp@ietf.org<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Betreff:</SPAN></B> [ANCP] = Mandatory=20 TLVs in draft-ietf-ancp-protocol=20 proposal</SPAN></FONT><o:p></o:p></P></DIV> <P class=3DMsoNormal><FONT face=3D"Times New Roman" = size=3D3><SPAN=20 style=3D"FONT-SIZE: = 12pt"><o:p> </o:p></SPAN></FONT></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi=20 All,</SPAN></FONT><SPAN lang=3DEN-GB> = </SPAN><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial">Continuing with=20 the series of e-mails regarding basic protocol issues = still to=20 be addressed, I now would now like to ask your = feedback=20 regarding the distinction the protocol places on = mandatory=20 TLVs. Given the length of this mail I'll first cut to = the=20 proposal, and after it you can find the problem=20 description.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The = proposal which=20 I am putting in front of the WG is to define a new TLV = format=20 which contains at a minimum a Mandatory flag (much = like Radius=20 VSAs do). We could have this TLV Flag be defined only = for new=20 applications.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">A second = proposal=20 would be try to make this flag work with existing ones = by for=20 example defining the highest order bit of the TLV# = field to=20 mean "Mandatory" when set to "0". This would be = invisible to=20 exiting implementations, but newer ones may have = problems in=20 communicating with older ones when the latter do not = send all=20 TLVs. But that can also be addressed by simply forming = the set=20 of mandatory TLVs to be the ones that all = implementations=20 currently send by = default.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Without = additional=20 feedback, I will assume that the WG is fine with the = first=20 proposal, and also with the 2nd one conditional on = deriving a=20 suitable "commonly used" TLV = set.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The = problem in=20 more detail: </SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial">Currently the=20 situation is that Mandatory TLVs are only stated to be = as such=20 in the body of the protocol draft spec, with an = implementer=20 having to scour fairly attentively the text. Eg "Type=20 (Access-Loop-Circuit-ID =3D 0x01): This is a mandatory = TLV",=20 etc.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The = behaviour of=20 an implementation that receives a message with a = missing=20 mandatory TLV is not defined at all, and the opposite = is=20 handled but not very robustly, i.e. when receiving a = TLV but=20 not recognizing it, and implementation is free to = discard it=20 (even if it is mandatory!). This is a recipe for=20 interoperability problems and an implementation mine=20 field.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">This = problem is=20 complicated by different applications. For example the = current=20 OAM section states the following regarding TLVs that = are to be=20 carried in the request message (my=20 italics):</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial">"</SPAN></FONT>=20 <BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = 'Courier New'">Following=20 TLVs<B><I><SPAN style=3D"FONT-WEIGHT: bold; = FONT-STYLE: italic">=20 can</SPAN></I></B> appear in this message:=20 </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = 'Courier New'">      =20 o Type (Access-Loop-Circuit-ID =3D 0x01) : defined in = section=20 5.4.1    </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = 'Courier New'">      =20 o Type (Access-Aggregation-Circuit-ID-Binary =3D = 0x06): defined=20 in </SPAN></FONT><BR><FONT face=3D"Courier New" = color=3Dblack=20 size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = 'Courier New'">        =20 section 5.4.1. </SPAN></FONT><BR><FONT face=3D"Courier = New"=20 color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = 'Courier New'"> </SPAN></FONT>=20 <BR><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = 'Courier New'">      =20 o Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03): = defined=20 in section </SPAN></FONT><BR><FONT face=3D"Courier = New"=20 color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = 'Courier New'">        =20 5.4.1.  </SPAN></FONT><o:p></o:p></P> <P><FONT face=3D"Courier New" color=3Dblack = size=3D2><SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = 'Courier New'">      =20 o Type (OAM-Loopback-Test-Parameters =3D 0x07): = Parameters=20 related to  </SPAN></FONT><BR><FONT = face=3D"Courier New"=20 color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = 'Courier New'">        =20 loopback test. This is an optional TLV. If this TLV is = not=20 present </SPAN></FONT><BR><FONT face=3D"Courier New" = color=3Dblack=20 size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = 'Courier New'">        =20 in the request message, the DSLAM SHOULD use locally=20 determined </SPAN></FONT><BR><FONT face=3D"Courier = New"=20 color=3Dblack size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = 'Courier New'">        =20 default values for the test parameters. =20 </SPAN></FONT><BR><FONT face=3D"Courier New" = color=3Dblack=20 size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = 'Courier New'">"</SPAN></FONT>=20 <BR><FONT face=3DArial color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = Arial">(NOTE:=20 The last "SHOULD" appears to be inappropriate. If the = TLV is=20 missing, the DSLAM MUST have some default parameters, = or=20 return an error)</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = Arial">The=20 "can" above indicates that they're all optional, while = clearly=20 the application cannot run its course without one or = more of=20 these fields. Here we have a case where one could have = a=20 perfectly compliant implementation that ignores all = these=20 TLVs=85</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial color=3Dblack size=3D2><SPAN = lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = Arial">-Woj.</SPAN></FONT><SPAN=20 lang=3DEN-US> </SPAN><o:p></o:p></P> <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: = 12pt"><FONT=20 face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: = 12pt"><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><o:p></o:p></SPAN></FONT></= P></DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE>= </BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C8AA2B.B969F0C3-- --===============1709113559== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============1709113559==-- From ancp-bounces@ietf.org Tue Apr 29 22:41:22 2008 Return-Path: <ancp-bounces@ietf.org> X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0BFB3A6C96; Tue, 29 Apr 2008 22:41:21 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A8013A6C96 for <ancp@core3.amsl.com>; Tue, 29 Apr 2008 22:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8d+LjJeCw8P for <ancp@core3.amsl.com>; Tue, 29 Apr 2008 22:40:48 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 8A5C83A6A6E for <ancp@ietf.org>; Tue, 29 Apr 2008 22:40:35 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Tue, 29 Apr 2008 22:40:11 PDT Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Apr 2008 22:39:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 01:39:53 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C28102EAC9B@proton.jnpr.net> In-Reply-To: <D9872168DBD43A41BD71FFC4713274D404FF1751@xmb-ams-33b.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal Thread-Index: AcilQRMfK4kdawUKQOWs5fdBngS8QQAAr04QACRhApAAC0ujAADNHRywAADiEXAAAbhxoAAAWwcQACIOoKAAAXsqYAASvbCgAAE4sjAAASS6UAABRQpQABPWDgA= References: <1B6169C658325341A3B8066E23919E1C01230DC1@S4DE8PSAANK.mitte.t-com.de><1B6169C658325341A3B8066E23919E1CFBC5C4@S4DE8PSAANK.mitte.t-com.de><D9872168DBD43A41BD71FFC4713274D404FA6ACC@xmb-ams-33b.emea.cisco.com><7A6D4815C5E8F74988784FEBD50F2F1E01ABAA16@FRVELSMBS22.ad2.ad.alcatel.com><D9872168DBD43A41BD71FFC4713274D404FF10C1@xmb-ams-33b.emea.cisco.com><7A6D4815C5E8F74988784FEBD50F2F1E01ABAAA4@FRVELSMBS22.ad2.ad.alcatel.com><D9872168DBD43A41BD71FFC4713274D404FF1233@xmb-ams-33b.emea.cisco.com><7A6D4815C5E8F74988784FEBD50F2F1E01ABAC34@FRVELSMBS22.ad2.ad.alcatel.com><D9872168DBD43A41BD71FFC4713274D404FF13AD@xmb-ams-33b.emea.cisco.com><48C276B536524E478C659685995F6AA539DBB4F194@RBSJX.ad.redback.com><D9872168DBD43A41BD71FFC4713274D404FF172D@xmb-ams-33b.emea.cisco.com><48C276B536524E478C659685995F6AA539DBB4F25F@RBSJX.ad.redback.com> <D9872168DBD43A41BD71FFC4713274D404FF1751@xmb-ams-33b.emea.cisco.com> From: "Sanjay Wadhwa" <swadhwa@juniper.net> To: "Wojciech Dec (wdec)" <wdec@cisco.com>, "Peter Arberg" <parberg@redback.com>, "DE CNODDER Stefaan" <stefaan.de_cnodder@alcatel-lucent.be>, "Busser, M" <Michael.Busser@t-systems.com>, <ancp@ietf.org> X-OriginalArrivalTime: 30 Apr 2008 05:39:57.0208 (UTC) FILETIME=[9FB7B180:01C8AA84] Cc: "Haag, T" <Thomas.Haag@t-systems.com> Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list <ancp.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/ancp> List-Post: <mailto:ancp@ietf.org> List-Help: <mailto:ancp-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1012658706==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1012658706== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8AA84.9E486A6F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8AA84.9E486A6F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Woj I agree only on the following: =20 1. A TLV might be mandatory for one application or use-case, and = optional for another application. We do need to clearly specify in the = draft if a TLV is mandatory or optional for a given application (which = boils down to specifying this per ANCP message and message type). 2. We should clearly specify the behavior for handling missing mandatory = TLVs in received messages. =20 To me the utility of flagging a TLV as mandatory or optional via the = protocol is at best debatable. If a buggy implementation on the sender = incorrectly sets a "known" TLV as mandatory (when it is not) or = vice-versa, do we want the receiver to infer the handling of this TLV = based on what the sender tells it? I don't think so. Ideally, we want = the receiver and sender to have a common understanding of what is = mandatory and what is optional based on what is in the spec, and handle = the TLV based on that understanding. As Peter mentions, the spec clearly = spells out TLVs that are mandatory and optional. Also, I don't see a = major advantage of your proposal with respect to debuggability. =20 Typical case where it does make sense for the sender to set some flag in = the TLV to control the handling of the TLV on the receiver is for = "unrecognized" TLV types...e.g. 1. Receiver is an intermediate node, which consumes the message but also = needs to forward it along to other nodes. Here the sender can flag the = handling of the TLV to the receiver (e.g. discard or forward if the TLV = type is not recognized by the receiver). This doesn't quite apply to = ANCP (messages are confined to be between two peers). =20 2. If handling of an unrecognized TLV on the receiver needs to be = different for an optional TLV versus a mandatory TLV. Here the receiver = doesn't understand the TLV type, but can infer the handling based on the = flag in the TLV. However, do we want the treatment of "unrecognized" = TLVs on the receiver to be different for optional and mandatory TLVs = (e.g. silently discard an unrecognized optional TLV...but discard and = also send an error back for an unrecognized mandatory TLV). I don't = think this is necessary. However, if we do want to do this, then may be = the flag in the TLV should explicitly indicate the handling for the TLV = (e.g. "silently discard if un-recognized" versus "discard and send an = error back")...as opposed to just flagging these as "mandatory" versus = "optional". =20 Woj> Of course it is, the whole spec is about this. The problem comes = when people start to re-use well known TLVs for different applications, = and then trying to make sense of it all >becomes non-trivial. Why do you = think both BGP and Diamater, and a number of other protocols have = definied "Mandatory" flags? Just for kicks? It's a well known protocol = design tool, that >comes handy when re-using same data across multiple = applications. =20 We should look at why these protocols are doing this (as opposed to = blindly following). For a counter example, please take a look at OSPF = traffic engineering extensions (RFC 3630).=20 =20 Cheers -Sanjay =20 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = Wojciech Dec (wdec) Sent: Tuesday, April 29, 2008 3:03 PM To: Peter Arberg; DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal =20 Hi Peter, =20 continued inline... =20 =09 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = Peter Arberg Sent: 29 April 2008 20:39 To: Wojciech Dec (wdec); DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal Hi Woj, =20 please see inline in your answers =20 =20 =09 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: 29. april 2008 11:07 To: Peter Arberg; DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal Hi Peter, =20 =20 =20 =09 ________________________________ From: Peter Arberg [mailto:parberg@redback.com]=20 Sent: 29 April 2008 19:34 To: Wojciech Dec (wdec); DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal Hi Woj, =20 I agree with Michael and Stefan on this issue, I do not see a need to = change the existing implementation with a mandatory/optional flag.=20 =20 Woj> Please indicate where in my proposal did you see anything about = changing existing implementaions? =20 =20 PAR> I might have misunderstood your email, but I read it as if you = suggest a high bit value in existing TLV's to be interpreted as a mandatory flag.=20 =20 Woj#2> Yes, I suggested (in proposal 2) that *if* the WG found there to = be a common set of TLVs currently in use, then the high-order bit set to = "0" (ie as today) could be interpreted as "mandatory", and the rest of = the TLV's redefined with a high order "1". To extsing implementations, = the "new" TLVs would just look like a different TLV#, while anyone = wishing to implement the more robust error cheking logic based on this = bit, would be free to do so.=20 =20 If you are simply talking about new capability type definitions, then = why do you not bring up the additional flag in a new internet-draft defining what capability = type you have in mind ?=20 =20 Woj#2> No, a new capability was not intended, but could also be = considered. =20 =20 I think I understand your arguments, but I do not agree with them. I = think most places in the draft it is clear what is defined as mandatory and optional.=20 =20 I agree on the point we need to go through the draft and make = clarifications to what TLV's in what capability types are mandatory and optional, and make more = description what should happen if mandatory TLVs are not included.=20 =20 Woj> Exactly.=20 =20 I think the DSLF TR-101 document has a good example of such a = description in it's=20 "Table 3 - Access loop characteristics sub-options", and I think if = we do the same for each capability types TLV's in the ANCP draft it will be a good help. =20 Woj> Indeed, pre-ceeded by some rationalization. The appears to be no = reason for some of the DSLF "mandatory" TLVs.=20 =20 PAR> I do not see a problem with re-visit in the draft if a TLV should = be optional or mandatory, so if that is the intend, then I'm all for an email discussion on a TLV by = TLV basis if we think it is a=20 manfdatory or optional information inside the specific capability type. = =20 Woj#2> Great, because any change to the mandated set *will* affect = existing implementation . =20 =20 =20 I do not agree with your point that it is not listed if "rate" is = mandatory or optional, it is clearly listed as a mandatory TLV, and as such it should be included in the = port up message, I really do not understand what confusion you have with this.=20 =20 Woj> The text states: =20 =20 5. Type (DSL Line Attributes =3D 0x04):=20 Length : variable (up to 1024 bytes)=20 Value : This consists of one or more Sub-TLVs corresponding to DSL=20 line attributes. No sub-TLVs other than the "DSL type" and "DSL=20 line state" SHOULD be included in a PORT DOWN message.=20 The general format of the sub-TLVs is identical to the general TLV=20 format. The value field in each sub-TLV is padded to a 4-octet=20 alignment. The Length field in each sub-TLV contains the actual=20 number of bytes in the TLV (not including the padding if present).=20 Current defined sub-TLV types are start from 0x81. =20 Maybe you can point me to where exatly it is stated clearly as being = mandatory, or otherwise explain why you "not agree"? =20 =20 PAR> I think you forgot to read the most important part where the = actual TLV is defined.=20 =20 Woj#2> I didn't. This part talks about the sub-TLV, not the main TLV = 0x04. Do you see my point now? =20 =20 Type (Actual-Net-Data-Upstream =3D 0x81): Actual upstream net data rate = on a DSL line.=20 This is a mandatory TLV. =20 =20 Length : (4 bytes)=20 Value : (Rate in Kb/sec)=20 =20 Type (Actual-Net-Data-Rate-Downstream =3D 0x82) : Actual downstream net = data rate on a DSL line.=20 This is a mandatory TLV.=20 =20 Length : (4 bytes)=20 Value : (Rate in Kb/sec)=20 =20 =20 The fact you say "Port UP" and "OAM" is best considered as legacy = applications, I have some trouble with this as well, since ANCP running in production networks = use them, and as such it is a central part of the ANCP specifications we need to finish as = soon as possible.=20 =20 Woj> I should have said legacy applications from a protocol messaging = perspective, not usage, nor support. It's quite clear that GSMP derived = messaging has baggage that is un called for in new applications. =20 I think Stefaan's example is very valid, that we do not need to make = mandatory requirements to=20 what receivers of ANCP information use such info. for. I don't think = we should try and make the ANCP specifications "mandatory" for box behavior, I think it is much = more important for the=20 working group to make the protocol specifications easy to understand = and get the first documentation finish and published, so the protocol can be used for different sets = of applications, and make sure new applications can be added later.=20 =20 Woj> Indeed the aim of the WG to define a protocol that is relatively = simple and easy to understand, not just to implementers but also to = people using it, and across vendors. Currently, having anyone operating = the device be familiar in what cases a TLV is mandatory and in what = optional requires a thorough understanding of the spec, across = applications. This is not easy, but I'll conceede that for the = applications implemented so far we could live with it.=20 =20 I do think that by documenting if a TLV is mandatory or optional = inside a specific capability type, it is easy to understand what must be sent to support the defined = application/capability type.=20 =20 Woj> Of course it is, the whole spec is about this. The problem comes = when people start to re-use well known TLVs for different applications, = and then trying to make sense of it all becomes non-trivial. Why do you = think both BGP and Diamater, and a number of other protocols have = definied "Mandatory" flags? Just for kicks? It's a well known protocol = design tool, that comes handy when re-using same data across multiple = applications.=20 =20 PAR> I might be wrong, but I think I can find as many or more protocol = examples who do not include a mandatory/optional flag, so examples can always be found which will = support the point you are trying to make. =20 I do not see a problem with a new internet-draft which defines new = capability-types and where a TLV mandatory flag is included, I do see a problem if the intend is to try = and adjust what already exist. =20 =20 Woj#2> Ok, so if adjusting is only scoped to what doesn't exist, as my = proposal laid out conditionally, you're fine. =20 =20 =20 Then if anybody want to include new capability types or sub-TLVs = later to address specific applications, then I think changes can be discussed at that time instead of trying = to change existing protocol implementations.=20 =20 Woj> Again I ask, where in the proposal did you see *anything* = requiring a change to an existing implementation. Please be specific. I = see that your main objection is on this issue, which means that you = accept proposal 1 (have such a flag for new TLVs/apps). It would also be useful if you indicated whether the list of TLVs = provided below is what you'd expect to be the minimum mandatory set.=20 =20 PAR> at the moment I read the draft as having defined the TLVs = mandatory as you describe, except I also read it as the dsl-type =3D 0x91 must be part of the port down. = If this is needed or not is a different discussion. =20 =20 Woj#2> Ok. Thanks. But please do come back to me if you see that the = proposal impacts an exiting implementation. I conclude that there is no = problem with doing changes to stuff that isn't currently used. Woj. =20 cheers, Peter=20 =20 Cheers, Woj. =20 cheers, Peter =20 =20 =20 =20 =09 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = Of Wojciech Dec (wdec) Sent: 29. april 2008 02:28 To: DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal Stefaan, =20 a number of points: 1. There currently is to my knowledge no implementation of ANCP = there that doesn't send the DSL Line attributes info by default in = Port-UP messages? The support of HS on the NAS is an orthogonal issue. 2. The current ancp protocol draft (02) doesn't say whether the rate = info is optional or mandatory, it only states that the sub-TLVs are = mandatory. Based on this, an implementer can be justified to expect = port-ups to *always* have the rate-info tlv (ie treat them as = mandatory). Equally, she's justified in considering this as optional. 3. The port-up and OAM are best considered as legacy applications = for ANCP. The re-use of any of the GSMP defined fields is already out of = the question due to constrains put in place by the existing use-case = messaging. Needless to say, this wasn't as thoroughly designed as it = should have been, and with the OAM and port-up apps being coupled. 4. It's up to the application to define what TLVs are mandatory and = which aren't, as you also state. The AN does not need to know what the = NAS will do with the info, BUT it needs to send the right TLVs for the = application (eg if we had a hypothetical AN that only sends Port-up's = with line-id, it would be next to useless for the dynamic shaping = application). =20 With all this in mind it's useful to re-read what I proposed = originally below regarding the mandatory flag: 1. "have this TLV Flag be = defined only for new applications" and 2. The notion of the mandatory = flag applying to existing TLVs being "conditional on deriving a = suitable "commonly used" TLV set." The latter point would ensure that = existing implementations do not need to change, but future ones can take = advantage of the extra robustness. =20 Hence, can the WG derive a set of commonly used, i.e. always used, = TLVs for existing implementations? The list I came up is as follows (making them pretty much mandatory = TLVs if it agrees with the views of others); =20 Port-up message (0x80); Extension-TLV (dsl tech type) Access-Loop-circuit-id (0x01) DSL Line Attribute (0x04) with the following sub TLVs; DSL-Type =3D 0x91; Actual-Net-Data-Upstream =3D 0x81; = Actual-Net-Data-Rate-Downstream =3D 0x82 =20 Port-down message (0x81); Extension TLV (dsl tech type) Access-Loop-circuit-id (0x01) DSL Line Attribute (0x04) with the following sub TLVs; DSL line state =3D 0x8F =20 All other TLVs are optional. =20 Would appreciate confirmation from the WG regarding the above. =20 Thanks, Woj. =20 =20 =09 ________________________________ From: DE CNODDER Stefaan = [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Sent: 29 April 2008 09:52 To: Wojciech Dec (wdec); Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =20 Hi Woj, =20 Take the following example: I have a network with 2 NASses, NAS-A = is doing hierarchical shaping, NAS-B just wants to have the port = information but is not doing hierarchical shaping (it is doing other = things like OAM, ...). This means NAS-A needs the bandwidth, while = NAS-B does not need the bandwidth. How should the flag be set in this = case by the AN? Set to 'Mandatory' for the port up messages to NAS-A, = and set to 'Optional' for port up messages towards NAS-B? Or is it = always set to 'Mandatory'? From your answer below, I understand that it = should be set to 'Optional' towards NAS-B. Is that correct? =20 NAS-B will simply ignore the bandwidth TLV. If such a flag would = exist, and the flag is set to 'Mandatory' by the AN to NAS-B, what = should be the behavior of NAS-B? Should it reject the whole message? = Maybe NAS-B is not supporting hierarchical shaping, so it might not = support the bandwidth TLV. Today, the bandwidht TLV is only mandatory = to be put in the port up messages, but for the receiver there is nothing = mandatory. =20 I believe the original intend of ANCP was that the AN does not need = to know what the NAS is doing with this information, the use of the = bandwidth is also not specified by ANCP, only an example is given (which = is shaping). In the future there may be applications for which TLVs = will be mandatory which are now optional. =20 regards, Stefaan =20 =20 =20 =20 =09 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: maandag 28 april 2008 21:33 To: DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =20 =20 =09 ________________________________ From: DE CNODDER Stefaan = [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Sent: 28 April 2008 17:15 To: Wojciech Dec (wdec); Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =20 Take the bandwidth sub-TLV in port up messages as example. The = current protocol spec says that it is mandatory to be sent in port up = messages. that's ok. But it is not mandatory for the receiver to = process the bandwidth sub-TLV. What is done with this information by = the NAS is not specified by ANCP, so you cannot make it mandatory for = the receiver side.=20 =20 Woj> Is the information required by the application? It would = appear for the dynamic shaping use-case to be most certainly so. Hence = it is absolutely mandatory, otherwise the message makes no sense for the = application. In any case, if=20 =20 So it looks to me that the flag can only indicate what the receiver = should do. Then the flag makes sense.=20 =20 Woj> The flag tells the receiver what info the sender thinks is = required to carry out the application. This in almost all cases has to = match up to what the receiver thinks is required. The sender doesn't = tell the receiver what to do with the info. =20 If the receiver knows what is mandatory, then I do not see a reason = why this has to be made explicit in the protocol. It would only = complicate the protocol. As already said by Michael: if a mandatory TLV = is not there, then it is just a bug.=20 =20 Woj> Can you specifically describe what aspect of the protocol does = it complicate? It's just making explicitly clear what the protocol = already has to implement anyway to be of any use. As to whether it is a bug, having such explicit marking makes it = clear what/where the problem is when observing a messaging flow vs a lot = of deduction work. In any case, the other point being made here is that = today the protocol does NOT specify what should happen if a mandatory = TLV is missing. =20 -Woj. =20 regards, Stefaan =20 =20 =20 =09 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: maandag 28 april 2008 16:28 To: DE CNODDER Stefaan; Busser, M; ancp@ietf.org Cc: Haag, T Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal It's actually a mix of both. Inline... =20 =09 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On = Behalf Of DE CNODDER Stefaan Sent: 28 April 2008 16:04 To: Wojciech Dec (wdec); Busser, M; ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal =20 Hi, =20 This new mandatory flag, what is exactly its meaning? =20 (1) if flag set to "mandatory", then the *receiver* of this TLV = MUST process it, and if unrecognized must drop the message=20 =20 If a received TLV is has the "mandatory" flag set then the receiver = MUST drop the message and report an error to the sender if it doesn't = recognize the TLV.=20 If a the receiver expects a "mandatory" TLV but doesn't receive it, = the message MUST be droped and an error report sent to the sender.=20 =20 OR =20 (2) if flag is set to"mandatory", then the *sender* MUST include it = in the message for which it is defined=20 =20 The sender MUST include mandatory TLVs as defined by the = protocol-spec/applications. =20 The current protocols draft says for certain TLVs that they are = mandatory, but that applies to the sender of it (interpretation 2). The = flag would indicate interpretation 1 (like for Radius VSAs?)? =20 If the higher order bit is set to "0" means that it is mandatory, = then currently defined optional defined TLVs suddenly become mandatory = which is not good.=20 =20 Woj> Only the currently used TLVs become mandatory. If they are not = used/implemented we can re-define them as optional (set flag to 1) at no = cost.=20 =20 But I would first to understand the exact meaning of this mandatory = flag. Defining such a flag indeed looks useful but then as = interpretation 1, and I would say that if flag set to 1, then it is = mandatory and actually, it is possible that a TLV is sent sometimes as = optional and sometimes as mandatory.=20 =20 Woj> Precisely, that is possible on a per application basis. Having = the flag would make troubleshooting of a message flow much more explicit = (today, with any problem one has to browse the drafts to figure out what = MUST be there vs what SHOULD be there all while looking what is actually = there) =20 Regards, Woj. =20 regards, Stefaan =20 =20 =09 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On = Behalf Of Wojciech Dec (wdec) Sent: donderdag 24 april 2008 14:19 To: Busser, M; ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal Hi Michael, =20 inline... =20 =09 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On = Behalf Of Busser, M Sent: 24 April 2008 13:13 To: ancp@ietf.org Cc: Haag, T Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol = proposal Hi Woi, all =20 I see the problem but i can not see, how an additional flag will = help solving this problem. =20 Lets assume your first proposal. If an implementation does not send the complete TLV, even it is = defined to be mandatory, I would call this a bug and I can not see, how = an additional flag can help here.=20 =20 Woj> The way it helps, and other protocols bear proof of this = scheme, is that it is easier for implementations to reconcile errors = resulting out of "Mandatory" and "Optional" TLV sets. The key to this = lies on a per application basis. One application may mandate TLV A for = operation, while another might not. Resolving such issues when = implementing or troubleshooting multiple applications is not always = trivial.=20 =20 Your second proposal seems obviously be required to keep existing = things working, if we agree on your first proposal.=20 But from my point of view it also assumes, that all existing = implementations are using the same set of TLVs now.=20 And I am not sure about that. =20 =20 Woj> This would be a good thing for the WG to discuss. There most = evidently is a fair amount of "dead wood" in the current spec, ie stuff = that nobody yet implements or cares about. In the former case, we could = re-cast that material using the new notions/extensions, in the latter = case simply chop it out. =20 Therefore I disagree with your first proposal. I recommend, the = better way will be to be more precise in definitions.=20 In my mind, it is a bug, if a mandatory TLV is missing. It is up to = the robustness of the implementation to deal with this situation. Is it really neccesary to define the behavior of a network element = in this case of failure in the ancp protocol itself? =20 =20 Woj> Other people have faced this problem before, and I would = rather go with the lessons they learned, rather than clinging to hopes = of perfect textual definitions and implementations. Other than backwards = compatibility, I do not see in your statements a valid reason to object = to the 1st proposal, particularly for new applications since it can only = make things more robust. The counter argument of being precise in the = definitions, as evidenced by the current spec, is admirable and needs to = be there, with this proposal providing an extra level of robustness and = visibility of any problems.=20 =20 Thanks, Woj. =20 If optional TLVs are not present in a message, we should describe = some kind of default behaviour, as you already stated. =20 =20 =20 =20 Comments on draft-ietf-ancp-protocol-02.txt: =20 It is not clearly stated, if the TLV "DSL Line Attributes " is = mandatory or optional.=20 In fact it is mandatory because some of its SubTLVs are mandatory.=20 We should spent a sentence to make this clear. =20 It is not clearly stated, if the TLV "Service-Profile-Name" is = mandatory or optional. I prefer mandatory because it is essetial for the use case Line = Config.=20 =20 Section 5.4.3 Line Config, where the TLVs are mentioned (page 35): ...defined in section 5.4.1.... must be corrected to = ...defined in section 5.4.2........ =20 Section 5.4.4 OAM, where the TLVs are mentioned (page 36 and page = 38): ...defined in section 5.4.1.... must be corrected to = ...defined in section 5.4.2........ =20 =20 =20 =20 Best Regards; Freundliche Gr=FC=DFe=20 Michael Busser T-Systems Enterprise Services GmbH=20 Production Line Network Centric Systems ICT-Systems Integration Network Integration Services =20 Br=FCckes 2 -8, 55545 Bad Kreuznach Postfach 9100, 55541 Bad Kreuznach +49 671 8333 8911 (Phone) +49 521 9210 3859 (Fax) +49 151 1211 9689 (Mobile) E-Mail: michael.busser@t-systems.com Internet: http://www.t-systems.com <http://www.t-systems.com/> =20 =20 T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Reinhard Clemens (Vorsitzender)*, Helmut = Binder, Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, = Wilfried Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG =20 Notice: This transmittal and/or attachments may be privileged or = confidential. If you are not the intended recipient, you are hereby = notified that you have received this transmittal in error; any review, = dissemination, or copying is strictly prohibited. If you received this = transmittal in error, please notify us immediately by reply and = immediately delete this message and all its attachments. Thank you.=20 T-Systems - Business flexibility=20 =20 =20 =09 ________________________________ Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im = Auftrag von Wojciech Dec (wdec) Gesendet: Mittwoch, 23. April 2008 14:54 An: ancp@ietf.org Betreff: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal =20 Hi All,=20 Continuing with the series of e-mails regarding basic protocol = issues still to be addressed, I now would now like to ask your feedback = regarding the distinction the protocol places on mandatory TLVs. Given = the length of this mail I'll first cut to the proposal, and after it you = can find the problem description. The proposal which I am putting in front of the WG is to define a = new TLV format which contains at a minimum a Mandatory flag (much like = Radius VSAs do). We could have this TLV Flag be defined only for new = applications. A second proposal would be try to make this flag work with existing = ones by for example defining the highest order bit of the TLV# field to = mean "Mandatory" when set to "0". This would be invisible to exiting = implementations, but newer ones may have problems in communicating with = older ones when the latter do not send all TLVs. But that can also be = addressed by simply forming the set of mandatory TLVs to be the ones = that all implementations currently send by default. Without additional feedback, I will assume that the WG is fine with = the first proposal, and also with the 2nd one conditional on deriving a = suitable "commonly used" TLV set. The problem in more detail:=20 Currently the situation is that Mandatory TLVs are only stated to = be as such in the body of the protocol draft spec, with an implementer = having to scour fairly attentively the text. Eg "Type = (Access-Loop-Circuit-ID =3D 0x01): This is a mandatory TLV", etc. The behaviour of an implementation that receives a message with a = missing mandatory TLV is not defined at all, and the opposite is handled = but not very robustly, i.e. when receiving a TLV but not recognizing it, = and implementation is free to discard it (even if it is mandatory!). = This is a recipe for interoperability problems and an implementation = mine field. This problem is complicated by different applications. For example = the current OAM section states the following regarding TLVs that are to = be carried in the request message (my italics): "=20 Following TLVs can appear in this message:=20 o Type (Access-Loop-Circuit-ID =3D 0x01) : defined in = section 5.4.1 =20 o Type (Access-Aggregation-Circuit-ID-Binary =3D 0x06): = defined in=20 section 5.4.1.=20 =20 o Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03): = defined in section=20 5.4.1. =20 o Type (OAM-Loopback-Test-Parameters =3D 0x07): Parameters = related to =20 loopback test. This is an optional TLV. If this TLV is not = present=20 in the request message, the DSLAM SHOULD use locally = determined=20 default values for the test parameters. =20 "=20 (NOTE: The last "SHOULD" appears to be inappropriate. If the TLV is = missing, the DSLAM MUST have some default parameters, or return an = error) The "can" above indicates that they're all optional, while clearly = the application cannot run its course without one or more of these = fields. Here we have a case where one could have a perfectly compliant = implementation that ignores all these TLVs... -Woj.=20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 ------_=_NextPart_001_01C8AA84.9E486A6F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--> <title>Nachricht

Woj

=A0 I agree only on the = following:

 

  1. A TLV might be mandatory for one application or use-case, and = optional for another application. We do need to clearly specify in the draft if = a TLV is mandatory or optional for a given application (which boils down = to specifying this per ANCP message and message = type).
  2. We should clearly specify the behavior for handling missing mandatory = TLVs in received messages.

 

To me the utility of flagging a TLV = as mandatory or optional via the protocol is at best debatable. =A0If a = buggy implementation on the sender incorrectly sets a “known” TLV = as mandatory (when it is not) or vice-versa, do we want the receiver to = infer the handling of this TLV based on what the sender tells it? I don’t = think so. Ideally, we want the receiver and sender to have a common understanding = of what is mandatory and what is optional based on what is in the spec, and = handle the TLV based on that understanding. As Peter mentions, the spec clearly = spells out TLVs that are mandatory and optional. Also, I don’t see a major = advantage of your proposal with respect to = debuggability.

 

Typical case where it does make = sense for the sender to set some flag in the TLV to control the handling of the = TLV on the receiver is for “unrecognized” TLV = types…e.g.

  1. Receiver is an intermediate node, which consumes the message but also needs = to forward it along to other nodes. Here the sender can flag the = handling of the TLV to the receiver (e.g. discard or forward if the TLV type is = not recognized by the receiver). This doesn’t quite apply to ANCP = (messages are confined to be between two = peers).

 =

  1. If handling of an unrecognized TLV on the receiver needs to be = different for an optional TLV versus a mandatory TLV. Here the receiver = doesn’t understand the TLV type, but can infer the handling based on the = flag in the TLV. However, do we want the treatment of = “unrecognized” TLVs on the receiver to be different for optional and mandatory = TLVs (e.g. silently discard an unrecognized optional TLV…but discard and = also send an error back for an unrecognized mandatory TLV). I don’t = think this is necessary. However, if we do want to do this, then may be the = flag in the TLV should explicitly indicate the handling for the TLV (e.g. = “silently discard if un-recognized” versus “discard and send an = error back”)…as opposed to just flagging these as = “mandatory” versus “optional”.

 

Woj> Of course it is, the = whole spec is about this. The problem comes when people start to = re-use well known TLVs for different applications, and then trying to make sense of = it all >becomes non-trivial. Why do you think both BGP and Diamater, and a number of = other protocols have definied "Mandatory" flags? Just for kicks? = It's a well known protocol design tool, that >comes handy when re-using same = data across multiple applications.

 

=

We should look at why these = protocols are doing this (as opposed to blindly following). For a counter example, = please take a look at OSPF traffic engineering extensions (RFC 3630). =

 

Cheers

-Sanjay

=

 

From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec)
Sent: Tuesday, April 29, = 2008 3:03 PM
To: Peter Arberg; DE = CNODDER Stefaan; Busser, M; ancp@ietf.org
Cc: Haag, T
Subject: Re: [ANCP] = Mandatory TLVs in draft-ietf-ancp-protocol proposal

 

Hi Peter,

 

continued inline...

 

From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Peter Arberg
Sent: 29 April 2008 = 20:39
To: Wojciech Dec (wdec); = DE CNODDER Stefaan; Busser, M; ancp@ietf.org
Cc: Haag, T
Subject: Re: [ANCP] = Mandatory TLVs in draft-ietf-ancp-protocol proposal

Hi = Woj,

 

please see = inline in your answers

 

 

From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]
Sent: 29. april 2008 = 11:07
To: Peter Arberg; DE = CNODDER Stefaan; Busser, M; ancp@ietf.org
Cc: Haag, T
Subject: RE: Re: [ANCP] = Mandatory TLVs in draft-ietf-ancp-protocol proposal

Hi Peter,

 

 

 

From: Peter Arberg [mailto:parberg@redback.com]
Sent: 29 April 2008 = 19:34
To: Wojciech Dec (wdec); = DE CNODDER Stefaan; Busser, M; ancp@ietf.org
Cc: Haag, T
Subject: RE: Re: [ANCP] = Mandatory TLVs in draft-ietf-ancp-protocol proposal

Hi = Woj,

 

I agree with = Michael and Stefan on this issue, I do not see a need to change the = existing

implementation = with a mandatory/optional flag. 

 

Woj> Please = indicate where in my proposal did you see anything about changing existing = implementaions?  

 

PAR> &nbs= p;I might have misunderstood your email, but I read it as if you suggest a = high bit

value in = existing TLV's to be interpreted as a mandatory flag. 

 

Woj#2> Yes, = I suggested (in proposal 2) that *if* the WG found there to be a common set of TLVs currently in use, then the high-order bit set to "0" (ie as = today) could be interpreted as "mandatory", and the rest of the TLV's redefined with a high order "1". To extsing implementations, = the "new" TLVs would just look like a different TLV#, = while anyone wishing to implement the more robust error cheking logic based on this bit, would be free to do so. 

 

If you are = simply talking about new capability type definitions, then why do you not bring = up

the additional = flag in a new internet-draft defining what capability type you have in mind = ? 

 

Woj#2> No, a = new capability was not intended, but could also be = considered.

 

 

I think I = understand your arguments, but I do not agree with them. I think most places = in

the draft it is = clear what is defined as mandatory and optional. 

 

I agree on the = point we need to go through the draft and make clarifications to what = TLV's

in what = capability types are mandatory and optional, and make more description what = should

happen if = mandatory TLVs are not included. 

 

Woj> = Exactly. 

 

I think the DSLF = TR-101 document has a good example of such a description in it's =

"Table 3 - Access loop = characteristics sub-options", and I think if we do the same for = each

capability= types TLV's in the ANCP draft it will be a good help.

 

Woj> Indeed, pre-ceeded by some rationalization. The appears to be no reason for some = of the DSLF "mandatory" TLVs. 

 

PAR> I do not = see a problem with re-visit in the draft if a TLV should be optional or = mandatory, so if

that is the = intend, then I'm all for an email discussion on a TLV by TLV basis if we think it is = a

manfdatory or = optional information inside the specific capability type. 

 

Woj#2> = Great, because any change to the mandated set *will* affect existing = implementation .<= span lang=3DDE>

 

 

 

I do not agree = with your point that it is not listed if "rate" is mandatory or = optional, it is clearly

listed as a = mandatory TLV, and as such it should be included in the port up message, I = really

do not = understand what confusion you have with this. 

 

Woj> The = text states:   

 

5. Type = (DSL Line Attributes =3D 0x04): =

Length : variable (up to = 1024 bytes)

Value : This consists of = one or more Sub-TLVs corresponding to DSL

line attributes. No = sub-TLVs other than the "DSL type" and "DSL

line state" SHOULD be included in a PORT DOWN message.

The general format of the sub-TLVs is identical to the general TLV

format. The value field in = each sub-TLV is padded to a 4-octet

alignment. The Length = field in each sub-TLV contains the actual

number of bytes in the TLV = (not including the padding if present).

Current defined sub-TLV = types are start from 0x81.  

Maybe you can point me to where exatly it = is stated clearly as being mandatory, or otherwise explain why you = "not agree"?  

 

=

PAR> I think = you forgot to read the most important part where the actual TLV is = defined. 

 <= /span>

Woj#2> I= didn't. This part talks about the sub-TLV, not the main TLV 0x04. Do you see my = point now?=

 <= /span>

 <= /span>

Type (Actual-Net-Data-Upstream =3D 0x81): Actual upstream net data rate = on a DSL line. =

This is a = mandatory TLV.  =

 <= /span>

Length  = :  (4 bytes) =

Value  = ; : (Rate in Kb/sec) =

 <= /span>

Type = (Actual-Net-Data-Rate-Downstream =3D 0x82) : Actual downstream net data rate on a DSL line. =

This is a = mandatory TLV. =

 <= /span>

Length :  = (4 bytes) =

Value  = :  (Rate in Kb/sec) =

 <= /span>

 

The fact you say "Port UP" and "OAM" is best considered as legacy applications, I have some

trouble with = this as well, since ANCP running in production networks use them, and as = such

it is a central = part of the ANCP specifications we need to finish as soon as = possible. 

 

Woj> I = should have said legacy applications from a protocol messaging perspective, not = usage, nor support. It's quite clear that GSMP derived messaging has baggage that = is un called for in new applications.

 

I think = Stefaan's example is very valid, that we do not need to make mandatory requirements to =

what receivers = of ANCP information use such info. for.  I don't think we should try and = make the

ANCP = specifications "mandatory" for box behavior, I think it is much more = important for the

working group to = make the protocol specifications easy to understand and get the first = documentation

finish and = published, so the protocol can be used for different sets of applications, and make = sure

new applications = can be added later. 

 

Woj> Indeed = the aim of the WG to define a protocol that is relatively simple and easy to understand, not just to implementers but also to people using it, and = across vendors. Currently, having anyone operating the device be familiar in = what cases a TLV is mandatory and in what optional requires a thorough = understanding of the spec, across applications. This is not easy, but I'll conceede = that for the applications implemented so far we could live with it. =

 

I do think that = by documenting if a TLV is mandatory or optional inside a specific = capability type,

it is easy to = understand what must be sent to support the defined application/capability = type. 

 

Woj> Of = course it is, the whole spec is about this. The problem comes when people = start to re-use well known TLVs for different applications, and then trying = to make sense of it all becomes non-trivial. Why do you think both BGP and = Diamater, and a number of other protocols have definied "Mandatory" = flags? Just for kicks? It's a well known protocol design tool, that comes handy when = re-using same data across multiple applications. 

 

PAR> I might = be wrong, but I think I can find as many or more protocol examples who do = not include

a = mandatory/optional flag, so examples can always be found which will support the point you = are trying

to = make.

 

I do not see a = problem with a new internet-draft which defines new capability-types and where a = TLV

mandatory flag is included, I do see a problem if the = intend is to try and adjust what already = exist.  

 

Woj#2> Ok, so if adjusting is only scoped to what = doesn't exist, as my proposal laid out conditionally, you're = fine.

 

 

 

Then if anybody = want to include new capability types or sub-TLVs later to address specific applications,

then I think = changes can be discussed at that time instead of trying to change existing = protocol

implementations.<= /span> 

 

Woj> Again I = ask, where in the proposal did you see *anything* requiring a change to = an existing implementation. Please be specific. I see = that your main objection is on this issue, which means that you accept proposal 1 = (have such a flag for new TLVs/apps).

It would also be useful if you indicated whether the = list of TLVs provided below is what you'd expect to be the minimum mandatory = set. 

 

PAR> at the = moment I read the draft as having defined the TLVs mandatory as you = describe, except

I also read = it as the dsl-type =3D 0x91 must be part of the port down. If this is needed = or not is a different

discussion.

 

 

Woj#2> Ok. = Thanks. But please do come back to me if you see that the proposal impacts an = exiting implementation. I conclude that there is no problem with doing changes to stuff that = isn't currently used.

Woj.

 

cheers,

Peter 

 

Cheers,

Woj.

 

cheers,

Peter

 

 

 

 

From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec)
Sent: 29. april 2008 = 02:28
To: DE CNODDER Stefaan; = Busser, M; ancp@ietf.org
Cc: Haag, T
Subject: Re: [ANCP] = Mandatory TLVs in draft-ietf-ancp-protocol proposal

Stefaan,

 

a number of points:

1. There currently is to my knowledge no = implementation of ANCP there that doesn't send the DSL Line attributes info by default = in Port-UP messages? The support of HS on the NAS is an orthogonal = issue.

2. The current ancp protocol draft (02) doesn't say = whether the rate info is optional or mandatory, it only states that the sub-TLVs = are mandatory. Based on this, an implementer can be justified to expect port-ups to *always* have the rate-info tlv (ie treat them as = mandatory). Equally, she's justified in considering this  as = optional.

3. The port-up and OAM are best considered as legacy applications for = ANCP. The re-use of any of the GSMP defined fields is already out of the question = due to constrains put in place by the existing use-case messaging. Needless to = say, this wasn't as thoroughly designed as it should have been, and with the = OAM and port-up apps being coupled.

4. It's up to the application to define what TLVs are mandatory and which aren't, as you also state. The AN does not need = to know what the NAS will do with the info, BUT it needs to send the right = TLVs for the application (eg if we had a hypothetical AN that only sends = Port-up's with line-id, it would be next to useless for the dynamic shaping = application).

 

With all this in mind it's useful to re-read what I = proposed originally below regarding the mandatory flag: 1. = "have this TLV Flag be = defined only for new applications" and 2. The notion of = the mandatory flag applying to existing TLVs  being "conditional on deriving a = suitable "commonly used" TLV set." The = latter point would ensure that existing implementations do not need to change, = but future ones can take advantage of the extra = robustness.

 

Hence, can the WG derive a set of commonly used, i.e. = always used, TLVs for existing implementations?

The list I came up is as follows (making them pretty = much mandatory TLVs if it agrees with the views of others);

 

Port-up message (0x80);

    Extension-TLV (dsl tech = type)

    Access-Loop-circuit-id = (0x01)

    DSL Line Attribute (0x04) with the following sub TLVs;

        DSL-Type = =3D 0x91; Actual-Net-Data-Upstream =3D 0x81; Actual-Net-Data-Rate-Downstream =3D = 0x82

 

Port-down message (0x81);

    Extension  TLV (dsl tech type)

    Access-Loop-circuit-id (0x01)

    DSL Line Attribute (0x04) with the following sub TLVs;

        DSL line state =3D = 0x8F

 

All other TLVs are optional.

 

Would appreciate confirmation from the WG regarding = the above.

 

Thanks,

Woj.

 

 

From: DE CNODDER Stefaan [mailto:stefaan.de_cnodder@alcatel-lucent.be]
Sent: 29 April 2008 = 09:52
To: Wojciech Dec (wdec); = Busser, M; ancp@ietf.org
Cc: Haag, T
Subject: RE: [ANCP] = Mandatory TLVs in draft-ietf-ancp-protocol proposal

 

Hi = Woj,

 

Take the = following example: I have a network with 2 NASses, NAS-A is doing hierarchical = shaping, NAS-B just wants to have the port information but is not doing = hierarchical shaping (it is doing other things like OAM, ...).  This means NAS-A = needs the bandwidth, while NAS-B does not need the bandwidth.  How should = the flag be set in this case by the AN?  Set to 'Mandatory' for the = port up messages to NAS-A, and set to 'Optional' for port up messages towards = NAS-B? Or is it always set to 'Mandatory'?  From your answer below, I = understand that it should be set to 'Optional' towards NAS-B.  Is that = correct?

 

NAS-B will = simply ignore the bandwidth TLV.  If such a flag would exist, and the flag is set = to 'Mandatory' by the AN to NAS-B, what should be the behavior of = NAS-B?  Should it reject the whole message?  Maybe NAS-B is not supporting hierarchical shaping, so it might not support the bandwidth TLV.  = Today, the bandwidht TLV is only mandatory to be put in the port up messages, = but for the receiver there is nothing mandatory.

 

I believe the = original intend of ANCP was that the AN does not need to know what the NAS is = doing with this information, the use of the bandwidth is also not specified by = ANCP, only an example is given (which is shaping).  In the future there may be applications for which TLVs will be mandatory which are now = optional.

 

regards,

Stefaan

 

 

 

 

From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]
Sent: maandag 28 april = 2008 21:33
To: DE CNODDER Stefaan; = Busser, M; ancp@ietf.org
Cc: Haag, T
Subject: RE: [ANCP] = Mandatory TLVs in draft-ietf-ancp-protocol proposal

 

 

From: DE CNODDER Stefaan [mailto:stefaan.de_cnodder@alcatel-lucent.be]
Sent: 28 April 2008 = 17:15
To: Wojciech Dec (wdec); = Busser, M; ancp@ietf.org
Cc: Haag, T
Subject: RE: [ANCP] = Mandatory TLVs in draft-ietf-ancp-protocol proposal

 

Take the = bandwidth sub-TLV in port up messages as example.  The current protocol spec = says that it is mandatory to be sent in port up messages.  that's ok.  But it is not mandatory for the receiver to process the = bandwidth sub-TLV.  What is done with this information by the NAS is not = specified by ANCP, so you cannot make it mandatory for the receiver = side. 

 

Woj> Is the information required by the application? It would appear for the dynamic shaping use-case to be most certainly so. Hence it is absolutely = mandatory, otherwise the message makes no sense for the = application. In = any case, if

 

So it looks to = me that the flag can only indicate what the receiver should do.  Then the = flag makes sense. 

 

Woj> =  The = flag tells the receiver what info the sender thinks is required to carry out the application. This in almost all cases has to match up to what the = receiver thinks is required. The sender doesn't tell the receiver what to do = with the info.

 

If the receiver = knows what is mandatory, then I do not see a reason why this has to be made = explicit in the protocol.  It would only complicate the protocol.  As = already said by Michael: if a mandatory TLV is not there, then it is just a = bug. 

 

Woj> Can you specifically describe what aspect of the protocol does it = complicate? It's = just making explicitly clear what the protocol already has to implement anyway to be = of any use.

As to whether it is a bug, having such explicit = marking makes it clear what/where the problem is when observing a messaging flow vs a lot of deduction work. In any case, the other point being = made here is that today the protocol does NOT specify what should happen = if a mandatory TLV is missing.

 

-Woj.

 

regards,

Stefaan

 

 

 

From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]
Sent: maandag 28 april = 2008 16:28
To: DE CNODDER Stefaan; = Busser, M; ancp@ietf.org
Cc: Haag, T
Subject: RE: [ANCP] = Mandatory TLVs in draft-ietf-ancp-protocol proposal

It's actually a mix of both. = Inline...

 

From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of DE CNODDER Stefaan
Sent: 28 April 2008 = 16:04
To: Wojciech Dec (wdec); = Busser, M; ancp@ietf.org
Cc: Haag, T
Subject: Re: [ANCP] = Mandatory TLVs in draft-ietf-ancp-protocol proposal

 

Hi,=

 

This new = mandatory flag, what is exactly its meaning?

 

(1) if flag = set to "mandatory", then the *receiver* of this TLV MUST process it, = and if unrecognized must drop the message 

 

If a received = TLV is has the "mandatory" flag set then the receiver MUST drop = the message and report an error to the sender if it doesn't recognize = the TLV. 

If a the = receiver expects a "mandatory" TLV but doesn't receive = it, the message MUST be droped and an error report sent to the sender. 

 

OR<= span lang=3DDE>

 

(2) if flag = is set to"mandatory", then the *sender* MUST include it in the = message for which it is defined 

 

The sender MUST = include mandatory TLVs as defined by the = protocol-spec/applications.

 

The current = protocols draft says for certain TLVs that they are mandatory, but that applies to = the sender of it (interpretation 2).  The flag would indicate = interpretation 1 (like for Radius VSAs?)?

 

If the higher = order bit is set to "0" means that it is mandatory, then currently = defined optional defined TLVs suddenly become mandatory which is not = good. 

 

Woj> Only = the currently used TLVs become mandatory. If they are not = used/implemented we can re-define them as optional (set flag to 1) at no cost. =

 

But I would = first to understand the exact meaning of this mandatory flag.  Defining such = a flag indeed looks useful but then as interpretation 1, and I would say that = if flag set to 1, then it is mandatory and actually, it is possible that a TLV = is sent sometimes as optional and sometimes as mandatory. 

 

Woj> = Precisely, that is possible on a per application basis. Having the flag would make troubleshooting of a = message flow much more explicit (today, with any problem one has to = browse the drafts to figure out what MUST be there vs what SHOULD be = there all while looking what is actually there)

 

Regards,<= /font>

Woj.

 

regards,

Stefaan

 

 

From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec)
Sent: donderdag 24 april = 2008 14:19
To: Busser, M; = ancp@ietf.org
Cc: Haag, T
Subject: Re: [ANCP] = Mandatory TLVs in draft-ietf-ancp-protocol proposal

Hi Michael,

 

inline...

 

From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On = Behalf Of Busser, M
Sent: 24 April 2008 = 13:13
To: ancp@ietf.org
Cc: Haag, T
Subject: Re: [ANCP] = Mandatory TLVs in draft-ietf-ancp-protocol proposal

Hi Woi, all

 

I see the problem but i can not see, how an = additional flag will help solving this problem.

 

Lets assume your = first proposal.

If an implementation does not send the complete TLV, even it is defined to be mandatory, I = would call this a bug and I can not see, how an additional flag can help here. 

 

Woj> The way it helps, and other protocols bear = proof of this scheme, is that it is easier for implementations to reconcile = errors resulting out of "Mandatory" and "Optional" TLV = sets. The key to this lies on a per application basis. One application may = mandate TLV A for operation, while another might not. Resolving such issues when implementing or troubleshooting multiple applications is not always = trivial.

 

Your second proposal seems obviously be required = to keep existing things working, if we agree on your first = proposal.

But from my point of view it also assumes, that = all existing implementations are using the same set of TLVs now. =

And I am not sure = about that.  

 

Woj> This would be a good thing for the WG to = discuss. There most evidently is a fair amount of "dead wood" in = the current spec, ie stuff that nobody yet implements or cares about. =  In the former case, we could re-cast that material using the new notions/extensions, in the latter case simply chop it = out.

 

Therefore I disagree with your first proposal. I = recommend, the better way will be to be more precise in = definitions. 

In my mind, it is a bug, if a mandatory TLV is = missing. It is up to the robustness of the implementation to deal with this = situation.

Is it really neccesary to define the behavior of a = network element in this case of failure in the ancp protocol = itself?  

 

Woj> Other people have faced this problem before, = and I would rather go with the lessons they learned, rather than clinging to = hopes of perfect textual definitions and implementations. Other than backwards compatibility, I do not see in your statements a valid reason to = object to the 1st proposal, particularly for new applications since it can = only make things more robust. The counter argument of being precise in the = definitions, as evidenced by the current spec, is admirable and needs to be there, = with this proposal providing an extra level of robustness and visibility of any = problems.

 

Thanks,

Woj.

 

If optional TLVs are not present in a message, we = should describe some kind of default behaviour, as you already = stated.

 

 

 

 

Comments on = draft-ietf-ancp-protocol-02.txt:

 

It is not clearly stated, if the TLV =  "DSL Line = Attributes " is mandatory or optional.

In fact it is mandatory because some of its = SubTLVs are mandatory.

We should spent a sentence to make this = clear.

 

It is not clearly stated, if the TLV =  "Service-Profile-Name" is mandatory or optional.

I prefer mandatory because it is essetial for = the use case Line Config. 

 

Section 5.4.3 Line Config, where the TLVs are = mentioned (page 35):

  ...defined in section = 5.4.1....    must be corrected to    ...defined in section = 5.4.2........

 

Section 5.4.4 OAM, where the TLVs are mentioned = (page 36 and page 38):

  ...defined in section = 5.4.1....    must be corrected to    ...defined in section = 5.4.2........

 

 

 

 

Best Regards; Freundliche = Gr=FC=DFe

Michael = Busser

T-Systems Enterprise Services GmbH =

Production Line Network Centric = Systems

ICT-Systems = Integration

Network Integration = Services

 

Br=FCckes 2 -8, 55545 = Bad Kreuznach
Postfach 9100, 55541 Bad Kreuznach
+49 671 8333 8911 (Phone)
+49 521 9210 3859 (Fax)
+49 151 1211 9689 (Mobile)
E-Mail: michael.busser@t-systems.com=

Internet: http://www.t-systems.com

 

T-Systems = Enterprise Services GmbH
Aufsichtsrat: Ren=E9 Obermann (Vorsitzender)
Executive Committee: Reinhard Clemens (Vorsitzender)*, Helmut Binder, = Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Wilfried Peters*,
Dr. Herbert Schaaff*, Zvezdana Seeger*
Handelsregister: Amtsgericht Frankfurt am Main HRB 55933
Sitz der Gesellschaft: Frankfurt am Main
WEEE-Reg.-Nr. DE87523644
*Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG

 

Notice: This transmittal and/or attachments = may be privileged or confidential. If you are not the intended recipient, you = are hereby notified that you have received this transmittal in error; any = review, dissemination, or copying is strictly prohibited. If you received this transmittal in error, please notify us immediately by reply and = immediately delete this message and all its attachments. Thank you.
T-Systems – Business flexibility

 

 =

Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von Wojciech Dec (wdec)
Gesendet: Mittwoch, 23. = April 2008 14:54
An: ancp@ietf.org
Betreff: [ANCP] Mandatory = TLVs in draft-ietf-ancp-protocol proposal

 

Hi All,

Continuing with the series of e-mails regarding basic protocol = issues still to be addressed, I now would now like to ask your feedback = regarding the distinction the protocol places on mandatory TLVs. Given the length of = this mail I'll first cut to the proposal, and after it you can find the = problem description.

The proposal which I am putting in front of the WG is to define a = new TLV format which contains at a minimum a Mandatory flag (much like = Radius VSAs do). We could have this TLV Flag be defined only for new = applications.

A second proposal would be try to make this flag work with = existing ones by for example defining the highest order bit of the TLV# field to mean "Mandatory" when set to "0". This would be invisible = to exiting implementations, but newer ones may have problems in = communicating with older ones when the latter do not send all TLVs. But that can also be = addressed by simply forming the set of mandatory TLVs to be the ones that all implementations currently send by default.

Without additional feedback, I will assume that the WG is fine = with the first proposal, and also with the 2nd one conditional on deriving a = suitable "commonly used" TLV set.

The problem in more detail:

Currently the situation is that Mandatory TLVs are only stated to = be as such in the body of the protocol draft spec, with an implementer having = to scour fairly attentively the text. Eg "Type (Access-Loop-Circuit-ID = =3D 0x01): This is a mandatory TLV", etc.

The behaviour of an implementation that receives a message with a missing mandatory TLV is not defined at all, and the opposite is handled = but not very robustly, i.e. when receiving a TLV but not recognizing it, and implementation is free to discard it (even if it is mandatory!). This is = a recipe for interoperability problems and an implementation mine = field.

This problem is complicated by different applications. For = example the current OAM section states the following regarding TLVs that are to be = carried in the request message (my italics):

"
Following TLVs can appear = in this message:

       o Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section 5.4.1   

       o Type (Access-Aggregation-Circuit-ID-Binary =3D 0x06): defined in =
         section 5.4.1.
 
       o Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03): defined in section =
         5.4.1. 

       o Type (OAM-Loopback-Test-Parameters =3D 0x07): Parameters related = to 
         loopback test. This is an optional TLV. If this TLV is not present =
         in the request message, the DSLAM SHOULD use locally determined =
         default values for the test parameters. 
"
(NOTE: The last "SHOULD" = appears to be inappropriate. If the TLV is missing, the DSLAM MUST have some default parameters, or return an error)

The "can" above indicates that = they're all optional, while clearly the application cannot run its course = without one or more of these fields. Here we have a case where one could have a = perfectly compliant implementation that ignores all these = TLVs…

-Woj.










------_=_NextPart_001_01C8AA84.9E486A6F-- --===============1012658706== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============1012658706==-- From ancp-bounces@ietf.org Wed Apr 30 00:18:59 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC7273A699D; Wed, 30 Apr 2008 00:18:59 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B74AB3A699D for ; Wed, 30 Apr 2008 00:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzBRe4f8dK7Y for ; Wed, 30 Apr 2008 00:18:56 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [61.144.161.53]) by core3.amsl.com (Postfix) with ESMTP id CEB2F3A6811 for ; Wed, 30 Apr 2008 00:18:55 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K04004YMMYWM4@szxga01-in.huawei.com> for ancp@ietf.org; Wed, 30 Apr 2008 15:18:32 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K040086UMYWUI@szxga01-in.huawei.com> for ancp@ietf.org; Wed, 30 Apr 2008 15:18:32 +0800 (CST) Received: from z24109b ([10.70.76.172]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K04003P0MYVWI@szxml04-in.huawei.com> for ancp@ietf.org; Wed, 30 Apr 2008 15:18:32 +0800 (CST) Date: Wed, 30 Apr 2008 15:18:35 +0800 From: Tina TSOU To: Maglione Roberta , Sanjay Wadhwa , "Wojciech Dec (wdec)" Message-id: <00d001c8aa92$67515630$ac4c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <9BD5D7887235424FA97DFC223CAE3C280AB439FC@proton.jnpr.net> Cc: ancp@ietf.org Subject: Re: [ANCP] question regarding Labels in ANCP port up messages X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1163296491==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1163296491== Content-type: multipart/alternative; boundary="Boundary_(ID_4ob3YVH46eWB+wEsVodK9Q)" This is a multi-part message in MIME format. --Boundary_(ID_4ob3YVH46eWB+wEsVodK9Q) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi all, It is clear to me that if Label Length is filled as 0, there is nothing to be filled into Label Value. The whole Label part is 4 bytes, not 8 bytes. Cheers from the last working day before Labor's Day holidays in some countries:) Tina ----- Original Message ----- From: Wojciech Dec (wdec) To: Sanjay Wadhwa ; Maglione Roberta Cc: ancp@ietf.org Sent: Wednesday, April 30, 2008 1:12 AM Subject: Re: [ANCP] question regarding Labels in ANCP port up messages Sanjay, All, What is stated below runs counter to at least a handful of ANCP implementations, all of which are known to be interoperable. There are really two options: 1) The current version of the spec is correct, and the known interoperable implementations do not follow it 2) The current version of the spec is not accurate, and does not reflect the fact that the known implementations follow the label field definition from draft-gsmpv3-base-spec. I would like to ask you, as the lead editor of the spec, to work with the WG in resolving what the problem is, and clearing up what the WG spec says about and if 1) holds to be true, then proposing an interoperability fix. In either case, the issue highlights the fact that there is still lingering confusion as to the dependencies ANCP has on rfc3292, or draft-gsmpv3-base-spec, or both. It seems to be in the best interest of all to address these. Regards, Woj. > -----Original Message----- > From: Sanjay Wadhwa [mailto:swadhwa@juniper.net] > Sent: 29 April 2008 17:29 > To: Maglione Roberta > Cc: Wojciech Dec (wdec); ancp@ietf.org; Philippe Champagne (pchamp) > Subject: RE: question regarding Labels in ANCP port up messages > > Hi Maglione > Yes, the label format is as defined in RFC 3292. The ANCP draft is > based on RFC 3292 and proposes extensions/modifications where > required. > This is clearly stated upfront both in the abstract and in > section 2. In > section 5.4.2, it clearly specifies the format of "port up" message > (based on RFC 3292), and explicitly states the label field > should be set > to 0. Following is what the draft currently states: > > > 5.4.2 Topology Discovery Extensions > > The GSMP Event message with PORT UP message type (80) is used for > conveying DSL line attributes to the NAS. The version field should be > set to 3, and the sub field should be set to 1. The I and subMessage > fields SHOULD be set to 1 to signify no fragmentation. The Port and > Label fields should be set to 0. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vers | Sub | Message Type | Result| Code > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Partition ID | Transaction Identifier > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |I| SubMessage Number | Length > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Port > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Port Session Number > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Event Sequence Number > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |x|S|x|x| > | > +-+-+-+-+ Label > | > ~ > ~ > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | > | > ~ Extension Value > ~ > | > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > When we say the label field should be set to 0, the intention > is for the > type and length fields in the label TLV to be set to 0. We can > explicitly state this for clarity. > > -Sanjay > > >-----Original Message----- > >From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] > >Sent: Tuesday, April 29, 2008 8:06 AM > >To: Sanjay Wadhwa > >Cc: Wojciech Dec (wdec); ancp@ietf.org; pchamp@cisco.com > >Subject: RE: question regarding Labels in ANCP port up messages > > > > > >Hi Sanjay and All, > > I was reading the current ancp protocol draft in order to > > understand which should be the correct format for the label > >field in the ancp port Up message. > >Actually as it was already pointed out in the alias the draft > >in section 5.4.2 says "GSMP Event message with PORT UP message > >type (80) is used" thus I am assuming that the label in the > >port UP message should follow the message format defined in > >RFC 3292, section 3.1.3: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |x|S|x|x| Label Type | Label Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > ~ Label Value ~ > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >but from what I have seen different implementations use > >different format for label field: in particular several > >implementations use a label format that is similar to the one > >specified in the expired draft draft-ietf-gsmp-v3-base-spec: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |x|S|x|x|x|x|x|x|x|x|x|x|x|x|x|x| Label > Type | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Label Adaptation | Label > Length | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | > | > > ~ Label Value > ~ > > | > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > >Even if ancp does not care about the label field, having this > >field somehow not clearly specified in the current ancp draft > >can easily lead to interoperability issues, thus I think it > >would be very helpful if you and/or the other editors can > >clarify what should be the correct format for the label field > >to be used in the ancp Port Up message. > > > >Thanks and best regards, > >Roberta > > > >________________________________________ > >From: Philippe Champagne (pchamp) [pchamp@cisco.com] > >Sent: Thursday, April 24, 2008 7:14 PM > >To: Sanjay Wadhwa > >Cc: Maglione Roberta; Wojciech Dec (wdec); ancp@ietf.org > >Subject: question regarding Labels in ANCP port up messages > > > >Hi Sanjay > > > >In section 5.4.2 of the draft, we have: > > > > > > 0 1 2 > 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > >7 8 9 0 1 > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Vers | Sub | Message Type | Result| Code > > | > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Partition ID | Transaction Identifier > > | > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |I| SubMessage Number | Length > > | > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Port > > | > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Port Session Number > > | > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Event Sequence Number > > | > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |x|S|x|x| > > | > > +-+-+-+-+ Label > > | > > ~ > > ~ > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |x|x|x|x|x|x|x|x| Message Type | Tech Type | > >Block Length | > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | > > | > > ~ Extension Value > > ~ > > | > > | > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >Where Label I suppose is taken from the RFC 3292, section > >3.1.3: (well, I'm guessing) > > > > A summary of TLV labels supported in this version of the > protocol is > > listed below: > > > > TLV Label Type Section Title > > --------- ---- ------------- > > ATM Label 0x100 ATM TLV Labels > > FR Label 0x101 Frame Relay TLV Labels > > MPLS Gen Label 0x102 MPLS Generic TLV Labels > > FEC Label 0x103 FEC TLV Labels > > > > All Labels will be designated as follow: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |x|S|x|x| Label Type | Label Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > ~ Label Value ~ > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > x: Reserved Flags. > > These are generally used by specific messages and will be > > defined in those messages. > > > > S: Stacked Label Indicator > > Label Stacking is discussed below in section 3.1.3.5 > > > > Label Type > > A 12-bit field indicating the type of label. > > > > Label Length > > A 16-bit field indicating the length of the Label > Value field > > in bytes. > > > > Label Value > > A variable length field that is an integer number of 32 bit > > words long. The Label Value field is interpreted > according to > > the Label Type as described in the following sections. > > > > > >The draft is a bit obscure about this and since it doesn't > >specify much, it can lead to misinterpretation for the unused > >part. Moreover, it would appear that several implementations > >currently use another format for the label field. Can you > >explain? I mean, how come what's in the current draft doesn't > >match what's known to be implemented? > > > >I'm still wondering why we carried over pieces from GSMP that > >we do not intend to use. > > > >I would recommend that if we are to keep them but not use > >them, we should mention precisely how we intend not to use > >them: that is how many 0 filled bytes this is expected to use > > > >The rfc 3292 doesn't cover the case where this field is not used. > > > >Can you shed some ligths on this? > > > >Thanks > >Regards > >Phil > > > > > > > >-------------------------------------------------------------------- > > > >CONFIDENTIALITY NOTICE > > > >This message and its attachments are addressed solely to the > >persons above and may contain confidential information. If you > >have received the message in error, be informed that any use > >of the content hereof is prohibited. Please return it > >immediately to the sender and delete the message. Should you > >have any questions, please contact us by replying to > >webmaster@telecomitalia.it. > > > > Thank you > > > > www.telecomitalia.it > > > >-------------------------------------------------------------------- > > > > > _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --Boundary_(ID_4ob3YVH46eWB+wEsVodK9Q) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable
Hi all,
It is clear to me that if = Label Length=20 is filled as 0, there is nothing to be filled into Label Value. The = whole Label=20 part is 4 bytes, not 8 bytes.
 
Cheers from the last working = day=20 before Labor=92s Day holidays in some countries:)

Tina
----- Original Message -----
From:=20 Wojciech Dec = (wdec)=20
To: Sanjay Wadhwa ; Maglione Roberta =
Sent: Wednesday, April 30, 2008 = 1:12=20 AM
Subject: Re: [ANCP] question = regarding=20 Labels in ANCP port up messages

Sanjay, All,

What is stated below runs counter = to at=20 least a handful of ANCP
implementations, all of which are known to = be=20 interoperable.
There are really two options:
1) The current = version of=20 the spec is correct, and the known
interoperable implementations do = not=20 follow it
2) The current version of the spec is not accurate, and = does not=20 reflect
the fact that the known implementations follow the label=20 field
definition from draft-gsmpv3-base-spec.

I would like = to ask=20 you, as the lead editor of the spec, to work with
the WG in = resolving what=20 the problem is, and clearing up what the WG
spec says about and if = 1) holds=20 to be true, then proposing an
interoperability fix.

In = either case,=20 the issue highlights the fact that there is still
lingering = confusion as to=20 the dependencies ANCP has on rfc3292, or
draft-gsmpv3-base-spec, or = both.=20 It seems to be in the best interest of
all to address=20 these.

Regards,
Woj.

> -----Original = Message-----
>=20 From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]
> Sent: 29 = April 2008=20 17:29
> To: Maglione Roberta
> Cc: Wojciech Dec (wdec); ancp@ietf.org; Philippe Champagne=20 (pchamp)
> Subject: RE: question regarding Labels in ANCP port = up=20 messages
>
> Hi Maglione
>   Yes, the = label=20 format is as defined in RFC 3292. The ANCP draft is
> based on = RFC 3292=20 and proposes extensions/modifications where
> required.
> = This is=20 clearly stated upfront both in the abstract and in
> section 2. = In
> section 5.4.2, it clearly  specifies the format of = "port up"=20 message
> (based on RFC 3292), and explicitly states the label = field=20
> should be set
> to 0. Following is what the draft = currently=20 states:
>
>
> 5.4.2 Topology Discovery Extensions =
>=20
> The GSMP Event message with PORT UP message type (80) is used = for=20
> conveying DSL line attributes to the NAS. The version field = should be=20
> set to 3, and the sub field should be set to 1. The I and = subMessage=20
> fields SHOULD be set to 1 to signify no fragmentation. The = Port and=20
> Label fields should be set to 0.
>
> =20 = 0            =       =20 = 1            =       =20 = 2            =       =20 3
>          0 1 2 = 3 4 5 6=20 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
> 6 7 8 9 0 1
>=20
> 
>=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>         | Vers  = | =20 Sub  | Message Type  |=20 Result|        Code
> |=20
> 
>=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>         | Partition = ID =20 |           =20 Transaction Identifier
> |     =
> =20
> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>        =20 |I|      SubMessage=20 Number     =20 |           = Length
> |=20
> 
>=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>        =20 = |            =             &= nbsp;   =20 Port
> |
> 
>=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>        =20 = |            =          =20 Port Session Number
> |
> 
>=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>        =20 = |            =         =20 Event Sequence Number
> |
> 
>=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>         = |x|S|x|x|
> |=20
>        =20 = +-+-+-+-+          &nbs= p;         =20 Label
> | =
>        =20 ~
> ~
> 
>=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>         = |x|x|x|x|x|x|x|x|=20 Message Type  |   Tech Type   | Block = Length
>=20 |
> 
>=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>         |
> |=20
>        =20 = ~            =              = Extension Value
> ~=20
>         |
> |=20
> 
>=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= =20
> When we say the label field should be set to 0, the intention =
> is for the
> type and length fields in the label TLV to = be set=20 to 0. We can
> explicitly state this for clarity.
> =
>=20 -Sanjay
>
> >-----Original Message-----
> = >From:=20 Maglione Roberta [mailto:roberta.maglione@telecomitalia.it]
> = >Sent:=20 Tuesday, April 29, 2008 8:06 AM
> >To: Sanjay Wadhwa
> = >Cc:=20 Wojciech Dec (wdec); ancp@ietf.org; pchamp@cisco.com
> = >Subject: RE:=20 question regarding Labels in ANCP port up messages
> = >
>=20 >
> >Hi Sanjay and All,
> = >     I was=20 reading the current ancp protocol draft in order to
> > = understand=20 which should be the correct format for the label
> >field in = the=20 ancp port Up message.
> >Actually as it was already pointed = out in=20 the alias the draft
> >in section 5.4.2 says "GSMP Event = message=20 with PORT UP message
> >type (80) is used"  thus I am = assuming=20 that the label in the
> >port UP message should follow the = message=20 format defined in 
> >RFC 3292, section 3.1.3:
>=20 >
> >   =20 = 0            =       =20 = 1            =       =20 = 2            =       =20 3
> >    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 = 9 0 1 2=20 3 4 5 6 7 8 9 0 1
> >  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= =20 >   |x|S|x|x|       Label=20 Type     =20 |          Label=20 Length         |
>=20 >  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= =20 >  =20 = |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p; =20 |
> >  =20 = ~            =             &= nbsp;=20 Label=20 = Value           &n= bsp;           &nb= sp; =20 ~
> >  =20 = |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p; =20 |
> >  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= =20 >
> >but from what I have seen different implementations = use=20
> >different format for label field: in particular several =
>=20 >implementations use  a label format that is similar to the = one=20
> >specified in the expired draft=20 draft-ietf-gsmp-v3-base-spec:
> >
>=20 >    =20 = 0            =       =20 = 1            =       =20 = 2            =       =20 3
> >       0 1 2 3 4 5 6 7 8 9 = 0 1 2 3=20 4 5 6 7 8 9 0 1 2 3 4 5 6
> 7 8 9 0 1
>=20 >     
>=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= =20 >     =20 = |x|S|x|x|x|x|x|x|x|x|x|x|x|x|x|x|      &nbs= p;    =20 Label
> Type         = |
>=20 >     
>=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= =20 >      |    Label=20 Adaptation           = |          Label
> = Length         |
>=20 >     
>=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= =20 >     =20 = |            =             &= nbsp;           &n= bsp;           &nb= sp;    =20
>          = |
>=20 >     =20 = ~            =             &= nbsp;=20 Label=20 = Value           &n= bsp;    =20
>          = ~
>=20 >     =20 = |            =             &= nbsp;           &n= bsp;           &nb= sp;    =20
>          = |
>=20 >     
>=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= =20 >
> >
> >Even if ancp does not care about the = label=20 field, having this
> >field somehow not clearly specified in = the=20 current ancp draft
> >can easily lead to interoperability = issues,=20 thus I think it
> >would be very helpful if you and/or the = other=20 editors can
> >clarify what should be the correct format for = the=20 label field
> >to be used in the ancp Port Up = message.
>=20 >
> >Thanks and best regards,
> >Roberta
>=20 >
> >________________________________________
> = >From:=20 Philippe Champagne (pchamp) [pchamp@cisco.com]
> >Sent: = Thursday,=20 April 24, 2008 7:14 PM
> >To: Sanjay Wadhwa
> >Cc: = Maglione=20 Roberta; Wojciech Dec (wdec); ancp@ietf.org
> >Subject: = question=20 regarding  Labels in ANCP port up messages
> >
> = >Hi=20 Sanjay
> >
> >In section 5.4.2 of the draft, we=20 have:
> >
> >
>=20 >        =20 = 0            =       =20 = 1            =       =20 2          =20
>         3
>=20 >         0 1 2 3 4 5 6 7 8 = 9 0 1 2=20 3 4 5 6 7 8 9 0 1 2 3 4 5 6
> >7 8 9 0 1
>=20 >       
>=20 = >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= >=20 >        | Vers  |  = Sub =20 | Message Type  | = Result|       =20 Code 
> = >        =20 |
> >       
>=20 = >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= >=20 >        | Partition ID =20 |           =20 Transaction Identifier   
>=20 >         |
>=20 >       
>=20 = >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= >=20 >       =20 |I|      SubMessage=20 Number     =20 |          =20 Length    
>=20 >         |
>=20 >       
>=20 = >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= >=20 >       =20 = |            =             &= nbsp;   =20 = Port           &nb= sp;        =20
> >         = |
>=20 >       
>=20 = >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= >=20 >       =20 = |            =          =20 Port Session=20 = Number           &= nbsp;=20
> >         = |
>=20 >       
>=20 = >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= >=20 >       =20 = |            =         =20 Event Sequence=20 = Number            =
> >         = |
>=20 >       
>=20 = >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= >=20 >       =20 = |x|S|x|x|          &nbs= p;            = ;            =           =20
> >         = |
>=20 >       =20 = +-+-+-+-+          &nbs= p;         =20 = Label           &n= bsp;       =20
> >         = |
>=20 >       =20 = ~            =             &= nbsp;           &n= bsp;           &nb= sp;    =20
> >         = ~
>=20 >       
>=20 = >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= >=20 >        |x|x|x|x|x|x|x|x| = Message=20 Type  |   Tech Type   |
> >Block=20 Length  |
> >        =
>=20 = >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= >=20 >       =20 = |            =             &= nbsp;           &n= bsp;           &nb= sp;    =20
> >         = |
>=20 >       =20 = ~            =              = Extension=20 = Value           &n= bsp; =20
> >         = ~
>=20 >       =20 = |            =             &= nbsp;           &n= bsp;           &nb= sp;    =20
> >         = |
>=20 >       
>=20 = >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= >=20 >Where Label I suppose is taken from the RFC 3292, section
> = >3.1.3: (well, I'm guessing)
> >
> >   = A=20 summary of TLV labels supported in this version of the
> = protocol=20 is
> >   listed below:
> >
>=20 >      TLV = Label     =20 Type       Section Title
>=20 >      = ---------     =20 ----       -------------
>=20 >      ATM = Label     =20 0x100      ATM TLV Labels
>=20 >      FR=20 Label       = 0x101     =20 Frame Relay TLV Labels
> >      MPLS = Gen=20 Label 0x102      MPLS Generic TLV = Labels
>=20 >      FEC = Label     =20 0x103      FEC TLV Labels
> = >
>=20 >   All Labels will be designated as follow:
> = >
>=20 >   =20 = 0            =       =20 = 1            =       =20 = 2            =       =20 3
> >    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 = 9 0 1 2=20 3 4 5 6 7 8 9 0 1
> >  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= =20 >   |x|S|x|x|       Label=20 Type     =20 |          Label=20 Length         |
>=20 >  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= =20 >  =20 = |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p; =20 |
> >  =20 = ~            =             &= nbsp;=20 Label=20 = Value           &n= bsp;           &nb= sp; =20 ~
> >  =20 = |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p; =20 |
> >  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= =20 >
> >      x: Reserved = Flags.
>=20 >         These are = generally used=20 by specific messages and will be
>=20 >         defined in those=20 messages.
> >
> >      S: = Stacked=20 Label Indicator
> = >        =20 Label Stacking is discussed below in section 3.1.3.5
> = >
>=20 >      Label Type
>=20 >         A 12-bit field = indicating=20 the type of label.
> >
> = >     =20 Label Length
> = >         A=20 16-bit field indicating the length of the Label
> Value = field
>=20 >         in bytes.
> = >
> >      Label Value
>=20 >         A variable length = field=20 that is an integer number of 32 bit
>=20 >         words long.  = The=20 Label Value field is interpreted
> according to
>=20 >         the Label Type as = described in the following sections.
> >
> >
> = >The=20 draft is a bit obscure about this and since it doesn't
> = >specify=20 much, it can lead to misinterpretation for the unused
> = >part.=20 Moreover, it would appear that several implementations
> = >currently=20 use another format for the label field. Can you
> = >explain?  I=20 mean, how come what's in the current draft doesn't
> >match = what's=20 known to be implemented?
> >
> >I'm still wondering = why we=20 carried over pieces from GSMP that
> >we do not intend to=20 use.
> >
> >I would recommend that if we are to keep = them=20 but not use
> >them, we should mention precisely how we = intend not=20 to use
> >them: that is how many 0 filled bytes this is = expected to=20 use
> >
> >The rfc 3292 doesn't cover the case where = this=20 field is not used.
> >
> >Can you shed some ligths = on=20 this?
> >
> >Thanks
> >Regards
>=20 >Phil
> >
> >
> >
>=20 = >--------------------------------------------------------------------<= BR>>=20 >
> >CONFIDENTIALITY NOTICE
> >
> >This = message=20 and its attachments are addressed solely to the
> >persons = above and=20 may contain confidential information. If you
> >have = received the=20 message in error, be informed that any use
> >of the content = hereof=20 is prohibited. Please return it
> >immediately to the sender = and=20 delete the message. Should you
> >have any questions, please = contact=20 us by replying to
> >webmaster@telecomitalia.it.
>=20 >
> >        Thank = you
>=20 >
>=20 = >           &nb= sp;           &nbs= p;            = ;   =20 www.telecomitalia.it
>=20 >
>=20 = >--------------------------------------------------------------------<= BR>>=20 = >           &nb= sp;           =20
> >
>=20
_______________________________________________
ANCP mailing = list
ANCP@ietf.org
https://www.ietf.org/= mailman/listinfo/ancp --Boundary_(ID_4ob3YVH46eWB+wEsVodK9Q)-- --===============1163296491== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============1163296491==-- From ancp-bounces@ietf.org Wed Apr 30 12:55:46 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 170613A698A; Wed, 30 Apr 2008 12:55:46 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 562333A698A for ; Wed, 30 Apr 2008 12:55:45 -0700 (PDT) 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=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0Iw71hv1HOf for ; Wed, 30 Apr 2008 12:55:43 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 95EE53A6943 for ; Wed, 30 Apr 2008 12:55:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 916BD2FE9E5; Wed, 30 Apr 2008 12:55:46 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30258-04; Wed, 30 Apr 2008 12:55:46 -0700 (PDT) Received: from rbsjx.ad.redback.com (rbsjxh2.redback.com [155.53.14.106]) by prattle.redback.com (Postfix) with ESMTP id 070A22FE9E4; Wed, 30 Apr 2008 12:55:43 -0700 (PDT) Received: from RBSJX.ad.redback.com ([155.53.14.103]) by rbsjxh2.ad.redback.com ([155.53.14.106]) with mapi; Wed, 30 Apr 2008 12:55:43 -0700 From: Peter Arberg To: Tina TSOU , Maglione Roberta , Sanjay Wadhwa , "Wojciech Dec (wdec)" Date: Wed, 30 Apr 2008 12:55:41 -0700 Thread-Topic: [ANCP] question regarding Labels in ANCP port up messages Thread-Index: Aciqkn5nSPBPuwuySsamcvxF1uU6kQAZ9dQQ Message-ID: <48C276B536524E478C659685995F6AA539DBBBE370@RBSJX.ad.redback.com> References: <9BD5D7887235424FA97DFC223CAE3C280AB439FC@proton.jnpr.net> <00d001c8aa92$67515630$ac4c460a@china.huawei.com> In-Reply-To: <00d001c8aa92$67515630$ac4c460a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at redback.com Cc: "ancp@ietf.org" Subject: Re: [ANCP] question regarding Labels in ANCP port up messages X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hi, some times I think it is amazing we ever got interoperability of ANCP :-) because looking at the label discussion is a very good example that the whole GSMP - ANCP reference have not worked very well. In the ANCP draft, section 5.4.2 the event message is shown like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub | Message Type | Result| Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Session Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Event Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|S|x|x| | +-+-+-+-+ Label | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Extension Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This is the exact same event message defined in draft-ietf-gsmp-v3-base-spec-08.txt section 11. And in this gsmp-draft, section 5.1.3 the label space is defined as minimum 8 bytes if the length=0 and as such no value, and this is because the gsmp-draft has a new "label adaptaion" field. BUT in RFC3292 the event message is show in section 9, like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Result | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Session Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Event Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|S|x|x| | +-+-+-+-+ Label | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ So a different Event Message picture/definition than what is shown in the ANCP draft, and in RFC3292 section 3.1.3 the label field is defined as 4 bytes if length=0 and as such no value. So I very much agree with Woj that we need this issue to be resolved, and proabably a show of hands what is actually done in different implementations, so we can nail down how the event message is suppose to look like in ANCP. I know at least 1 implementation which uses 8 bytes for the label field. cheers, Peter ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Tina TSOU Sent: 30. april 2008 00:19 To: Maglione Roberta; Sanjay Wadhwa; Wojciech Dec (wdec) Cc: ancp@ietf.org Subject: Re: [ANCP] question regarding Labels in ANCP port up messages Hi all, It is clear to me that if Label Length is filled as 0, there is nothing to be filled into Label Value. The whole Label part is 4 bytes, not 8 bytes. Cheers from the last working day before Labor's Day holidays in some countries:) Tina ----- Original Message ----- From: Wojciech Dec (wdec) To: Sanjay Wadhwa ; Maglione Roberta Cc: ancp@ietf.org Sent: Wednesday, April 30, 2008 1:12 AM Subject: Re: [ANCP] question regarding Labels in ANCP port up messages Sanjay, All, What is stated below runs counter to at least a handful of ANCP implementations, all of which are known to be interoperable. There are really two options: 1) The current version of the spec is correct, and the known interoperable implementations do not follow it 2) The current version of the spec is not accurate, and does not reflect the fact that the known implementations follow the label field definition from draft-gsmpv3-base-spec. I would like to ask you, as the lead editor of the spec, to work with the WG in resolving what the problem is, and clearing up what the WG spec says about and if 1) holds to be true, then proposing an interoperability fix. In either case, the issue highlights the fact that there is still lingering confusion as to the dependencies ANCP has on rfc3292, or draft-gsmpv3-base-spec, or both. It seems to be in the best interest of all to address these. Regards, Woj. > -----Original Message----- > From: Sanjay Wadhwa [mailto:swadhwa@juniper.net] > Sent: 29 April 2008 17:29 > To: Maglione Roberta > Cc: Wojciech Dec (wdec); ancp@ietf.org; Philippe Champagne (pchamp) > Subject: RE: question regarding Labels in ANCP port up messages > > Hi Maglione > Yes, the label format is as defined in RFC 3292. The ANCP draft is > based on RFC 3292 and proposes extensions/modifications where > required. > This is clearly stated upfront both in the abstract and in > section 2. In > section 5.4.2, it clearly specifies the format of "port up" message > (based on RFC 3292), and explicitly states the label field > should be set > to 0. Following is what the draft currently states: > > > 5.4.2 Topology Discovery Extensions > > The GSMP Event message with PORT UP message type (80) is used for > conveying DSL line attributes to the NAS. The version field should be > set to 3, and the sub field should be set to 1. The I and subMessage > fields SHOULD be set to 1 to signify no fragmentation. The Port and > Label fields should be set to 0. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vers | Sub | Message Type | Result| Code > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Partition ID | Transaction Identifier > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |I| SubMessage Number | Length > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Port > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Port Session Number > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Event Sequence Number > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |x|S|x|x| > | > +-+-+-+-+ Label > | > ~ > ~ > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | > | > ~ Extension Value > ~ > | > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > When we say the label field should be set to 0, the intention > is for the > type and length fields in the label TLV to be set to 0. We can > explicitly state this for clarity. > > -Sanjay > > >-----Original Message----- > >From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] > >Sent: Tuesday, April 29, 2008 8:06 AM > >To: Sanjay Wadhwa > >Cc: Wojciech Dec (wdec); ancp@ietf.org; pchamp@cisco.com > >Subject: RE: question regarding Labels in ANCP port up messages > > > > > >Hi Sanjay and All, > > I was reading the current ancp protocol draft in order to > > understand which should be the correct format for the label > >field in the ancp port Up message. > >Actually as it was already pointed out in the alias the draft > >in section 5.4.2 says "GSMP Event message with PORT UP message > >type (80) is used" thus I am assuming that the label in the > >port UP message should follow the message format defined in > >RFC 3292, section 3.1.3: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |x|S|x|x| Label Type | Label Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > ~ Label Value ~ > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >but from what I have seen different implementations use > >different format for label field: in particular several > >implementations use a label format that is similar to the one > >specified in the expired draft draft-ietf-gsmp-v3-base-spec: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |x|S|x|x|x|x|x|x|x|x|x|x|x|x|x|x| Label > Type | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Label Adaptation | Label > Length | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | > | > > ~ Label Value > ~ > > | > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > >Even if ancp does not care about the label field, having this > >field somehow not clearly specified in the current ancp draft > >can easily lead to interoperability issues, thus I think it > >would be very helpful if you and/or the other editors can > >clarify what should be the correct format for the label field > >to be used in the ancp Port Up message. > > > >Thanks and best regards, > >Roberta > > > >________________________________________ > >From: Philippe Champagne (pchamp) [pchamp@cisco.com] > >Sent: Thursday, April 24, 2008 7:14 PM > >To: Sanjay Wadhwa > >Cc: Maglione Roberta; Wojciech Dec (wdec); ancp@ietf.org > >Subject: question regarding Labels in ANCP port up messages > > > >Hi Sanjay > > > >In section 5.4.2 of the draft, we have: > > > > > > 0 1 2 > 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > >7 8 9 0 1 > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Vers | Sub | Message Type | Result| Code > > | > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Partition ID | Transaction Identifier > > | > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |I| SubMessage Number | Length > > | > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Port > > | > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Port Session Number > > | > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Event Sequence Number > > | > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |x|S|x|x| > > | > > +-+-+-+-+ Label > > | > > ~ > > ~ > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |x|x|x|x|x|x|x|x| Message Type | Tech Type | > >Block Length | > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | > > | > > ~ Extension Value > > ~ > > | > > | > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >Where Label I suppose is taken from the RFC 3292, section > >3.1.3: (well, I'm guessing) > > > > A summary of TLV labels supported in this version of the > protocol is > > listed below: > > > > TLV Label Type Section Title > > --------- ---- ------------- > > ATM Label 0x100 ATM TLV Labels > > FR Label 0x101 Frame Relay TLV Labels > > MPLS Gen Label 0x102 MPLS Generic TLV Labels > > FEC Label 0x103 FEC TLV Labels > > > > All Labels will be designated as follow: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |x|S|x|x| Label Type | Label Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > ~ Label Value ~ > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > x: Reserved Flags. > > These are generally used by specific messages and will be > > defined in those messages. > > > > S: Stacked Label Indicator > > Label Stacking is discussed below in section 3.1.3.5 > > > > Label Type > > A 12-bit field indicating the type of label. > > > > Label Length > > A 16-bit field indicating the length of the Label > Value field > > in bytes. > > > > Label Value > > A variable length field that is an integer number of 32 bit > > words long. The Label Value field is interpreted > according to > > the Label Type as described in the following sections. > > > > > >The draft is a bit obscure about this and since it doesn't > >specify much, it can lead to misinterpretation for the unused > >part. Moreover, it would appear that several implementations > >currently use another format for the label field. Can you > >explain? I mean, how come what's in the current draft doesn't > >match what's known to be implemented? > > > >I'm still wondering why we carried over pieces from GSMP that > >we do not intend to use. > > > >I would recommend that if we are to keep them but not use > >them, we should mention precisely how we intend not to use > >them: that is how many 0 filled bytes this is expected to use > > > >The rfc 3292 doesn't cover the case where this field is not used. > > > >Can you shed some ligths on this? > > > >Thanks > >Regards > >Phil > > > > > > > >-------------------------------------------------------------------- > > > >CONFIDENTIALITY NOTICE > > > >This message and its attachments are addressed solely to the > >persons above and may contain confidential information. If you > >have received the message in error, be informed that any use > >of the content hereof is prohibited. Please return it > >immediately to the sender and delete the message. Should you > >have any questions, please contact us by replying to > >webmaster@telecomitalia.it. > > > > Thank you > > > > www.telecomitalia.it > > > >-------------------------------------------------------------------- > > > > > _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Apr 30 14:42:24 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1829628C0E8; Wed, 30 Apr 2008 14:42:24 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54A3F3A67F2 for ; Wed, 30 Apr 2008 14:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRk4bN3GEb8f for ; Wed, 30 Apr 2008 14:42:20 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 589493A6A76 for ; Wed, 30 Apr 2008 14:42:14 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Wed, 30 Apr 2008 14:42:16 PDT Received: from proton.jnpr.net ([10.10.2.37]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Apr 2008 14:42:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 17:42:01 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280AB43A10@proton.jnpr.net> In-Reply-To: <48C276B536524E478C659685995F6AA539DBBBE370@RBSJX.ad.redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] question regarding Labels in ANCP port up messages Thread-Index: Aciqkn5nSPBPuwuySsamcvxF1uU6kQAZ9dQQAAE415A= From: "Sanjay Wadhwa" To: "Peter Arberg" , "Tina TSOU" , "Maglione Roberta" , "Wojciech Dec (wdec)" X-OriginalArrivalTime: 30 Apr 2008 21:42:04.0728 (UTC) FILETIME=[08003380:01C8AB0B] Cc: ancp@ietf.org Subject: Re: [ANCP] question regarding Labels in ANCP port up messages X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0766194272==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0766194272== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8AB0B.06341E6F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8AB0B.06341E6F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Peter The ANCP draft as it currently stands is based on RFC3292. It provides extensions and modifications to relevant constructs in RFC3292. There is no mention (implicit or explicit) of expired GSMP drafts in the ANCP draft. In order to implement the ANCP draft, I am not sure why one would look at the expired GSMP drafts. Do you see a reason to do this based on anything that you read in the ANCP draft? Bringing up reference to expired gsmp draft in this thread just adds to the confusion. For GSMPv3 objects in the messages (such as Label Type), one has to look at RFC3292 (this is clearly stated in the ANCP draft - section 2 and I am quoting it below) : ANCP uses a subset of GSMPv3 messages to implement currently defined use-cases. These relevant GSMPv3 messages are identified in section 5. GSMPv3 procedures with suitable extensions, as used by ANCP, are described in sections 5.1, 5.2 and 5.3. GSMPv3 general extensions and GSMPv3 message specific extensions required by ANCP are described in sub-sections of 5.4. In addition to specifying extensions and modifications to relevant GSMP messages applicable to ANCP, this draft also defines the usage of these messages by ANCP, and indicates the values that ANCP should set for relevant fields in these GSMP messages. However, to understand the basic semantics of various fields in GSMP messages, the reader is referred to [4]. =3D> RFC 3292. What existing implementations currently do is an important but separate issue. These implementations for most part precede the current ANCP draft. It is fine to poll where these implementations diverge from the current draft. It is then upto the implementations (including the one that I am somewhat familiar with) to work towards compliance with the draft.=20 On the following points from Woj: Woj>2) The current version of the spec is not accurate, and does not reflect the fact that the known implementations follow the label field definition from draft-gsmpv3-base-spec. It is not for the protocol draft to point out what current implementations do. The best we can do is to further clarify in the draft that type and value fields of the Label object (defined in RFC3292) should be set to 0 in the port-up message (we already mention the lable object as a whole should be set to all 0s).=20 Woj> This would be a good thing for the WG to discuss. There most evidently is a fair amount of "dead wood" in the current spec, ie stuff that nobody yet implements or cares about. In the former case, we could re-cast that material using the new notions/extensions, in the latter case simply chop it out. I agree. We are based on GSMPv3 (RFC3292) messages, and obviously not everything in these messages is leveraged by ANCP. However, the sync rate and OAM uses-cases are implemented and in use (ideally we should leave these alone...i.e. no change beyond adding more clarity if needed). For anything new (such as multicast) we are defining new messages (no legacy). =20 -Sanjay >-----Original Message----- >From: Peter Arberg [ mailto:parberg@redback.com] >Sent: Wednesday, April 30, 2008 3:56 PM >To: Tina TSOU; Maglione Roberta; Sanjay Wadhwa; Wojciech Dec (wdec) >Cc: ancp@ietf.org >Subject: RE: [ANCP] question regarding Labels in ANCP port up messages > > >Hi, > >some times I think it is amazing we ever got interoperability >of ANCP :-) >because looking at the label discussion is a very good example that the >whole GSMP - ANCP reference have not worked very well. > >In the ANCP draft, section 5.4.2 the event message is shown like this: > >0 1 2 3 >0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Vers | Sub | Message Type | Result| Code | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Partition ID | Transaction Identifier | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >|I| SubMessage Number | Length | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Port | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Port Session Number | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Event Sequence Number | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >|x|S|x|x| | >+-+-+-+-+ Label | >~ ~ >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >|x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| | >~ Extension Value ~ >| | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >This is the exact same event message defined in >draft-ietf-gsmp-v3-base-spec-08.txt section 11. > >And in this gsmp-draft, section 5.1.3 the label space is defined >as minimum 8 bytes if the length=3D0 and as such no value, and this >is because the gsmp-draft has a new "label adaptaion" field. > > > >BUT in RFC3292 the event message is show in section 9, like this: > >0 1 2 3 >0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Version | Message Type | Result | Code | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Partition ID | Transaction Identifier | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >|I| SubMessage Number | Length | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Port | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Port Session Number | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Event Sequence Number | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >|x|S|x|x| | >+-+-+-+-+ Label | >~ ~ >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >So a different Event Message picture/definition than what is shown >in the ANCP draft, and in RFC3292 section 3.1.3 the label field >is defined as 4 bytes if length=3D0 and as such no value. > > > >So I very much agree with Woj that we need this issue to be resolved, >and proabably a show of hands what is actually done in different >implementations, so we can nail down how the event message is >suppose to look like in ANCP. > > >I know at least 1 implementation which uses 8 bytes for the >label field. > > >cheers, >Peter > > > > > > >________________________________ > > From: ancp-bounces@ietf.org >[ mailto:ancp-bounces@ietf.org] On Behalf Of Tina TSOU > Sent: 30. april 2008 00:19 > To: Maglione Roberta; Sanjay Wadhwa; Wojciech Dec (wdec) > Cc: ancp@ietf.org > Subject: Re: [ANCP] question regarding Labels in ANCP >port up messages > > > Hi all, > It is clear to me that if Label Length is filled as 0, >there is nothing to be filled into Label Value. The whole >Label part is 4 bytes, not 8 bytes. > > Cheers from the last working day before Labor's Day >holidays in some countries:) > > Tina > > ----- Original Message ----- > From: Wojciech Dec (wdec) < mailto:wdec@cisco.com> > To: Sanjay Wadhwa < mailto:swadhwa@juniper.net> > ; Maglione Roberta < mailto:roberta.maglione@telecomitalia.it> > Cc: ancp@ietf.org > Sent: Wednesday, April 30, 2008 1:12 AM > Subject: Re: [ANCP] question regarding Labels >in ANCP port up messages > > Sanjay, All, > > What is stated below runs counter to at least >a handful of ANCP > implementations, all of which are known to be >interoperable. > There are really two options: > 1) The current version of the spec is correct, >and the known > interoperable implementations do not follow it > 2) The current version of the spec is not >accurate, and does not reflect > the fact that the known implementations follow >the label field > definition from draft-gsmpv3-base-spec. > > I would like to ask you, as the lead editor of >the spec, to work with > the WG in resolving what the problem is, and >clearing up what the WG > spec says about and if 1) holds to be true, >then proposing an > interoperability fix. > > In either case, the issue highlights the fact >that there is still > lingering confusion as to the dependencies >ANCP has on rfc3292, or > draft-gsmpv3-base-spec, or both. It seems to >be in the best interest of > all to address these. > > Regards, > Woj. > > > -----Original Message----- > > From: Sanjay Wadhwa [ mailto:swadhwa@juniper.net] > > Sent: 29 April 2008 17:29 > > To: Maglione Roberta > > Cc: Wojciech Dec (wdec); ancp@ietf.org; >Philippe Champagne (pchamp) > > Subject: RE: question regarding Labels in >ANCP port up messages > > > > Hi Maglione > > Yes, the label format is as defined in RFC >3292. The ANCP draft is > > based on RFC 3292 and proposes >extensions/modifications where > > required. > > This is clearly stated upfront both in the >abstract and in > > section 2. In > > section 5.4.2, it clearly specifies the >format of "port up" message > > (based on RFC 3292), and explicitly states >the label field > > should be set > > to 0. Following is what the draft currently states: > > > > > > 5.4.2 Topology Discovery Extensions > > > > The GSMP Event message with PORT UP message >type (80) is used for > > conveying DSL line attributes to the NAS. >The version field should be > > set to 3, and the sub field should be set to >1. The I and subMessage > > fields SHOULD be set to 1 to signify no >fragmentation. The Port and > > Label fields should be set to 0. > > > > 0 1 2 =20 > 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 >8 9 0 1 2 3 4 5 > > 6 7 8 9 0 1 > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Vers | Sub | Message Type | >Result| Code > > | > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Partition ID | =20 >Transaction Identifier > > | > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |I| SubMessage Number | =20 > Length > > | > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Port > > | > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Port Session Number > > | > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Event Sequence Number > > | > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |x|S|x|x| > > | > > +-+-+-+-+ Label > > | > > ~ > > ~ > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |x|x|x|x|x|x|x|x| Message Type | =20 >Tech Type | Block Length > > | > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | > > | > > ~ Extension Value > > ~ > > | > > | > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > When we say the label field should be set to >0, the intention > > is for the > > type and length fields in the label TLV to >be set to 0. We can > > explicitly state this for clarity. > > > > -Sanjay > > > > >-----Original Message----- > > >From: Maglione Roberta >[ mailto:roberta.maglione@telecomitalia.it] > > >Sent: Tuesday, April 29, 2008 8:06 AM > > >To: Sanjay Wadhwa > > >Cc: Wojciech Dec (wdec); ancp@ietf.org; >pchamp@cisco.com > > >Subject: RE: question regarding Labels in >ANCP port up messages > > > > > > > > >Hi Sanjay and All, > > > I was reading the current ancp >protocol draft in order to > > > understand which should be the correct >format for the label > > >field in the ancp port Up message. > > >Actually as it was already pointed out in >the alias the draft > > >in section 5.4.2 says "GSMP Event message >with PORT UP message > > >type (80) is used" thus I am assuming that >the label in the > > >port UP message should follow the message >format defined in > > >RFC 3292, section 3.1.3: > > > > > > 0 1 =20 >2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 >0 1 2 3 4 5 6 7 8 9 0 1 > > > =20 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |x|S|x|x| Label Type | =20 > Label Length | > > > =20 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | =20 > | > > > ~ Label Value =20 > ~ > > > | =20 > | > > > =20 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > >but from what I have seen different >implementations use > > >different format for label field: in >particular several > > >implementations use a label format that is >similar to the one > > >specified in the expired draft >draft-ietf-gsmp-v3-base-spec: > > > > > > 0 1 =20 > 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 >8 9 0 1 2 3 4 5 6 > > 7 8 9 0 1 > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |x|S|x|x|x|x|x|x|x|x|x|x|x|x|x|x| =20 > Label > > Type | > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Label Adaptation | =20 > Label > > Length | > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | > > | > > > ~ Label Value > > ~ > > > | > > | > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > >Even if ancp does not care about the label >field, having this > > >field somehow not clearly specified in the >current ancp draft > > >can easily lead to interoperability issues, >thus I think it > > >would be very helpful if you and/or the >other editors can > > >clarify what should be the correct format >for the label field > > >to be used in the ancp Port Up message. > > > > > >Thanks and best regards, > > >Roberta > > > > > >________________________________________ > > >From: Philippe Champagne (pchamp) [pchamp@cisco.com] > > >Sent: Thursday, April 24, 2008 7:14 PM > > >To: Sanjay Wadhwa > > >Cc: Maglione Roberta; Wojciech Dec (wdec); >ancp@ietf.org > > >Subject: question regarding Labels in ANCP >port up messages > > > > > >Hi Sanjay > > > > > >In section 5.4.2 of the draft, we have: > > > > > > > > > 0 1 2 > > 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 >7 8 9 0 1 2 3 4 5 6 > > >7 8 9 0 1 > > > > > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Vers | Sub | Message Type | >Result| Code > > > | > > > > > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Partition ID | =20 >Transaction Identifier > > > | > > > > > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |I| SubMessage Number | =20 > Length > > > | > > > > > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Port > > > | > > > > > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Port Session Number > > > | > > > > > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Event Sequence Number > > > | > > > > > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |x|S|x|x| > > > | > > > +-+-+-+-+ Label > > > | > > > ~ > > > ~ > > > > > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |x|x|x|x|x|x|x|x| Message Type | =20 >Tech Type | > > >Block Length | > > > > > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | > > > | > > > ~ Extension Value > > > ~ > > > | > > > | > > > > > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >Where Label I suppose is taken from the RFC >3292, section > > >3.1.3: (well, I'm guessing) > > > > > > A summary of TLV labels supported in >this version of the > > protocol is > > > listed below: > > > > > > TLV Label Type Section Title > > > --------- ---- ------------- > > > ATM Label 0x100 ATM TLV Labels > > > FR Label 0x101 Frame Relay >TLV Labels > > > MPLS Gen Label 0x102 MPLS >Generic TLV Labels > > > FEC Label 0x103 FEC TLV Labels > > > > > > All Labels will be designated as follow: > > > > > > 0 1 =20 >2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 >0 1 2 3 4 5 6 7 8 9 0 1 > > > =20 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |x|S|x|x| Label Type | =20 > Label Length | > > > =20 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | =20 > | > > > ~ Label Value =20 > ~ > > > | =20 > | > > > =20 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > x: Reserved Flags. > > > These are generally used by >specific messages and will be > > > defined in those messages. > > > > > > S: Stacked Label Indicator > > > Label Stacking is discussed below >in section 3.1.3.5 > > > > > > Label Type > > > A 12-bit field indicating the type >of label. > > > > > > Label Length > > > A 16-bit field indicating the >length of the Label > > Value field > > > in bytes. > > > > > > Label Value > > > A variable length field that is an >integer number of 32 bit > > > words long. The Label Value field >is interpreted > > according to > > > the Label Type as described in the >following sections. > > > > > > > > >The draft is a bit obscure about this and >since it doesn't > > >specify much, it can lead to >misinterpretation for the unused > > >part. Moreover, it would appear that >several implementations > > >currently use another format for the label >field. Can you > > >explain? I mean, how come what's in the >current draft doesn't > > >match what's known to be implemented? > > > > > >I'm still wondering why we carried over >pieces from GSMP that > > >we do not intend to use. > > > > > >I would recommend that if we are to keep >them but not use > > >them, we should mention precisely how we >intend not to use > > >them: that is how many 0 filled bytes this >is expected to use > > > > > >The rfc 3292 doesn't cover the case where >this field is not used. > > > > > >Can you shed some ligths on this? > > > > > >Thanks > > >Regards > > >Phil > > > > > > > > > > > >>-------------------------------------------------------------------- > > > > > >CONFIDENTIALITY NOTICE > > > > > >This message and its attachments are >addressed solely to the > > >persons above and may contain confidential >information. If you > > >have received the message in error, be >informed that any use > > >of the content hereof is prohibited. Please >return it > > >immediately to the sender and delete the >message. Should you > > >have any questions, please contact us by replying to > > >webmaster@telecomitalia.it. > > > > > > Thank you > > > > > > =20 >www.telecomitalia.it > > > > > >>-------------------------------------------------------------------- > > > > > > > > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp > >=20 ------_=_NextPart_001_01C8AB0B.06341E6F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Peter
  The ANCP draft as it currently stands = is based=20 on RFC3292. It provides extensions and modifications to relevant = constructs in=20 RFC3292. There is no mention (implicit or explicit) of expired GSMP = drafts in=20 the ANCP draft. In order to implement the ANCP draft, I am not sure why = one=20 would look at the expired GSMP drafts. Do you see a reason to do this = based on=20 anything that you read in the ANCP draft? Bringing up reference to = expired gsmp=20 draft in this thread just adds to the confusion. For GSMPv3 objects = in the=20 messages (such as Label Type), one has to look at RFC3292 (this is = clearly=20 stated in the ANCP draft - section 2 and I am quoting it below) = :

ANCP uses a subset of GSMPv3 = messages to=20 implement currently defined use-cases. These relevant GSMPv3 messages = are=20 identified in section 5. GSMPv3 procedures with suitable extensions, as = used by=20 ANCP, are described in sections 5.1, 5.2 and 5.3. GSMPv3 general = extensions and=20 GSMPv3 message specific extensions required by ANCP are described in=20 sub-sections of 5.4. In addition to specifying extensions and = modifications to=20 relevant GSMP messages applicable to ANCP, this draft also defines the = usage of=20 these messages by ANCP, and indicates the values that ANCP should set = for=20 relevant fields in these GSMP messages. However, to understand the basic = semantics of various fields in GSMP messages, the reader is referred to=20 [4]. =3D> RFC 3292.

What existing implementations = currently=20 do is an important but separate issue. These implementations for most = part=20 precede the current ANCP draft. It is fine to poll where these = implementations=20 diverge from the current draft. It is then upto the implementations = (including=20 the one that I am somewhat familiar with) to work towards compliance = with the=20 draft.

On the following points from =  Woj:

Woj>2) The current version of the spec is not = accurate, and=20 does not reflect the fact that the known implementations follow the = label=20 field definition from draft-gsmpv3-base-spec.

It is not for the protocol draft to point out what = current=20 implementations do.  The best we can do is to further clarify = in the=20 draft that type and value fields of the Label object (defined in = RFC3292) should=20 be set to 0 in the port-up message (we already mention the lable = object as=20 a whole should be set to all 0s).

Woj> This would be a good thing for the WG = to=20 discuss. There most evidently is a fair amount of "dead wood" in = the=20 current spec, ie stuff that nobody yet implements or cares about. =  In=20 the former case, we could re-cast that material using the new=20 notions/extensions, in the latter case simply chop it=20 out.

I=20 agree. We are based on GSMPv3 (RFC3292)  messages, and obviously = not=20 everything in these messages is leveraged by ANCP.  However, the = sync rate=20 and OAM uses-cases are implemented and in use (ideally we should leave = these=20 alone...i.e. no change beyond adding more clarity if needed). For = anything new=20 (such as multicast) we are defining new messages (no legacy).  =

-Sanjay

>-----Original = Message-----
>From: Peter=20 Arberg [mailto:parberg@redback.com]
>Sent:=20 Wednesday, April 30, 2008 3:56 PM
>To: Tina TSOU; Maglione = Roberta; Sanjay=20 Wadhwa; Wojciech Dec (wdec)
>Cc: ancp@ietf.org
>Subject: RE: = [ANCP]=20 question regarding Labels in ANCP port up=20 messages
>
>
>Hi,
>
>some times I think it = is=20 amazing we ever got interoperability
>of ANCP :-)
>because = looking=20 at the label discussion is a very good example that the
>whole = GSMP - ANCP=20 reference have not worked very well.
>
>In the ANCP draft, = section=20 5.4.2 the event message is shown like=20 this:
>
>0        &nb= sp;         =20 1            =       =20 2            =       =20 3
>0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0=20 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|=20 Vers  |  Sub  | Message Type  |=20 Result|       =20 Code          =20 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|=20 Partition ID =20 |            = Transaction=20 Identifier          &nb= sp; =20 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|I|     =20 SubMessage Number     =20 |          =20 Length           &= nbsp; =20 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|          &nb= sp;           &nbs= p;     =20 Port           &nb= sp;           &nbs= p;     =20 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|          &nb= sp;          =20 Port Session=20 Number           &= nbsp;         =20 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|          &nb= sp;         =20 Event Sequence=20 Number           &= nbsp;        =20 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|x|S|x|x|         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;        =20 |
>+-+-+-+-+         &= nbsp;          =20 Label           &n= bsp;           &nb= sp;    =20 |
>~          &nb= sp;           &nbs= p;            = ;            =             &= nbsp;  =20 ~
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|x|x|x|x|x|x|x|x|=20 Message Type  |   Tech Type   | Block = Length =20 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|          &nb= sp;           &nbs= p;            = ;            =             &= nbsp;  =20 |
>~          &nb= sp;           &nbs= p; =20 Extension=20 Value           &n= bsp;          =20 ~
>|          &nb= sp;           &nbs= p;            = ;            =             &= nbsp;  =20 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>
>
>This=20 is the exact same event message defined=20 in
>draft-ietf-gsmp-v3-base-spec-08.txt  section=20 11.
>
>And in this gsmp-draft, section 5.1.3 the label space = is=20 defined
>as minimum 8 bytes if the length=3D0 and as such no = value, and=20 this
>is because the gsmp-draft has a new "label adaptaion"=20 field.
>
>
>
>BUT in RFC3292 the event message = is show=20 in section 9, like=20 this:
>
>0        &nb= sp;         =20 1            =       =20 2            =       =20 3
>0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0=20 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|   =20 Version    | Message Type  |   =20 Result     |    =20 Code     =20 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|=20 Partition ID =20 |            = Transaction=20 Identifier          &nb= sp; =20 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|I|     =20 SubMessage Number     =20 |          =20 Length           &= nbsp; =20 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|          &nb= sp;           &nbs= p;     =20 Port           &nb= sp;           &nbs= p;     =20 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|          &nb= sp;          =20 Port Session=20 Number           &= nbsp;         =20 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|          &nb= sp;         =20 Event Sequence=20 Number           &= nbsp;        =20 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|x|S|x|x|         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;        =20 |
>+-+-+-+-+         &= nbsp;          =20 Label           &n= bsp;           &nb= sp;    =20 |
>~          &nb= sp;           &nbs= p;            = ;            =             &= nbsp;  =20 ~
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>
>
>So=20 a different Event Message picture/definition than what is = shown
>in the=20 ANCP draft, and in RFC3292 section 3.1.3 the label field
>is = defined as 4=20 bytes if length=3D0 and as such no = value.
>
>
>
>So I very=20 much agree with Woj that we need this issue to be resolved,
>and = proabably=20 a show of hands what is actually done in = different
>implementations, so we=20 can nail down how the event message is
>suppose to look like in=20 ANCP.
>
>
>I know at least 1 implementation which uses = 8 bytes=20 for the
>label=20 field.
>
>
>cheers,
>Peter
>
>
>= ;
>
>
>
>________________________________
>=
>       =20 From: ancp-bounces@ietf.org
>[mailto:ancp-bounces@ietf.org] On = Behalf Of Tina=20 TSOU
>        Sent: 30. april = 2008=20 00:19
>        To: Maglione = Roberta;=20 Sanjay Wadhwa; Wojciech Dec=20 (wdec)
>        Cc:=20 ancp@ietf.org
>        Subject: = Re:=20 [ANCP] question regarding Labels in ANCP
>port up=20 messages
>
>
>       = ; Hi=20 all,
>        It is clear to me = that if=20 Label Length is filled as 0,
>there is nothing to be filled into = Label=20 Value. The whole
>Label part is 4 bytes, not 8=20 bytes.
>
>        Cheers = from the=20 last working day before Labor's Day
>holidays in some=20 countries:)
>
>       =20 Tina
>
>         = ;      =20 ----- Original Message=20 -----
>          =      =20 From: Wojciech Dec (wdec) <mailto:wdec@cisco.com>
>        &nbs= p;      =20 To: Sanjay Wadhwa <mailto:swadhwa@juniper.net>
> ; Maglione=20 Roberta <mailto:roberta.maglione@telecomitalia.it>
>        &nbs= p;      =20 Cc:=20 ancp@ietf.org
>        &nbs= p;      =20 Sent: Wednesday, April 30, 2008 1:12=20 AM
>          &nb= sp;    =20 Subject: Re: [ANCP] question regarding Labels
>in ANCP port up=20 messages
>
>        &= nbsp;      =20 Sanjay,=20 All,
>
>         = ;      =20 What is stated below runs counter to at least
>a handful of=20 ANCP
>          &= nbsp;    =20 implementations, all of which are known to=20 be
>interoperable.
>       = ;        =20 There are really two=20 options:
>         &nb= sp;     =20 1) The current version of the spec is correct,
>and the=20 known
>          =      =20 interoperable implementations do not follow=20 it
>          &nb= sp;    =20 2) The current version of the spec is not
>accurate, and does not=20 reflect
>         &nbs= p;     =20 the fact that the known implementations follow
>the label=20 field
>          =      =20 definition from=20 draft-gsmpv3-base-spec.
>
>     &nbs= p;         =20 I would like to ask you, as the lead editor of
>the spec, to work=20 with
>          &= nbsp;    =20 the WG in resolving what the problem is, and
>clearing up what the = WG
>          &nb= sp;    =20 spec says about and if 1) holds to be true,
>then proposing=20 an
>          &nb= sp;    =20 interoperability=20 fix.
>
>         = ;      =20 In either case, the issue highlights the fact
>that there is=20 still
>          =      =20 lingering confusion as to the dependencies
>ANCP has on rfc3292,=20 or
>          &nb= sp;    =20 draft-gsmpv3-base-spec, or both. It seems to
>be in the best = interest=20 of
>          &nb= sp;    =20 all to address=20 these.
>
>        &nb= sp;      =20 Regards,
>         &nb= sp;     =20 Woj.
>
>         = ;      =20 > -----Original=20 Message-----
>         = ;      =20 > From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]
>         &= nbsp;     =20 > Sent: 29 April 2008=20 17:29
>          =      =20 > To: Maglione=20 Roberta
>         &nbs= p;     =20 > Cc: Wojciech Dec (wdec); ancp@ietf.org;
>Philippe Champagne=20 (pchamp)
>         &nb= sp;     =20 > Subject: RE: question regarding Labels in
>ANCP port up=20 messages
>         &nb= sp;     =20 >
>          &= nbsp;    =20 > Hi=20 Maglione
>         &nb= sp;     =20 >   Yes, the label format is as defined in RFC
>3292. = The=20 ANCP draft=20 is
>          &nb= sp;    =20 > based on RFC 3292 and proposes
>extensions/modifications=20 where
>          =      =20 >=20 required.
>         &n= bsp;     =20 > This is clearly stated upfront both in the
>abstract and=20 in
>          &nb= sp;    =20 > section 2.=20 In
>          &nb= sp;    =20 > section 5.4.2, it clearly  specifies the
>format of = "port up"=20 message
>         &nbs= p;     =20 > (based on RFC 3292), and explicitly states
>the label=20 field
>          =      =20 > should be=20 set
>          &n= bsp;    =20 > to 0. Following is what the draft currently=20 states:
>         &nbs= p;     =20 >
>          &= nbsp;    =20 >
>          &= nbsp;    =20 > 5.4.2 Topology Discovery=20 Extensions
>         &= nbsp;     =20 >
>          &= nbsp;    =20 > The GSMP Event message with PORT UP message
>type (80) is = used=20 for
>          &n= bsp;    =20 > conveying DSL line attributes to the NAS.
>The version field = should=20 be
>          &nb= sp;    =20 > set to 3, and the sub field should be set to
>1. The I and=20 subMessage
>         &= nbsp;     =20 > fields SHOULD be set to 1 to signify no
>fragmentation. The = Port=20 and
>          &n= bsp;    =20 > Label fields should be set to=20 0.
>          &nb= sp;    =20 >
>          &= nbsp;    =20 > =20 0            =       =20 1            =       =20 2  
>        &nbs= p;      =20 3
>          &nbs= p;    =20 >          0 1 2 3 4 5 6 = 7 8 9 0=20 1 2 3 4 5 6 7
>8 9 0 1 2 3 4=20 5
>          &nbs= p;    =20 > 6 7 8 9 0=20 1
>          &nbs= p;    =20 >
>          &= nbsp;    =20 >
>          &= nbsp;    =20 >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
>          &= nbsp;    =20 >         | Vers  = | =20 Sub  | Message Type =20 |
>Result|       =20 Code
>          &= nbsp;    =20 >=20 |
>          &nbs= p;    =20 >
>          &= nbsp;    =20 >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
>          &= nbsp;    =20 >         | Partition = ID =20 |           
&g= t;Transaction=20 Identifier
>         &= nbsp;     =20 >=20 |
>          &nbs= p;    =20 >
>          &= nbsp;    =20 >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
>          &= nbsp;    =20 >        =20 |I|      SubMessage=20 Number     =20 |   
>      =20 Length
>          = ;     =20 >=20 |
>          &nbs= p;    =20 >
>          &= nbsp;    =20 >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
>          &= nbsp;    =20 >        =20 |            =             &= nbsp;   =20 Port
>          &= nbsp;    =20 >=20 |
>          &nbs= p;    =20 >
>          &= nbsp;    =20 >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
>          &= nbsp;    =20 >        =20 |            =          =20 Port Session=20 Number
>          = ;     =20 >=20 |
>          &nbs= p;    =20 >
>          &= nbsp;    =20 >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
>          &= nbsp;    =20 >        =20 |            =         =20 Event Sequence=20 Number
>          = ;     =20 >=20 |
>          &nbs= p;    =20 >
>          &= nbsp;    =20 >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
>          &= nbsp;    =20 >        =20 |x|S|x|x|
>         &n= bsp;     =20 >=20 |
>          &nbs= p;    =20 >        =20 +-+-+-+-+          &nbs= p;         =20 Label
>          =      =20 >=20 |
>          &nbs= p;    =20 >        =20 ~
>          &nbs= p;    =20 >=20 ~
>          &nbs= p;    =20 >
>          &= nbsp;    =20 >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
>          &= nbsp;    =20 >         |x|x|x|x|x|x|x|x| = Message=20 Type  |  
>Tech Type   | Block=20 Length
>          = ;     =20 >=20 |
>          &nbs= p;    =20 >
>          &= nbsp;    =20 >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
>          &= nbsp;    =20 >        =20 |
>          &nbs= p;    =20 >=20 |
>          &nbs= p;    =20 >        =20 ~            =              = Extension=20 Value
>          =      =20 >=20 ~
>          &nbs= p;    =20 >        =20 |
>          &nbs= p;    =20 >=20 |
>          &nbs= p;    =20 >
>          &= nbsp;    =20 >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
>          &= nbsp;    =20 >
>          &= nbsp;    =20 > When we say the label field should be set to
>0, the=20 intention
>         &n= bsp;     =20 > is for=20 the
>          &n= bsp;    =20 > type and length fields in the label TLV to
>be set to 0. We=20 can
>          &n= bsp;    =20 > explicitly state this for=20 clarity.
>         &nb= sp;     =20 >
>          &= nbsp;    =20 >=20 -Sanjay
>         &nbs= p;     =20 >
>          &= nbsp;    =20 > >-----Original=20 Message-----
>         = ;      =20 > >From: Maglione Roberta
>[mailto:roberta.maglione@telecomitalia.it]
>         &= nbsp;     =20 > >Sent: Tuesday, April 29, 2008 8:06=20 AM
>          &nb= sp;    =20 > >To: Sanjay=20 Wadhwa
>          = ;     =20 > >Cc: Wojciech Dec (wdec);=20 ancp@ietf.org;
>pchamp@cisco.com
>    &nb= sp;          =20 > >Subject: RE: question regarding Labels in
>ANCP port up=20 messages
>         &nb= sp;     =20 >=20 >
>          &= nbsp;    =20 >=20 >
>          &= nbsp;    =20 > >Hi Sanjay and=20 All,
>          &= nbsp;    =20 > >     I was reading the current = ancp
>protocol=20 draft in order=20 to
>          &nb= sp;    =20 > > understand which should be the correct
>format for the=20 label
>          =      =20 > >field in the ancp port Up=20 message.
>         &nb= sp;     =20 > >Actually as it was already pointed out in
>the alias the=20 draft
>          =      =20 > >in section 5.4.2 says "GSMP Event message
>with PORT UP=20 message
>         &nbs= p;     =20 > >type (80) is used"  thus I am assuming that
>the = label in=20 the
>          &n= bsp;    =20 > >port UP message should follow the message
>format defined = in
>          &nb= sp;    =20 > >RFC 3292, section=20 3.1.3:
>          = ;     =20 >=20 >
>          &= nbsp;    =20 > >   =20 0            =       =20 1            =       
>2    &nbs= p;            = ; =20 3
>          &nbs= p;    =20 > >    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 = 9
>0 1 2=20 3 4 5 6 7 8 9 0=20 1
>          &nbs= p;    =20 >=20 >  
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+
>        &= nbsp;      =20 > >   |x|S|x|x|       = Label=20 Type     =20 |       
>  Label=20 Length        =20 |
>          &nbs= p;    =20 >=20 >  
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+
>        &= nbsp;      =20 > >  =20 |            =             &= nbsp;           &n= bsp;  
>        &= nbsp;           &n= bsp; =20 |
>          &nbs= p;    =20 > >  =20 ~            =             &= nbsp;=20 Label=20 Value  
>        =             &= nbsp; =20 ~
>          &nbs= p;    =20 > >  =20 |            =             &= nbsp;           &n= bsp;  
>        &= nbsp;           &n= bsp; =20 |
>          &nbs= p;    =20 >=20 >  
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+
>        &= nbsp;      =20 >=20 >
>          &= nbsp;    =20 > >but from what I have seen different
>implementations=20 use
>          &n= bsp;    =20 > >different format for label field: in
>particular=20 several
>         &nbs= p;     =20 > >implementations use  a label format that is
>similar = to the=20 one
>          &n= bsp;    =20 > >specified in the expired=20 draft
>draft-ietf-gsmp-v3-base-spec:
>    = ;           =20 >=20 >
>          &= nbsp;    =20 > >    =20 0            =       =20 1            =      
>=20 2            =       =20 3
>          &nbs= p;    =20 > >       0 1 2 3 4 5 6 7 8 9 0 1 2 = 3 4 5 6=20 7
>8 9 0 1 2 3 4 5=20 6
>          &nbs= p;    =20 > 7 8 9 0=20 1
>          &nbs= p;    =20 >=20 >
>          &= nbsp;    =20 >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
>          &= nbsp;    =20 > >     =20 |x|S|x|x|x|x|x|x|x|x|x|x|x|x|x|x|    
> &n= bsp;    =20 Label
>          =      =20 > Type        =20 |
>          &nbs= p;    =20 >=20 >
>          &= nbsp;    =20 >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
>          &= nbsp;    =20 > >      |    Label=20 Adaptation          =20 |    
>    =20 Label
>          =      =20 > Length        =20 |
>          &nbs= p;    =20 >=20 >
>          &= nbsp;    =20 >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
>          &= nbsp;    =20 > >     =20 |
>          &nbs= p;    =20 >         =20 |
>          &nbs= p;    =20 > >     =20 ~            =             &= nbsp;=20 Label=20 Value
>          =      =20 >         =20 ~
>          &nbs= p;    =20 > >     =20 |
>          &nbs= p;    =20 >         =20 |
>          &nbs= p;    =20 >=20 >
>          &= nbsp;    =20 >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
>          &= nbsp;    =20 >=20 >
>          &= nbsp;    =20 >=20 >
>          &= nbsp;    =20 > >Even if ancp does not care about the label
>field, having = this
>          &= nbsp;    =20 > >field somehow not clearly specified in the
>current ancp=20 draft
>          =      =20 > >can easily lead to interoperability issues,
>thus I think = it
>          &nb= sp;    =20 > >would be very helpful if you and/or the
>other editors=20 can
>          &n= bsp;    =20 > >clarify what should be the correct format
>for the label=20 field
>          =      =20 > >to be used in the ancp Port Up=20 message.
>         &nb= sp;     =20 >=20 >
>          &= nbsp;    =20 > >Thanks and best=20 regards,
>         &nb= sp;     =20 >=20 >Roberta
>         =       =20 >=20 >
>          &= nbsp;    =20 >=20 >________________________________________
>   &nb= sp;           =20 > >From: Philippe Champagne (pchamp)=20 [pchamp@cisco.com]
>        = ;       =20 > >Sent: Thursday, April 24, 2008 7:14=20 PM
>          &nb= sp;    =20 > >To: Sanjay=20 Wadhwa
>          = ;     =20 > >Cc: Maglione Roberta; Wojciech Dec=20 (wdec);
>ancp@ietf.org
>      &= nbsp;        =20 > >Subject: question regarding  Labels in ANCP
>port up = messages
>         &nb= sp;     =20 >=20 >
>          &= nbsp;    =20 > >Hi=20 Sanjay
>          = ;     =20 >=20 >
>          &= nbsp;    =20 > >In section 5.4.2 of the draft, we=20 have:
>          =      =20 >=20 >
>          &= nbsp;    =20 >=20 >
>          &= nbsp;    =20 > >        =20 0            =       =20 1            =       =20 2
>          &nbs= p;    =20 >        =20 3
>          &nbs= p;    =20 > >         0 1 2 3 4 5 6 = 7 8 9 0=20 1 2 3 4 5 6
>7 8 9 0 1 2 3 4 5=20 6
>          &nbs= p;    =20 > >7 8 9 0=20 1
>          &nbs= p;    =20 >=20 >
>          &= nbsp;    =20 >
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>         &nb= sp;     =20 > >        | Vers  |  = Sub  | Message Type =20 |
>Result|       =20 Code
>          &= nbsp;    =20 > >        =20 |
>          &nbs= p;    =20 >=20 >
>          &= nbsp;    =20 >
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>         &nb= sp;     =20 > >        | Partition ID  = |           
&g= t;Transaction=20 Identifier
>         &= nbsp;     =20 > >        =20 |
>          &nbs= p;    =20 >=20 >
>          &= nbsp;    =20 >
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>         &nb= sp;     =20 > >       =20 |I|      SubMessage=20 Number     =20 |  
>       =20 Length
>          = ;     =20 > >        =20 |
>          &nbs= p;    =20 >=20 >
>          &= nbsp;    =20 >
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>         &nb= sp;     =20 > >       =20 |            =             &= nbsp;   =20 Port
>          &= nbsp;    =20 > >        =20 |
>          &nbs= p;    =20 >=20 >
>          &= nbsp;    =20 >
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>         &nb= sp;     =20 > >       =20 |            =          =20 Port Session=20 Number
>          = ;     =20 > >        =20 |
>          &nbs= p;    =20 >=20 >
>          &= nbsp;    =20 >
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>         &nb= sp;     =20 > >       =20 |            =         =20 Event Sequence=20 Number
>          = ;     =20 > >        =20 |
>          &nbs= p;    =20 >=20 >
>          &= nbsp;    =20 >
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>         &nb= sp;     =20 > >       =20 |x|S|x|x|
>         &n= bsp;     =20 > >        =20 |
>          &nbs= p;    =20 > >       =20 +-+-+-+-+          &nbs= p;         =20 Label
>          =      =20 > >        =20 |
>          &nbs= p;    =20 > >       =20 ~
>          &nbs= p;    =20 > >        =20 ~
>          &nbs= p;    =20 >=20 >
>          &= nbsp;    =20 >
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>         &nb= sp;     =20 > >        |x|x|x|x|x|x|x|x| = Message=20 Type  |  
>Tech Type  =20 |
>          &nbs= p;    =20 > >Block Length =20 |
>          &nbs= p;    =20 >=20 >
>          &= nbsp;    =20 >
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>         &nb= sp;     =20 > >       =20 |
>          &nbs= p;    =20 > >        =20 |
>          &nbs= p;    =20 > >       =20 ~            =              = Extension=20 Value
>          =      =20 > >        =20 ~
>          &nbs= p;    =20 > >       =20 |
>          &nbs= p;    =20 > >        =20 |
>          &nbs= p;    =20 >=20 >
>          &= nbsp;    =20 >
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>         &nb= sp;     =20 > >Where Label I suppose is taken from the RFC
>3292,=20 section
>         &nbs= p;     =20 > >3.1.3: (well, I'm=20 guessing)
>         &n= bsp;     =20 >=20 >
>          &= nbsp;    =20 > >   A summary of TLV labels supported in
>this = version=20 of=20 the
>          &n= bsp;    =20 > protocol=20 is
>          &nb= sp;    =20 > >   listed=20 below:
>          = ;     =20 >=20 >
>          &= nbsp;    =20 > >      TLV = Label     =20 Type       Section=20 Title
>          =      =20 > >      = ---------     =20 ----      =20 -------------
>        &nbs= p;      =20 > >      ATM = Label     =20 0x100      ATM TLV=20 Labels
>          = ;     =20 > >      FR=20 Label       = 0x101     =20 Frame Relay
>TLV=20 Labels
>          = ;     =20 > >      MPLS Gen Label=20 0x102      MPLS
>Generic TLV=20 Labels
>          = ;     =20 > >      FEC = Label     =20 0x103      FEC TLV=20 Labels
>          = ;     =20 >=20 >
>          &= nbsp;    =20 > >   All Labels will be designated as=20 follow:
>         &nbs= p;     =20 >=20 >
>          &= nbsp;    =20 > >   =20 0            =       =20 1            =       
>2    &nbs= p;            = ; =20 3
>          &nbs= p;    =20 > >    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 = 9
>0 1 2=20 3 4 5 6 7 8 9 0=20 1
>          &nbs= p;    =20 >=20 >  
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+
>        &= nbsp;      =20 > >   |x|S|x|x|       = Label=20 Type     =20 |       
>  Label=20 Length        =20 |
>          &nbs= p;    =20 >=20 >  
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+
>        &= nbsp;      =20 > >  =20 |            =             &= nbsp;           &n= bsp;  
>        &= nbsp;           &n= bsp; =20 |
>          &nbs= p;    =20 > >  =20 ~            =             &= nbsp;=20 Label=20 Value  
>        =             &= nbsp; =20 ~
>          &nbs= p;    =20 > >  =20 |            =             &= nbsp;           &n= bsp;  
>        &= nbsp;           &n= bsp; =20 |
>          &nbs= p;    =20 >=20 >  
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+
>        &= nbsp;      =20 >=20 >
>          &= nbsp;    =20 > >      x: Reserved=20 Flags.
>          = ;     =20 > >         These are = generally=20 used by
>specific messages and will=20 be
>          &nb= sp;    =20 > >         defined in = those=20 messages.
>         &n= bsp;     =20 >=20 >
>          &= nbsp;    =20 > >      S: Stacked Label=20 Indicator
>         &n= bsp;     =20 > >         Label Stacking = is=20 discussed below
>in section=20 3.1.3.5
>         &nbs= p;     =20 >=20 >
>          &= nbsp;    =20 > >      Label=20 Type
>          &= nbsp;    =20 > >         A 12-bit field = indicating the type
>of=20 label.
>          = ;     =20 >=20 >
>          &= nbsp;    =20 > >      Label=20 Length
>          = ;     =20 > >         A 16-bit field = indicating the
>length of the=20 Label
>          =      =20 > Value=20 field
>          =      =20 > >         in=20 bytes.
>          = ;     =20 >=20 >
>          &= nbsp;    =20 > >      Label=20 Value
>          =      =20 > >         A variable = length=20 field that is an
>integer number of 32=20 bit
>          &n= bsp;    =20 > >         words = long.  The=20 Label Value field
>is=20 interpreted
>         =       =20 > according=20 to
>          &nb= sp;    =20 > >         the Label Type = as=20 described in the
>following=20 sections.
>         &n= bsp;     =20 >=20 >
>          &= nbsp;    =20 >=20 >
>          &= nbsp;    =20 > >The draft is a bit obscure about this and
>since it=20 doesn't
>         &nbs= p;     =20 > >specify much, it can lead to
>misinterpretation for the=20 unused
>          = ;     =20 > >part. Moreover, it would appear that
>several=20 implementations
>        &n= bsp;      =20 > >currently use another format for the label
>field. Can=20 you
>          &n= bsp;    =20 > >explain?  I mean, how come what's in the
>current = draft=20 doesn't
>         &nbs= p;     =20 > >match what's known to be=20 implemented?
>         = ;      =20 >=20 >
>          &= nbsp;    =20 > >I'm still wondering why we carried over
>pieces from GSMP = that
>          &= nbsp;    =20 > >we do not intend to=20 use.
>          &= nbsp;    =20 >=20 >
>          &= nbsp;    =20 > >I would recommend that if we are to keep
>them but not=20 use
>          &n= bsp;    =20 > >them, we should mention precisely how we
>intend not to=20 use
>          &n= bsp;    =20 > >them: that is how many 0 filled bytes this
>is expected = to=20 use
>          &n= bsp;    =20 >=20 >
>          &= nbsp;    =20 > >The rfc 3292 doesn't cover the case where
>this field is = not=20 used.
>          =      =20 >=20 >
>          &= nbsp;    =20 > >Can you shed some ligths on=20 this?
>          =      =20 >=20 >
>          &= nbsp;    =20 >=20 >Thanks
>         &= nbsp;     =20 >=20 >Regards
>         =       =20 >=20 >Phil
>         &nb= sp;     =20 >=20 >
>          &= nbsp;    =20 >=20 >
>          &= nbsp;    =20 >=20 >
>          &= nbsp;    =20 >
>>---------------------------------------------------------= -----------
>         =       =20 >=20 >
>          &= nbsp;    =20 > >CONFIDENTIALITY=20 NOTICE
>          = ;     =20 >=20 >
>          &= nbsp;    =20 > >This message and its attachments are
>addressed solely to = the
>          &n= bsp;    =20 > >persons above and may contain confidential
>information. = If=20 you
>          &n= bsp;    =20 > >have received the message in error, be
>informed that any = use
>          &n= bsp;    =20 > >of the content hereof is prohibited. Please
>return=20 it
>          &nb= sp;    =20 > >immediately to the sender and delete the
>message. Should = you
>          &n= bsp;    =20 > >have any questions, please contact us by replying=20 to
>          &nb= sp;    =20 >=20 >webmaster@telecomitalia.it.
>     &nbs= p;         =20 >=20 >
>          &= nbsp;    =20 > >        Thank=20 you
>          &n= bsp;    =20 >=20 >
>          &= nbsp;    =20 >=20 >           &nb= sp;           &nbs= p;            = ;   
>www.telecomitalia.it
>   =              = >=20 >
>          &= nbsp;    =20 >
>>---------------------------------------------------------= -----------
>         =       =20 >=20 >
>          &= nbsp;    =20 >=20 >
>          &= nbsp;    =20 >
>          &= nbsp;    =20 _______________________________________________
>   =              = ANCP mailing=20 list
>          &= nbsp;    =20 ANCP@ietf.org
>        &nbs= p;      =20 https://www.ietf.org/mailman/listinfo/ancp
>
>

------_=_NextPart_001_01C8AB0B.06341E6F-- --===============0766194272== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============0766194272==-- From ancp-bounces@ietf.org Wed Apr 30 16:20:17 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8661B28C319; Wed, 30 Apr 2008 16:20:17 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6ABE3A677D for ; Wed, 30 Apr 2008 16:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvgIMSUkXXX4 for ; Wed, 30 Apr 2008 16:20:08 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 2BFA828C368 for ; Wed, 30 Apr 2008 16:20:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 8C63C938B60; Wed, 30 Apr 2008 16:20:10 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04747-01; Wed, 30 Apr 2008 16:20:09 -0700 (PDT) Received: from rbsjx.ad.redback.com (rbsjxh2.redback.com [155.53.14.106]) by prattle.redback.com (Postfix) with ESMTP id 6476F65E99F; Wed, 30 Apr 2008 16:20:05 -0700 (PDT) Received: from RBSJX.ad.redback.com ([155.53.14.103]) by rbsjxh2.ad.redback.com ([155.53.14.106]) with mapi; Wed, 30 Apr 2008 16:20:05 -0700 From: Peter Arberg To: Sanjay Wadhwa , Tina TSOU , Maglione Roberta , "Wojciech Dec (wdec)" Date: Wed, 30 Apr 2008 16:20:02 -0700 Thread-Topic: [ANCP] question regarding Labels in ANCP port up messages Thread-Index: Aciqkn5nSPBPuwuySsamcvxF1uU6kQAZ9dQQAAE415AABe3TAA== Message-ID: <48C276B536524E478C659685995F6AA539DBBBE577@RBSJX.ad.redback.com> References: <48C276B536524E478C659685995F6AA539DBBBE370@RBSJX.ad.redback.com> <9BD5D7887235424FA97DFC223CAE3C280AB43A10@proton.jnpr.net> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C280AB43A10@proton.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_48C276B536524E478C659685995F6AA539DBBBE577RBSJXadredbac_" MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at redback.com Cc: "ancp@ietf.org" Subject: Re: [ANCP] question regarding Labels in ANCP port up messages X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org --_004_48C276B536524E478C659685995F6AA539DBBBE577RBSJXadredbac_ Content-Type: multipart/alternative; boundary="_000_48C276B536524E478C659685995F6AA539DBBBE577RBSJXadredbac_" --_000_48C276B536524E478C659685995F6AA539DBBBE577RBSJXadredbac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sanjay, What do you mean "why I reference an old draft" ???????????? I'm surprised you even ask... please take a look at YOUR own internet-draf= t that most of the ANCP working implementations are based on, in case you do not have t= his old internet-draft, I have attached it to the document. If you look at the reference for this ancp-draft, you will see that in the = reference section you point to this old gsmp-draft... Yes and I know this has been changed i= n the later versions of the ANCP draft, but that do not change the fact that many of th= e implementations today was developed when the attached draft was current. I think a very good question is brought up here, and that is what is implem= ented and running in networks today ? My take on this is that when the reference was change from the old gsmp-dra= ft to the older RFC3292, apparently no one paid any attention to the fact the label definit= ion in the event message was different and not compatible. What current implementations do today is an important factor in this discus= sion, and I think it is time to come to realization that we might need a new version number f= or ANCP since it continues to look like there is big holes open for interpretation. So if= I did a ANCP implementation there is bound to be interoperability issues with existing i= mplementations runnig. cheers, Peter ________________________________ From: Sanjay Wadhwa [mailto:swadhwa@juniper.net] Sent: 30. april 2008 14:42 To: Peter Arberg; Tina TSOU; Maglione Roberta; Wojciech Dec (wdec) Cc: ancp@ietf.org Subject: RE: [ANCP] question regarding Labels in ANCP port up messages Peter The ANCP draft as it currently stands is based on RFC3292. It provides ex= tensions and modifications to relevant constructs in RFC3292. There is no m= ention (implicit or explicit) of expired GSMP drafts in the ANCP draft. In = order to implement the ANCP draft, I am not sure why one would look at the = expired GSMP drafts. Do you see a reason to do this based on anything that = you read in the ANCP draft? Bringing up reference to expired gsmp draft in = this thread just adds to the confusion. For GSMPv3 objects in the messages = (such as Label Type), one has to look at RFC3292 (this is clearly stated in= the ANCP draft - section 2 and I am quoting it below) : ANCP uses a subset of GSMPv3 messages to implement currently defined use-ca= ses. These relevant GSMPv3 messages are identified in section 5. GSMPv3 pro= cedures with suitable extensions, as used by ANCP, are described in section= s 5.1, 5.2 and 5.3. GSMPv3 general extensions and GSMPv3 message specific e= xtensions required by ANCP are described in sub-sections of 5.4. In additio= n to specifying extensions and modifications to relevant GSMP messages appl= icable to ANCP, this draft also defines the usage of these messages by ANCP= , and indicates the values that ANCP should set for relevant fields in thes= e GSMP messages. However, to understand the basic semantics of various fiel= ds in GSMP messages, the reader is referred to [4]. =3D> RFC 3292. What existing implementations currently do is an important but separate iss= ue. These implementations for most part precede the current ANCP draft. It = is fine to poll where these implementations diverge from the current draft.= It is then upto the implementations (including the one that I am somewhat = familiar with) to work towards compliance with the draft. On the following points from Woj: Woj>2) The current version of the spec is not accurate, and does not reflec= t the fact that the known implementations follow the label field definition= from draft-gsmpv3-base-spec. It is not for the protocol draft to point out what current implementations = do. The best we can do is to further clarify in the draft that type and va= lue fields of the Label object (defined in RFC3292) should be set to 0 in t= he port-up message (we already mention the lable object as a whole should b= e set to all 0s). Woj> This would be a good thing for the WG to discuss. There most evidently= is a fair amount of "dead wood" in the current spec, ie stuff that nobody = yet implements or cares about. In the former case, we could re-cast that m= aterial using the new notions/extensions, in the latter case simply chop it= out. I agree. We are based on GSMPv3 (RFC3292) messages, and obviously not ever= ything in these messages is leveraged by ANCP. However, the sync rate and = OAM uses-cases are implemented and in use (ideally we should leave these al= one...i.e. no change beyond adding more clarity if needed). For anything ne= w (such as multicast) we are defining new messages (no legacy). -Sanjay >-----Original Message----- >From: Peter Arberg [mailto:parberg@redback.com] >Sent: Wednesday, April 30, 2008 3:56 PM >To: Tina TSOU; Maglione Roberta; Sanjay Wadhwa; Wojciech Dec (wdec) >Cc: ancp@ietf.org >Subject: RE: [ANCP] question regarding Labels in ANCP port up messages > > >Hi, > >some times I think it is amazing we ever got interoperability >of ANCP :-) >because looking at the label discussion is a very good example that the >whole GSMP - ANCP reference have not worked very well. > >In the ANCP draft, section 5.4.2 the event message is shown like this: > >0 1 2 3 >0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Vers | Sub | Message Type | Result| Code | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Partition ID | Transaction Identifier | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >|I| SubMessage Number | Length | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Port | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Port Session Number | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Event Sequence Number | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >|x|S|x|x| | >+-+-+-+-+ Label | >~ ~ >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >|x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| | >~ Extension Value ~ >| | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >This is the exact same event message defined in >draft-ietf-gsmp-v3-base-spec-08.txt section 11. > >And in this gsmp-draft, section 5.1.3 the label space is defined >as minimum 8 bytes if the length=3D0 and as such no value, and this >is because the gsmp-draft has a new "label adaptaion" field. > > > >BUT in RFC3292 the event message is show in section 9, like this: > >0 1 2 3 >0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Version | Message Type | Result | Code | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Partition ID | Transaction Identifier | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >|I| SubMessage Number | Length | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Port | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Port Session Number | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Event Sequence Number | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >|x|S|x|x| | >+-+-+-+-+ Label | >~ ~ >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >So a different Event Message picture/definition than what is shown >in the ANCP draft, and in RFC3292 section 3.1.3 the label field >is defined as 4 bytes if length=3D0 and as such no value. > > > >So I very much agree with Woj that we need this issue to be resolved, >and proabably a show of hands what is actually done in different >implementations, so we can nail down how the event message is >suppose to look like in ANCP. > > >I know at least 1 implementation which uses 8 bytes for the >label field. > > >cheers, >Peter > > > > > > >________________________________ > > From: ancp-bounces@ietf.org >[mailto:ancp-bounces@ietf.org] On Behalf Of Tina TSOU > Sent: 30. april 2008 00:19 > To: Maglione Roberta; Sanjay Wadhwa; Wojciech Dec (wdec) > Cc: ancp@ietf.org > Subject: Re: [ANCP] question regarding Labels in ANCP >port up messages > > > Hi all, > It is clear to me that if Label Length is filled as 0, >there is nothing to be filled into Label Value. The whole >Label part is 4 bytes, not 8 bytes. > > Cheers from the last working day before Labor's Day >holidays in some countries:) > > Tina > > ----- Original Message ----- > From: Wojciech Dec (wdec) > To: Sanjay Wadhwa > ; Maglione Roberta > Cc: ancp@ietf.org > Sent: Wednesday, April 30, 2008 1:12 AM > Subject: Re: [ANCP] question regarding Labels >in ANCP port up messages > > Sanjay, All, > > What is stated below runs counter to at least >a handful of ANCP > implementations, all of which are known to be >interoperable. > There are really two options: > 1) The current version of the spec is correct, >and the known > interoperable implementations do not follow it > 2) The current version of the spec is not >accurate, and does not reflect > the fact that the known implementations follow >the label field > definition from draft-gsmpv3-base-spec. > > I would like to ask you, as the lead editor of >the spec, to work with > the WG in resolving what the problem is, and >clearing up what the WG > spec says about and if 1) holds to be true, >then proposing an > interoperability fix. > > In either case, the issue highlights the fact >that there is still > lingering confusion as to the dependencies >ANCP has on rfc3292, or > draft-gsmpv3-base-spec, or both. It seems to >be in the best interest of > all to address these. > > Regards, > Woj. > > > -----Original Message----- > > From: Sanjay Wadhwa [mailto:swadhwa@juniper.net] > > Sent: 29 April 2008 17:29 > > To: Maglione Roberta > > Cc: Wojciech Dec (wdec); ancp@ietf.org; >Philippe Champagne (pchamp) > > Subject: RE: question regarding Labels in >ANCP port up messages > > > > Hi Maglione > > Yes, the label format is as defined in RFC >3292. The ANCP draft is > > based on RFC 3292 and proposes >extensions/modifications where > > required. > > This is clearly stated upfront both in the >abstract and in > > section 2. In > > section 5.4.2, it clearly specifies the >format of "port up" message > > (based on RFC 3292), and explicitly states >the label field > > should be set > > to 0. Following is what the draft currently states: > > > > > > 5.4.2 Topology Discovery Extensions > > > > The GSMP Event message with PORT UP message >type (80) is used for > > conveying DSL line attributes to the NAS. >The version field should be > > set to 3, and the sub field should be set to >1. The I and subMessage > > fields SHOULD be set to 1 to signify no >fragmentation. The Port and > > Label fields should be set to 0. > > > > 0 1 2 > 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 >8 9 0 1 2 3 4 5 > > 6 7 8 9 0 1 > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Vers | Sub | Message Type | >Result| Code > > | > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Partition ID | >Transaction Identifier > > | > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |I| SubMessage Number | > Length > > | > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Port > > | > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Port Session Number > > | > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Event Sequence Number > > | > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |x|S|x|x| > > | > > +-+-+-+-+ Label > > | > > ~ > > ~ > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |x|x|x|x|x|x|x|x| Message Type | >Tech Type | Block Length > > | > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | > > | > > ~ Extension Value > > ~ > > | > > | > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > When we say the label field should be set to >0, the intention > > is for the > > type and length fields in the label TLV to >be set to 0. We can > > explicitly state this for clarity. > > > > -Sanjay > > > > >-----Original Message----- > > >From: Maglione Roberta >[mailto:roberta.maglione@telecomitalia.it] > > >Sent: Tuesday, April 29, 2008 8:06 AM > > >To: Sanjay Wadhwa > > >Cc: Wojciech Dec (wdec); ancp@ietf.org; >pchamp@cisco.com > > >Subject: RE: question regarding Labels in >ANCP port up messages > > > > > > > > >Hi Sanjay and All, > > > I was reading the current ancp >protocol draft in order to > > > understand which should be the correct >format for the label > > >field in the ancp port Up message. > > >Actually as it was already pointed out in >the alias the draft > > >in section 5.4.2 says "GSMP Event message >with PORT UP message > > >type (80) is used" thus I am assuming that >the label in the > > >port UP message should follow the message >format defined in > > >RFC 3292, section 3.1.3: > > > > > > 0 1 >2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 >0 1 2 3 4 5 6 7 8 9 0 1 > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |x|S|x|x| Label Type | > Label Length | > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | > | > > > ~ Label Value > ~ > > > | > | > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > >but from what I have seen different >implementations use > > >different format for label field: in >particular several > > >implementations use a label format that is >similar to the one > > >specified in the expired draft >draft-ietf-gsmp-v3-base-spec: > > > > > > 0 1 > 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 >8 9 0 1 2 3 4 5 6 > > 7 8 9 0 1 > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |x|S|x|x|x|x|x|x|x|x|x|x|x|x|x|x| > Label > > Type | > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Label Adaptation | > Label > > Length | > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | > > | > > > ~ Label Value > > ~ > > > | > > | > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > >Even if ancp does not care about the label >field, having this > > >field somehow not clearly specified in the >current ancp draft > > >can easily lead to interoperability issues, >thus I think it > > >would be very helpful if you and/or the >other editors can > > >clarify what should be the correct format >for the label field > > >to be used in the ancp Port Up message. > > > > > >Thanks and best regards, > > >Roberta > > > > > >________________________________________ > > >From: Philippe Champagne (pchamp) [pchamp@cisco.com] > > >Sent: Thursday, April 24, 2008 7:14 PM > > >To: Sanjay Wadhwa > > >Cc: Maglione Roberta; Wojciech Dec (wdec); >ancp@ietf.org > > >Subject: question regarding Labels in ANCP >port up messages > > > > > >Hi Sanjay > > > > > >In section 5.4.2 of the draft, we have: > > > > > > > > > 0 1 2 > > 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 >7 8 9 0 1 2 3 4 5 6 > > >7 8 9 0 1 > > > > > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Vers | Sub | Message Type | >Result| Code > > > | > > > > > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Partition ID | >Transaction Identifier > > > | > > > > > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |I| SubMessage Number | > Length > > > | > > > > > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Port > > > | > > > > > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Port Session Number > > > | > > > > > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Event Sequence Number > > > | > > > > > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |x|S|x|x| > > > | > > > +-+-+-+-+ Label > > > | > > > ~ > > > ~ > > > > > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |x|x|x|x|x|x|x|x| Message Type | >Tech Type | > > >Block Length | > > > > > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | > > > | > > > ~ Extension Value > > > ~ > > > | > > > | > > > > > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >Where Label I suppose is taken from the RFC >3292, section > > >3.1.3: (well, I'm guessing) > > > > > > A summary of TLV labels supported in >this version of the > > protocol is > > > listed below: > > > > > > TLV Label Type Section Title > > > --------- ---- ------------- > > > ATM Label 0x100 ATM TLV Labels > > > FR Label 0x101 Frame Relay >TLV Labels > > > MPLS Gen Label 0x102 MPLS >Generic TLV Labels > > > FEC Label 0x103 FEC TLV Labels > > > > > > All Labels will be designated as follow: > > > > > > 0 1 >2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 >0 1 2 3 4 5 6 7 8 9 0 1 > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |x|S|x|x| Label Type | > Label Length | > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | > | > > > ~ Label Value > ~ > > > | > | > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > x: Reserved Flags. > > > These are generally used by >specific messages and will be > > > defined in those messages. > > > > > > S: Stacked Label Indicator > > > Label Stacking is discussed below >in section 3.1.3.5 > > > > > > Label Type > > > A 12-bit field indicating the type >of label. > > > > > > Label Length > > > A 16-bit field indicating the >length of the Label > > Value field > > > in bytes. > > > > > > Label Value > > > A variable length field that is an >integer number of 32 bit > > > words long. The Label Value field >is interpreted > > according to > > > the Label Type as described in the >following sections. > > > > > > > > >The draft is a bit obscure about this and >since it doesn't > > >specify much, it can lead to >misinterpretation for the unused > > >part. Moreover, it would appear that >several implementations > > >currently use another format for the label >field. Can you > > >explain? I mean, how come what's in the >current draft doesn't > > >match what's known to be implemented? > > > > > >I'm still wondering why we carried over >pieces from GSMP that > > >we do not intend to use. > > > > > >I would recommend that if we are to keep >them but not use > > >them, we should mention precisely how we >intend not to use > > >them: that is how many 0 filled bytes this >is expected to use > > > > > >The rfc 3292 doesn't cover the case where >this field is not used. > > > > > >Can you shed some ligths on this? > > > > > >Thanks > > >Regards > > >Phil > > > > > > > > > > > >>-------------------------------------------------------------------- > > > > > >CONFIDENTIALITY NOTICE > > > > > >This message and its attachments are >addressed solely to the > > >persons above and may contain confidential >information. If you > > >have received the message in error, be >informed that any use > > >of the content hereof is prohibited. Please >return it > > >immediately to the sender and delete the >message. Should you > > >have any questions, please contact us by replying to > > >webmaster@telecomitalia.it. > > > > > > Thank you > > > > > > >www.telecomitalia.it > > > > > >>-------------------------------------------------------------------- > > > > > > > > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp > > --_000_48C276B536524E478C659685995F6AA539DBBBE577RBSJXadredbac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Sanjay,
 
What do you mean "why I reference an old draft"&nb= sp;=20 ????????????
 
I'm surprised you even ask...  please take a = look at=20 YOUR own internet-draft that most
of the ANCP working implementations are based on, = in case=20 you do not have this old
internet-draft, I have attached it to the=20 document.
 
If you look at the reference for this ancp-draft, = you will=20 see that in the reference section
you point to this old gsmp-draft...  Yes and = I know=20 this has been changed in the later
versions of the ANCP draft, but that do not change= the fact=20 that many of the implementations
today was developed when the attached draft was=20 current.
 
I think a very good question is brought up here, a= nd that=20 is what is implemented and
running in networks today ?
 
My take on this is that when the reference was cha= nge from=20 the old gsmp-draft to the older
RFC3292, apparently no one paid any attention to t= he fact=20 the label definition in the event
message was different and not=20 compatible.
 
What current implementations do today is an import= ant=20 factor in this discussion, and I think
it is time to come to realization that we might ne= ed a new=20 version number for ANCP since
it continues to look like there is big holes open = for=20 interpretation. So if I did a ANCP
implementation there is bound to be interoperabili= ty issues=20 with existing implementations
runnig.
 
cheers,
Peter
 
 
 

From: Sanjay Wadhwa=20 [mailto:swadhwa@juniper.net]
Sent: 30. april 2008=20 14:42
To: Peter Arberg; Tina TSOU; Maglione Roberta; Wojciech D= ec=20 (wdec)
Cc: ancp@ietf.org
Subject: RE: [ANCP] question= =20 regarding Labels in ANCP port up messages

Peter
  The ANCP draft as it currently stands i= s based=20 on RFC3292. It provides extensions and modifications to relevant construc= ts in=20 RFC3292. There is no mention (implicit or explicit) of expired GSMP draft= s in=20 the ANCP draft. In order to implement the ANCP draft, I am not sure why o= ne=20 would look at the expired GSMP drafts. Do you see a reason to do this bas= ed on=20 anything that you read in the ANCP draft? Bringing up reference to expire= d=20 gsmp draft in this thread just adds to the confusion. For GSMPv3 obj= ects=20 in the messages (such as Label Type), one has to look at RFC3292 (this is= =20 clearly stated in the ANCP draft - section 2 and I am quoting it below)=20 :

ANCP uses a subset of GSMPv3 mess= ages to=20 implement currently defined use-cases. These relevant GSMPv3 messages are= =20 identified in section 5. GSMPv3 procedures with suitable extensions, as u= sed=20 by ANCP, are described in sections 5.1, 5.2 and 5.3. GSMPv3 general exten= sions=20 and GSMPv3 message specific extensions required by ANCP are described in= =20 sub-sections of 5.4. In addition to specifying extensions and modificatio= ns to=20 relevant GSMP messages applicable to ANCP, this draft also defines the us= age=20 of these messages by ANCP, and indicates the values that ANCP should set = for=20 relevant fields in these GSMP messages. However, to understand the basic= =20 semantics of various fields in GSMP messages, the reader is referred to=20 [4]. =3D> RFC 3292.

What existing implementations=20 currently do is an important but separate issue. These implementations fo= r=20 most part precede the current ANCP draft. It is fine to poll where these= =20 implementations diverge from the current draft. It is then upto the=20 implementations (including the one that I am somewhat familiar with) to w= ork=20 towards compliance with the draft.

On the following points from  Woj:

Woj>2) The current version of the spec is not accura= te, and=20 does not reflect the fact that the known implementations follow the = label=20 field definition from draft-gsmpv3-base-spec.

It is not for the protocol draft to point out what curr= ent=20 implementations do.  The best we can do is to further clarify i= n the=20 draft that type and value fields of the Label object (defined in RFC3292)= =20 should be set to 0 in the port-up message (we already mention the la= ble=20 object as a whole should be set to all 0s).

Woj> This would be a good thing for the WG = to=20 discuss. There most evidently is a fair amount of "dead wood" in the= =20 current spec, ie stuff that nobody yet implements or cares about.=20  In the former case, we could re-cast that material using the new=20 notions/extensions, in the latter case simply chop it=20 out.

I agree. We are based on GSMPv3 (RFC3292)=20  messages, and obviously not everything in these messages is leverag= ed by=20 ANCP.  However, the sync rate and OAM uses-cases are implemented and= in=20 use (ideally we should leave these alone...i.e. no change beyond adding m= ore=20 clarity if needed). For anything new (such as multicast) we are defining = new=20 messages (no legacy). 

-Sanjay

>-----Original Message-----
>Fr= om:=20 Peter Arberg [mailto:parberg@redback.com]
>Sen= t:=20 Wednesday, April 30, 2008 3:56 PM
>To: Tina TSOU; Maglione Roberta;= =20 Sanjay Wadhwa; Wojciech Dec (wdec)
>Cc: ancp@ietf.org
>Subjec= t:=20 RE: [ANCP] question regarding Labels in ANCP port up=20 messages
>
>
>Hi,
>
>some times I think it = is=20 amazing we ever got interoperability
>of ANCP :-)
>because lo= oking=20 at the label discussion is a very good example that the
>whole GSMP= -=20 ANCP reference have not worked very well.
>
>In the ANCP draf= t,=20 section 5.4.2 the event message is shown like=20 this:
>
>0        &nb= sp;         =20 1            =       =20 2            =       =20 3
>0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0=20 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|=20 Vers  |  Sub  | Message Type  |=20 Result|       =20 Code          =20 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|=20 Partition ID =20 |           =20 Transaction=20 Identifier          &nb= sp; =20 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|I|     =20 SubMessage Number     =20 |          =20 Length           &= nbsp; =20 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|           = ;            &n= bsp;    =20 Port           &nb= sp;            =      =20 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|           = ;          =20 Port Session=20 Number           &= nbsp;         =20 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|           = ;         =20 Event Sequence=20 Number           &= nbsp;        =20 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|x|S|x|x|         &nb= sp;            =             &nb= sp;            =        =20 |
>+-+-+-+-+         &= nbsp;          =20 Label           &n= bsp;            = ;    =20 |
>~          &nb= sp;            =             &nb= sp;            =             &nb= sp; =20 ~
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|x|x|x|x|x|x|x|x|=20 Message Type  |   Tech Type   | Block Length&nbs= p;=20 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|           = ;            &n= bsp;            = ;            &n= bsp;            = ; =20 |
>~          &nb= sp;            =  =20 Extension=20 Value           &n= bsp;          =20 ~
>|          &nb= sp;            =             &nb= sp;            =             &nb= sp; =20 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>
>
>This=20 is the exact same event message defined=20 in
>draft-ietf-gsmp-v3-base-spec-08.txt  section=20 11.
>
>And in this gsmp-draft, section 5.1.3 the label space = is=20 defined
>as minimum 8 bytes if the length=3D0 and as such no value,= and=20 this
>is because the gsmp-draft has a new "label adaptaion"=20 field.
>
>
>
>BUT in RFC3292 the event message is= show=20 in section 9, like=20 this:
>
>0        &nb= sp;         =20 1            =       =20 2            =       =20 3
>0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0=20 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|   =20 Version    | Message Type  |   =20 Result     |    =20 Code     =20 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|=20 Partition ID =20 |           =20 Transaction=20 Identifier          &nb= sp; =20 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|I|     =20 SubMessage Number     =20 |          =20 Length           &= nbsp; =20 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|           = ;            &n= bsp;    =20 Port           &nb= sp;            =      =20 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|           = ;          =20 Port Session=20 Number           &= nbsp;         =20 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|           = ;         =20 Event Sequence=20 Number           &= nbsp;        =20 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>|x|S|x|x|         &nb= sp;            =             &nb= sp;            =        =20 |
>+-+-+-+-+         &= nbsp;          =20 Label           &n= bsp;            = ;    =20 |
>~          &nb= sp;            =             &nb= sp;            =             &nb= sp; =20 ~
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
>
>
>So=20 a different Event Message picture/definition than what is shown
>in= the=20 ANCP draft, and in RFC3292 section 3.1.3 the label field
>is define= d as=20 4 bytes if length=3D0 and as such no value.
>
>
>
&g= t;So I=20 very much agree with Woj that we need this issue to be resolved,
>a= nd=20 proabably a show of hands what is actually done in=20 different
>implementations, so we can nail down how the event messa= ge=20 is
>suppose to look like in ANCP.
>
>
>I know at = least=20 1 implementation which uses 8 bytes for the
>label=20 field.
>
>
>cheers,
>Peter
>
>
>= ;
>
>
>
>________________________________
>>       =20 From: ancp-bounces@ietf.org
>[mailto:ancp-bounces@ietf.org] On Behal= f Of Tina=20 TSOU
>        Sent: 30. april 20= 08=20 00:19
>        To: Maglione Robe= rta;=20 Sanjay Wadhwa; Wojciech Dec=20 (wdec)
>        Cc:=20 ancp@ietf.org
>        Subject: = Re:=20 [ANCP] question regarding Labels in ANCP
>port up=20 messages
>
>
>       = ; Hi=20 all,
>        It is clear to me = that=20 if Label Length is filled as 0,
>there is nothing to be filled into= =20 Label Value. The whole
>Label part is 4 bytes, not 8=20 bytes.
>
>        Cheers f= rom=20 the last working day before Labor's Day
>holidays in some=20 countries:)
>
>       =20 Tina
>
>         = ;      =20 ----- Original Message=20 -----
>          =      =20 From: Wojciech Dec (wdec) <mailto:wdec@cisco.com>
>        &nbs= p;      =20 To: Sanjay Wadhwa <mailto:swadhwa@juniper.net>
>= ;=20 Maglione Roberta <mailto:roberta.maglione@telecomitalia.it>
>        &nbs= p;      =20 Cc:=20 ancp@ietf.org
>        &nbs= p;      =20 Sent: Wednesday, April 30, 2008 1:12=20 AM
>          &nb= sp;    =20 Subject: Re: [ANCP] question regarding Labels
>in ANCP port up=20 messages
>
>        &= nbsp;      =20 Sanjay,=20 All,
>
>         = ;      =20 What is stated below runs counter to at least
>a handful of=20 ANCP
>          &= nbsp;    =20 implementations, all of which are known to=20 be
>interoperable.
>       = ;        =20 There are really two=20 options:
>         &nb= sp;     =20 1) The current version of the spec is correct,
>and the=20 known
>          =      =20 interoperable implementations do not follow=20 it
>          &nb= sp;    =20 2) The current version of the spec is not
>accurate, and does not=20 reflect
>         &nbs= p;     =20 the fact that the known implementations follow
>the label=20 field
>          =      =20 definition from=20 draft-gsmpv3-base-spec.
>
>     &nbs= p;         =20 I would like to ask you, as the lead editor of
>the spec, to work=20 with
>          &= nbsp;    =20 the WG in resolving what the problem is, and
>clearing up what the= =20 WG
>          &nb= sp;    =20 spec says about and if 1) holds to be true,
>then proposing=20 an
>          &nb= sp;    =20 interoperability=20 fix.
>
>         = ;      =20 In either case, the issue highlights the fact
>that there is=20 still
>          =      =20 lingering confusion as to the dependencies
>ANCP has on rfc3292,=20 or
>          &nb= sp;    =20 draft-gsmpv3-base-spec, or both. It seems to
>be in the best intere= st=20 of
>          &nb= sp;    =20 all to address=20 these.
>
>        &nb= sp;      =20 Regards,
>         &nb= sp;     =20 Woj.
>
>         = ;      =20 > -----Original=20 Message-----
>         = ;      =20 > From: Sanjay Wadhwa [<= FONT=20 size=3D2>mailto:swadhwa@juniper.net]
>         &= nbsp;     =20 > Sent: 29 April 2008=20 17:29
>          =      =20 > To: Maglione=20 Roberta
>         &nbs= p;     =20 > Cc: Wojciech Dec (wdec); ancp@ietf.org;
>Philippe Champagne=20 (pchamp)
>         &nb= sp;     =20 > Subject: RE: question regarding Labels in
>ANCP port up=20 messages
>         &nb= sp;     =20 >
>          &= nbsp;    =20 > Hi=20 Maglione
>         &nb= sp;     =20 >   Yes, the label format is as defined in RFC
>3292. = The=20 ANCP draft=20 is
>          &nb= sp;    =20 > based on RFC 3292 and proposes
>extensions/modifications=20 where
>          =      =20 >=20 required.
>         &n= bsp;     =20 > This is clearly stated upfront both in the
>abstract and=20 in
>          &nb= sp;    =20 > section 2.=20 In
>          &nb= sp;    =20 > section 5.4.2, it clearly  specifies the
>format of "port= up"=20 message
>         &nbs= p;     =20 > (based on RFC 3292), and explicitly states
>the label=20 field
>          =      =20 > should be=20 set
>          &n= bsp;    =20 > to 0. Following is what the draft currently=20 states:
>         &nbs= p;     =20 >
>          &= nbsp;    =20 >
>          &= nbsp;    =20 > 5.4.2 Topology Discovery=20 Extensions
>         &= nbsp;     =20 >
>          &= nbsp;    =20 > The GSMP Event message with PORT UP message
>type (80) is used= =20 for
>          &n= bsp;    =20 > conveying DSL line attributes to the NAS.
>The version field s= hould=20 be
>          &nb= sp;    =20 > set to 3, and the sub field should be set to
>1. The I and=20 subMessage
>         &= nbsp;     =20 > fields SHOULD be set to 1 to signify no
>fragmentation. The Po= rt=20 and
>          &n= bsp;    =20 > Label fields should be set to=20 0.
>          &nb= sp;    =20 >
>          &= nbsp;    =20 > =20 0            =       =20 1            =       =20 2  
>        &nbs= p;      =20 3
>          &nbs= p;    =20 >          0 1 2 3 4 5 6 = 7 8 9=20 0 1 2 3 4 5 6 7
>8 9 0 1 2 3 4=20 5
>          &nbs= p;    =20 > 6 7 8 9 0=20 1
>          &nbs= p;    =20 >
>          &= nbsp;    =20 >
>          &= nbsp;    =20 >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
>          &nb= sp;    =20 >         | Vers  | = =20 Sub  | Message Type =20 |
>Result|       =20 Code
>          &= nbsp;    =20 >=20 |
>          &nbs= p;    =20 >
>          &= nbsp;    =20 >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
>          &nb= sp;    =20 >         | Partition ID = =20 |           
&g= t;Transaction=20 Identifier
>         &= nbsp;     =20 >=20 |
>          &nbs= p;    =20 >
>          &= nbsp;    =20 >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
>          &nb= sp;    =20 >        =20 |I|      SubMessage=20 Number     =20 |   
>      =20 Length
>          = ;     =20 >=20 |
>          &nbs= p;    =20 >
>          &= nbsp;    =20 >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
>          &nb= sp;    =20 >        =20 |            =             &nb= sp;   =20 Port
>          &= nbsp;    =20 >=20 |
>          &nbs= p;    =20 >
>          &= nbsp;    =20 >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
>          &nb= sp;    =20 >        =20 |            =          =20 Port Session=20 Number
>          = ;     =20 >=20 |
>          &nbs= p;    =20 >
>          &= nbsp;    =20 >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
>          &nb= sp;    =20 >        =20 |            =         =20 Event Sequence=20 Number
>          = ;     =20 >=20 |
>          &nbs= p;    =20 >
>          &= nbsp;    =20 >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
>          &nb= sp;    =20 >        =20 |x|S|x|x|
>         &n= bsp;     =20 >=20 |
>          &nbs= p;    =20 >        =20 +-+-+-+-+          &nbs= p;         =20 Label
>          =      =20 >=20 |
>          &nbs= p;    =20 >        =20 ~
>          &nbs= p;    =20 >=20 ~
>          &nbs= p;    =20 >
>          &= nbsp;    =20 >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
>          &nb= sp;    =20 >         |x|x|x|x|x|x|x|x| Me= ssage=20 Type  |  
>Tech Type   | Block=20 Length
>          = ;     =20 >=20 |
>          &nbs= p;    =20 >
>          &= nbsp;    =20 >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
>          &nb= sp;    =20 >        =20 |
>          &nbs= p;    =20 >=20 |
>          &nbs= p;    =20 >        =20 ~            =             =20 Extension=20 Value
>          =      =20 >=20 ~
>          &nbs= p;    =20 >        =20 |
>          &nbs= p;    =20 >=20 |
>          &nbs= p;    =20 >
>          &= nbsp;    =20 >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
>          &nb= sp;    =20 >
>          &= nbsp;    =20 > When we say the label field should be set to
>0, the=20 intention
>         &n= bsp;     =20 > is for=20 the
>          &n= bsp;    =20 > type and length fields in the label TLV to
>be set to 0. We=20 can
>          &n= bsp;    =20 > explicitly state this for=20 clarity.
>         &nb= sp;     =20 >
>          &= nbsp;    =20 >=20 -Sanjay
>         &nbs= p;     =20 >
>          &= nbsp;    =20 > >-----Original=20 Message-----
>         = ;      =20 > >From: Maglione Roberta
>[mailto:roberta.maglione@telecomitalia.it]
>         &= nbsp;     =20 > >Sent: Tuesday, April 29, 2008 8:06=20 AM
>          &nb= sp;    =20 > >To: Sanjay=20 Wadhwa
>          = ;     =20 > >Cc: Wojciech Dec (wdec);=20 ancp@ietf.org;
>pchamp@cisco.com
>    &nb= sp;          =20 > >Subject: RE: question regarding Labels in
>ANCP port up=20 messages
>         &nb= sp;     =20 >=20 >
>          &= nbsp;    =20 >=20 >
>          &= nbsp;    =20 > >Hi Sanjay and=20 All,
>          &= nbsp;    =20 > >     I was reading the current=20 ancp
>protocol draft in order=20 to
>          &nb= sp;    =20 > > understand which should be the correct
>format for the=20 label
>          =      =20 > >field in the ancp port Up=20 message.
>         &nb= sp;     =20 > >Actually as it was already pointed out in
>the alias the=20 draft
>          =      =20 > >in section 5.4.2 says "GSMP Event message
>with PORT UP=20 message
>         &nbs= p;     =20 > >type (80) is used"  thus I am assuming that
>the labe= l in=20 the
>          &n= bsp;    =20 > >port UP message should follow the message
>format defined= =20 in
>          &nb= sp;    =20 > >RFC 3292, section=20 3.1.3:
>          = ;     =20 >=20 >
>          &= nbsp;    =20 > >   =20 0            =       =20 1            =       
>2     =             &nb= sp;=20 3
>          &nbs= p;    =20 > >    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
&g= t;0 1=20 2 3 4 5 6 7 8 9 0=20 1
>          &nbs= p;    =20 >=20 >  
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+
>        &nb= sp;      =20 > >   |x|S|x|x|       Label= =20 Type     =20 |       
>  Label=20 Length        =20 |
>          &nbs= p;    =20 >=20 >  
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+
>        &nb= sp;      =20 > >  =20 |            =             &nb= sp;            =   
>         &= nbsp;           &nbs= p;=20 |
>          &nbs= p;    =20 > >  =20 ~            =             &nb= sp;=20 Label=20 Value  
>        =             &nb= sp; =20 ~
>          &nbs= p;    =20 > >  =20 |            =             &nb= sp;            =   
>         &= nbsp;           &nbs= p;=20 |
>          &nbs= p;    =20 >=20 >  
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+
>        &nb= sp;      =20 >=20 >
>          &= nbsp;    =20 > >but from what I have seen different
>implementations=20 use
>          &n= bsp;    =20 > >different format for label field: in
>particular=20 several
>         &nbs= p;     =20 > >implementations use  a label format that is
>similar = to=20 the=20 one
>          &n= bsp;    =20 > >specified in the expired=20 draft
>draft-ietf-gsmp-v3-base-spec:
>    = ;           =20 >=20 >
>          &= nbsp;    =20 > >    =20 0            =       =20 1            =      
>=20 2            =       =20 3
>          &nbs= p;    =20 > >       0 1 2 3 4 5 6 7 8 9 0 1 2 3= 4 5=20 6 7
>8 9 0 1 2 3 4 5=20 6
>          &nbs= p;    =20 > 7 8 9 0=20 1
>          &nbs= p;    =20 >=20 >
>          &= nbsp;    =20 >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
>          &nb= sp;    =20 > >     =20 |x|S|x|x|x|x|x|x|x|x|x|x|x|x|x|x|    
> &n= bsp;    =20 Label
>          =      =20 > Type        =20 |
>          &nbs= p;    =20 >=20 >
>          &= nbsp;    =20 >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
>          &nb= sp;    =20 > >      |    Label=20 Adaptation          =20 |    
>    =20 Label
>          =      =20 > Length        =20 |
>          &nbs= p;    =20 >=20 >
>          &= nbsp;    =20 >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
>          &nb= sp;    =20 > >     =20 |
>          &nbs= p;    =20 >         =20 |
>          &nbs= p;    =20 > >     =20 ~            =             &nb= sp;=20 Label=20 Value
>          =      =20 >         =20 ~
>          &nbs= p;    =20 > >     =20 |
>          &nbs= p;    =20 >         =20 |
>          &nbs= p;    =20 >=20 >
>          &= nbsp;    =20 >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
>          &nb= sp;    =20 >=20 >
>          &= nbsp;    =20 >=20 >
>          &= nbsp;    =20 > >Even if ancp does not care about the label
>field, having= =20 this
>          &= nbsp;    =20 > >field somehow not clearly specified in the
>current ancp=20 draft
>          =      =20 > >can easily lead to interoperability issues,
>thus I think= =20 it
>          &nb= sp;    =20 > >would be very helpful if you and/or the
>other editors=20 can
>          &n= bsp;    =20 > >clarify what should be the correct format
>for the label=20 field
>          =      =20 > >to be used in the ancp Port Up=20 message.
>         &nb= sp;     =20 >=20 >
>          &= nbsp;    =20 > >Thanks and best=20 regards,
>         &nb= sp;     =20 >=20 >Roberta
>         =       =20 >=20 >
>          &= nbsp;    =20 >=20 >________________________________________
>   &nb= sp;           =20 > >From: Philippe Champagne (pchamp)=20 [pchamp@cisco.com]
>        = ;       =20 > >Sent: Thursday, April 24, 2008 7:14=20 PM
>          &nb= sp;    =20 > >To: Sanjay=20 Wadhwa
>          = ;     =20 > >Cc: Maglione Roberta; Wojciech Dec=20 (wdec);
>ancp@ietf.org
>      &= nbsp;        =20 > >Subject: question regarding  Labels in ANCP
>port up= =20 messages
>         &nb= sp;     =20 >=20 >
>          &= nbsp;    =20 > >Hi=20 Sanjay
>          = ;     =20 >=20 >
>          &= nbsp;    =20 > >In section 5.4.2 of the draft, we=20 have:
>          =      =20 >=20 >
>          &= nbsp;    =20 >=20 >
>          &= nbsp;    =20 > >        =20 0            =       =20 1            =       =20 2
>          &nbs= p;    =20 >        =20 3
>          &nbs= p;    =20 > >         0 1 2 3 4 5 6 7= 8 9=20 0 1 2 3 4 5 6
>7 8 9 0 1 2 3 4 5=20 6
>          &nbs= p;    =20 > >7 8 9 0=20 1
>          &nbs= p;    =20 >=20 >
>          &= nbsp;    =20 >
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>          = ;     =20 > >        | Vers  | = =20 Sub  | Message Type =20 |
>Result|       =20 Code
>          &= nbsp;    =20 > >        =20 |
>          &nbs= p;    =20 >=20 >
>          &= nbsp;    =20 >
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>          = ;     =20 > >        | Partition ID = =20 |           
&g= t;Transaction=20 Identifier
>         &= nbsp;     =20 > >        =20 |
>          &nbs= p;    =20 >=20 >
>          &= nbsp;    =20 >
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>          = ;     =20 > >       =20 |I|      SubMessage=20 Number     =20 |  
>       =20 Length
>          = ;     =20 > >        =20 |
>          &nbs= p;    =20 >=20 >
>          &= nbsp;    =20 >
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>          = ;     =20 > >       =20 |            =             &nb= sp;   =20 Port
>          &= nbsp;    =20 > >        =20 |
>          &nbs= p;    =20 >=20 >
>          &= nbsp;    =20 >
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>          = ;     =20 > >       =20 |            =          =20 Port Session=20 Number
>          = ;     =20 > >        =20 |
>          &nbs= p;    =20 >=20 >
>          &= nbsp;    =20 >
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>          = ;     =20 > >       =20 |            =         =20 Event Sequence=20 Number
>          = ;     =20 > >        =20 |
>          &nbs= p;    =20 >=20 >
>          &= nbsp;    =20 >
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>          = ;     =20 > >       =20 |x|S|x|x|
>         &n= bsp;     =20 > >        =20 |
>          &nbs= p;    =20 > >       =20 +-+-+-+-+          &nbs= p;         =20 Label
>          =      =20 > >        =20 |
>          &nbs= p;    =20 > >       =20 ~
>          &nbs= p;    =20 > >        =20 ~
>          &nbs= p;    =20 >=20 >
>          &= nbsp;    =20 >
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>          = ;     =20 > >        |x|x|x|x|x|x|x|x| Mes= sage=20 Type  |  
>Tech Type  =20 |
>          &nbs= p;    =20 > >Block Length =20 |
>          &nbs= p;    =20 >=20 >
>          &= nbsp;    =20 >
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>          = ;     =20 > >       =20 |
>          &nbs= p;    =20 > >        =20 |
>          &nbs= p;    =20 > >       =20 ~            =             =20 Extension=20 Value
>          =      =20 > >        =20 ~
>          &nbs= p;    =20 > >       =20 |
>          &nbs= p;    =20 > >        =20 |
>          &nbs= p;    =20 >=20 >
>          &= nbsp;    =20 >
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>          = ;     =20 > >Where Label I suppose is taken from the RFC
>3292,=20 section
>         &nbs= p;     =20 > >3.1.3: (well, I'm=20 guessing)
>         &n= bsp;     =20 >=20 >
>          &= nbsp;    =20 > >   A summary of TLV labels supported in
>this ve= rsion=20 of=20 the
>          &n= bsp;    =20 > protocol=20 is
>          &nb= sp;    =20 > >   listed=20 below:
>          = ;     =20 >=20 >
>          &= nbsp;    =20 > >      TLV=20 Label      Type     &nb= sp;=20 Section=20 Title
>          =      =20 > >     =20 ---------     =20 ----      =20 -------------
>        &nbs= p;      =20 > >      ATM=20 Label      0x100      A= TM=20 TLV=20 Labels
>          = ;     =20 > >      FR=20 Label       0x101    &n= bsp;=20 Frame Relay
>TLV=20 Labels
>          = ;     =20 > >      MPLS Gen Label=20 0x102      MPLS
>Generic TLV=20 Labels
>          = ;     =20 > >      FEC=20 Label      0x103      F= EC=20 TLV=20 Labels
>          = ;     =20 >=20 >
>          &= nbsp;    =20 > >   All Labels will be designated as=20 follow:
>         &nbs= p;     =20 >=20 >
>          &= nbsp;    =20 > >   =20 0            =       =20 1            =       
>2     =             &nb= sp;=20 3
>          &nbs= p;    =20 > >    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
&g= t;0 1=20 2 3 4 5 6 7 8 9 0=20 1
>          &nbs= p;    =20 >=20 >  
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+
>        &nb= sp;      =20 > >   |x|S|x|x|       Label= =20 Type     =20 |       
>  Label=20 Length        =20 |
>          &nbs= p;    =20 >=20 >  
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+
>        &nb= sp;      =20 > >  =20 |            =             &nb= sp;            =   
>         &= nbsp;           &nbs= p;=20 |
>          &nbs= p;    =20 > >  =20 ~            =             &nb= sp;=20 Label=20 Value  
>        =             &nb= sp; =20 ~
>          &nbs= p;    =20 > >  =20 |            =             &nb= sp;            =   
>         &= nbsp;           &nbs= p;=20 |
>          &nbs= p;    =20 >=20 >  
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+
>        &nb= sp;      =20 >=20 >
>          &= nbsp;    =20 > >      x: Reserved=20 Flags.
>          = ;     =20 > >         These are gener= ally=20 used by
>specific messages and will=20 be
>          &nb= sp;    =20 > >         defined in thos= e=20 messages.
>         &n= bsp;     =20 >=20 >
>          &= nbsp;    =20 > >      S: Stacked Label=20 Indicator
>         &n= bsp;     =20 > >         Label Stacking = is=20 discussed below
>in section=20 3.1.3.5
>         &nbs= p;     =20 >=20 >
>          &= nbsp;    =20 > >      Label=20 Type
>          &= nbsp;    =20 > >         A 12-bit field= =20 indicating the type
>of=20 label.
>          = ;     =20 >=20 >
>          &= nbsp;    =20 > >      Label=20 Length
>          = ;     =20 > >         A 16-bit field= =20 indicating the
>length of the=20 Label
>          =      =20 > Value=20 field
>          =      =20 > >         in=20 bytes.
>          = ;     =20 >=20 >
>          &= nbsp;    =20 > >      Label=20 Value
>          =      =20 > >         A variable leng= th=20 field that is an
>integer number of 32=20 bit
>          &n= bsp;    =20 > >         words long.&nbs= p;=20 The Label Value field
>is=20 interpreted
>         =       =20 > according=20 to
>          &nb= sp;    =20 > >         the Label Type = as=20 described in the
>following=20 sections.
>         &n= bsp;     =20 >=20 >
>          &= nbsp;    =20 >=20 >
>          &= nbsp;    =20 > >The draft is a bit obscure about this and
>since it=20 doesn't
>         &nbs= p;     =20 > >specify much, it can lead to
>misinterpretation for the=20 unused
>          = ;     =20 > >part. Moreover, it would appear that
>several=20 implementations
>        &n= bsp;      =20 > >currently use another format for the label
>field. Can=20 you
>          &n= bsp;    =20 > >explain?  I mean, how come what's in the
>current dra= ft=20 doesn't
>         &nbs= p;     =20 > >match what's known to be=20 implemented?
>         = ;      =20 >=20 >
>          &= nbsp;    =20 > >I'm still wondering why we carried over
>pieces from GSMP= =20 that
>          &= nbsp;    =20 > >we do not intend to=20 use.
>          &= nbsp;    =20 >=20 >
>          &= nbsp;    =20 > >I would recommend that if we are to keep
>them but not=20 use
>          &n= bsp;    =20 > >them, we should mention precisely how we
>intend not to=20 use
>          &n= bsp;    =20 > >them: that is how many 0 filled bytes this
>is expected to= =20 use
>          &n= bsp;    =20 >=20 >
>          &= nbsp;    =20 > >The rfc 3292 doesn't cover the case where
>this field is n= ot=20 used.
>          =      =20 >=20 >
>          &= nbsp;    =20 > >Can you shed some ligths on=20 this?
>          =      =20 >=20 >
>          &= nbsp;    =20 >=20 >Thanks
>         &= nbsp;     =20 >=20 >Regards
>         =       =20 >=20 >Phil
>         &nb= sp;     =20 >=20 >
>          &= nbsp;    =20 >=20 >
>          &= nbsp;    =20 >=20 >
>          &= nbsp;    =20 >
>>---------------------------------------------------------= -----------
>         &n= bsp;     =20 >=20 >
>          &= nbsp;    =20 > >CONFIDENTIALITY=20 NOTICE
>          = ;     =20 >=20 >
>          &= nbsp;    =20 > >This message and its attachments are
>addressed solely to= =20 the
>          &n= bsp;    =20 > >persons above and may contain confidential
>information. I= f=20 you
>          &n= bsp;    =20 > >have received the message in error, be
>informed that any= =20 use
>          &n= bsp;    =20 > >of the content hereof is prohibited. Please
>return=20 it
>          &nb= sp;    =20 > >immediately to the sender and delete the
>message. Should= =20 you
>          &n= bsp;    =20 > >have any questions, please contact us by replying=20 to
>          &nb= sp;    =20 >=20 >webmaster@telecomitalia.it.
>     &nbs= p;         =20 >=20 >
>          &= nbsp;    =20 > >        Thank=20 you
>          &n= bsp;    =20 >=20 >
>          &= nbsp;    =20 >=20 >           &nb= sp;            =             &nb= sp;  
>www.telecomitalia.it
>    =            =20 >=20 >
>          &= nbsp;    =20 >
>>---------------------------------------------------------= -----------
>         &n= bsp;     =20 >=20 >
>          &= nbsp;    =20 >=20 >
>          &= nbsp;    =20 >
>          &= nbsp;    =20 _______________________________________________
>   =             =20 ANCP mailing=20 list
>          &= nbsp;    =20 ANCP@ietf.org
>        &nbs= p;      =20 https://www.ietf.org/mailman/listinfo/ancp
>
>

--_000_48C276B536524E478C659685995F6AA539DBBBE577RBSJXadredbac_-- --_004_48C276B536524E478C659685995F6AA539DBBBE577RBSJXadredbac_ Content-Type: text/plain; name="draft-wadhwa-gsmp-l2control-configuration-01.txt" Content-Description: draft-wadhwa-gsmp-l2control-configuration-01.txt Content-Disposition: attachment; filename="draft-wadhwa-gsmp-l2control-configuration-01.txt"; creation-date="Mon, 02 Oct 2006 14:31:13 GMT"; modification-date="Fri, 12 May 2006 09:55:21 GMT" Content-Transfer-Encoding: base64 DQoNCg0KDQoNCg0KICAgICBXb3JraW5nIEdyb3VwIE5hbWUgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgU2FuamF5IFdhZGh3YSANCiAgICAgSW50ZXJuZXQgRHJhZnQgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmlwZXIgTmV0d29ya3MgDQogICAg IEV4cGlyZXM6IFNlcHRlbWJlciAyOCwgMjAwNiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgSmVyb21lIE1vaXNhbmQgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKdW5pcGVyIE5ldHdvcmtzIA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFN3YW1pIFN1YnJhbWFuaWFuIA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmlwZXIgTmV0d29y a3MgDQogICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFRob21hcyBIYWFnIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVC1TeXN0ZW1zICAgICAgDQogICAgICAN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIE5vcmJlcnQgVm9pZ3QgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBTaWVtZW5zIA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoJCQkJCQkJICAgIE1hcmNoIDI4 LCAyMDA2ICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAg ICAgICAgICAgICAgICAgICAgICBHU01QIGV4dGVuc2lvbnMgZm9yIGxheWVyMiBjb250cm9sIChM MkMpICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgIFRvcG9sb2d5 IERpc2NvdmVyeSBhbmQgTGluZSBDb25maWd1cmF0aW9uIA0KDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgIGRyYWZ0LXdhZGh3 YS1nc21wLWwyY29udHJvbC1jb25maWd1cmF0aW9uLTAxLnR4dCANCg0KDQogICAgICAgICANCg0K ICAgICBTdGF0dXMgb2YgdGhpcyBNZW1vIA0KDQogICAgICAgICANCg0KICAgICAgICBCeSBzdWJt aXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMgdGhhdCBh bnkgDQogICAgICAgIGFwcGxpY2FibGUgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFpbXMgb2Ygd2hp Y2ggaGUgb3Igc2hlIGlzIGF3YXJlIA0KICAgICAgICBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNj bG9zZWQsIGFuZCBhbnkgb2Ygd2hpY2ggaGUgb3Igc2hlIGJlY29tZXMgDQogICAgICAgIGF3YXJl IHdpbGwgYmUgZGlzY2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggc2VjdGlvbiA2IG9mIEJDUCA3 OS4gDQoNCiAgICAgICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0 aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcgDQogICAgICAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMg YXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQgDQogICAgICAgIG90aGVy IGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0 LQ0KICAgICAgICBEcmFmdHMuIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZh bGlkIGZvciBhIG1heGltdW0gb2YgDQogICAgICAgIHNpeCBtb250aHMgYW5kIG1heSBiZSB1cGRh dGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIA0KICAgICAgICBkb2N1bWVudHMg YXQgYW55IHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMg YXMgDQogICAgICAgIHJlZmVyZW5jZSBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhh biBhcyAid29yayBpbiBwcm9ncmVzcy4iIA0KDQogICAgICAgIFRoZSBsaXN0IG9mIGN1cnJlbnQg SW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdCAgICAgDQogICAgICAgIGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dCANCg0KICAgICAgICBUaGUgbGlzdCBv ZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0ICAg ICANCiAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCANCg0KICAgICAgICBU aGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIFNlcHRlbWJlciAyOCwgMjAwNi4gDQog ICAgICANCiAgICAgIA0KICAgICAgDQoMICAgICBXYWRod2EgZXQuYWwgICAgICAgICAgRXhwaXJl cyBTZXB0ZW1iZXIgMywgMjAwNSAgICAgICAgICAgICAgICBbUGFnZSAxXSANCiAgICAgIA0KDCAg ICAgSW50ZXJuZXQtRHJhZnQgICAgICBkcmFmdC13YWRod2EtZ3NtcC1sMmNvbnRyb2wtY29uZmln dXJhdGlvbi0wMSAgICAgICAgTWFyY2ggMjAwNiANCiAgICAgICAgIA0KDQogICAgIENvcHlyaWdo dCBOb3RpY2UgDQoNCiAgICAgICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAo MjAwNikuICBBbGwgUmlnaHRzIFJlc2VydmVkLiANCg0KICAgICBBYnN0cmFjdCANCg0KICAgICAg ICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBwcm9wb3NlZCBleHRlbnNpb25zIHRvIHRoZSBHU01Q IHByb3RvY29sIHRvIA0KICAgICAgICBhbGxvdyBpdHMgdXNlIGluIGEgYnJvYWRiYW5kIGVudmly b25tZW50LCBhcyBhIGNvbnRyb2wgcGxhbmUgYmV0d2VlbiAgIA0KICAgICAgICBBY2Nlc3MgTm9k ZXMgKGUuZy4gRFNMQU0pIGFuZCBCcm9hZGJhbmQgTmV0d29yayBHYXRld2F5cyAoZS5nLiBCUkFT KS4gDQogICAgICAgIFRoaXMgZG9jdW1lbnQgZm9jdXNlcyBvbiBzcGVjaWZpYyB1c2UgY2FzZXMs IHRvcG9sb2d5IGRpc2NvdmVyeSBhbmQgDQogICAgICAgIGxpbmUgY29uZmlndXJhdGlvbi4gSXQg aXMgaW50ZW5kZWQgdG8gYmUgY29tcGxlbWVudGVkIGJ5IG90aGVyIA0KICAgICAgICBJbnRlcm5l dC1kcmFmdHMgZm9jdXNpbmcgb24gYWRkaXRpb25hbCB1c2UgY2FzZXMuIA0KDQogICAgIENvbnZl bnRpb25zIHVzZWQgaW4gdGhpcyBkb2N1bWVudCANCg0KICAgICAgICBUaGUga2V5IHdvcmRzICJN VVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsIA0KICAg ICAgICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJP UFRJT05BTCIgaW4gdGhpcyANCiAgICAgICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVk IGFzIGRlc2NyaWJlZCBpbiBSRkMtMjExOSBbMV0uIA0KDQogICAgIFRhYmxlIG9mIENvbnRlbnRz IA0KDQogICAgICAgIFRhYmxlIG9mIENvbnRlbnRzIDIgDQoNCiAgICAgICAgMSAgU3BlY2lmaWNh dGlvbiBSZXF1aXJlbWVudHMgIDQgDQoNCiAgICAgICAgMiAgSW50cm9kdWN0aW9uICA0IA0KDQog ICAgICAgIDMgIEJyb2FkYmFuZCBBY2Nlc3MgQWdncmVnYXRpb24gNCANCg0KICAgICAgICAgICAz LjEgICBBVE0tYmFzZWQgYnJvYWRiYW5kIGFnZ3JlZ2F0aW9uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi40IA0KICAgICAgICAgICAzLjIgICBFdGhlcm5ldC1iYXNlZCBicm9hZGJhbmQgYWdncmVn YXRpb24uLi4uLi4uLi4uLi4uLi4uLi4uLi42IA0KICAgICAgICA0ICBMYXllcjIgQ29udHJvbCBQ cm90b2NvbCA3IA0KDQogICAgICAgICAgIDQuMSAgIE92ZXJ2aWV3Li4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjcgDQogICAgICAgICAgIDQuMiAgIExheWVy MiBjb250cm9sIGZvciBBY2Nlc3MgVG9wb2xvZ3kgRGlzY292ZXJ5Li4uLi4uLi4uLi4uLjggDQog ICAgICAgICAgICAgIDQuMi4xICAgIEdvYWxzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLjggDQogICAgICAgICAgICAgIDQuMi4yICAgIE1lc3NhZ2UgRmxvdyAt IEdTTVAgbWFwcGluZy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjkgDQogICAgICAgICAgIDQuMyAg IExheWVyMiBjb250cm9sIGZvciBMaW5lIENvbmZpZ3VyYXRpb24uLi4uLi4uLi4uLi4uLi4uLi4u MTAgDQogICAgICAgICAgICAgIDQuMy4xICAgIEdvYWxzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uMTAgDQogICAgICAgICAgICAgIDQuMy4yICAgIE1lc3NhZ2Ug RmxvdyAtIEdTTVAgbWFwcGluZy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTEgDQogICAgICAgICAg IDQuNCAgIExheWVyMiBDb250cm9sIGZvciBUcmFuc2FjdGlvbmFsIE11bHRpY2FzdC4uLi4uLi4u Li4uLi4uMTIgDQogICAgICAgICAgIDQuNSAgIExheWVyMiBPQU0uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTMgDQogICAgICAgICAgICAgIDQuNS4xICAgIE1l c3NhZ2UgRmxvdyAtIEdTTVAgbWFwcGluZy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTMgDQogICAg ICAgIDUgIEdTTVAgZm9yIExheWVyMiBDb250cm9sIFByb3RvY29sIA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAxNCANCg0KICAgICAgICAgICA1LjEgICBHU01QL1RDUCBj b25uZWN0aW9uIGVzdGFibGlzaG1lbnQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE0IA0KICAgICAg ICAgICA1LjIgICBHU01QIGNvbm5lY3Rpb24ga2VlcC1hbGl2ZS4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjE1IA0KICAgICAgDQogICAgICANCiAgICAgV2FkaHdhIGV0LmFsICAgICAgICAg IEV4cGlyZXMgU2VwdGVtYmVyIDI4LCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgMl0gDQogICAg ICAgICANCgwgICAgIEludGVybmV0LURyYWZ0ICAgICAgZHJhZnQtd2FkaHdhLWdzbXAtbDJjb250 cm9sLWNvbmZpZ3VyYXRpb24tMDEgICAgICAgIE1hcmNoIDIwMDYgDQogICAgICAgICANCg0KICAg ICAgICAgICA1LjMgICBDYXBhYmlsaXR5IG5lZ290aWF0aW9uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjE1IA0KICAgICAgICAgICA1LjQgICBHU01QIE1lc3NhZ2UgRXh0ZW5zaW9u cyBmb3IgTDIgY29udHJvbC4uLi4uLi4uLi4uLi4uLi4uLjE4IA0KICAgICAgICAgICAgICA1LjQu MSAgICBUb3BvbG9neSBEaXNjb3ZlcnkuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE4 IA0KICAgICAgICAgICAgICA1LjQuMiAgICBMaW5lIENvbmZpZ3VyYXRpb24uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjI3IA0KICAgICAgICAgICAgICA1LjQuMyAgICBPQU0uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjI5IA0KICAgICAgICAgICA1 LjUgICBBVE0tc3BlY2lmaWMgY29uc2lkZXJhdGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLjMyIA0KICAgICAgICAgICA1LjYgICBFdGhlcm5ldC1zcGVjaWZpYyBjb25zaWRlcmF0aW9u cy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjMzIA0KICAgICAgICAgICA1LjcgICBHcmFjZWZ1bCBy ZXN0YXJ0IGNvbnNpZGVyYXRpb25zIChUQkQpLi4uLi4uLi4uLi4uLi4uLi4uLjMzIA0KICAgICAg ICA2ICBJQU5BIENvbnNpZGVyYXRpb25zICAzMyANCg0KICAgICAgICA3ICBTZWN1cml0eSBDb25z aWRlcmF0aW9ucyAzMyANCg0KICAgICAgICA4ICBSZWZlcmVuY2VzIDM0IA0KDQogICAgICAgIEF1 dGhvcidzIEFkZHJlc3NlcyAgIDM1IA0KDQogICAgICAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBT dGF0ZW1lbnQgMzUgDQoNCiAgICAgICAgRGlzY2xhaW1lciBvZiBWYWxpZGl0eSAgMzYgDQoNCiAg ICAgICAgQ29weXJpZ2h0IFN0YXRlbWVudCAgMzYgDQoNCiAgICAgICAgQWNrbm93bGVkZ21lbnQg DQogICAgICAgICAgICAgICAgICAgIDM2IA0KDQogICAgICAgICANCg0KICAgICAgICAgDQoNCiAg ICAgICAgIA0KDQogICAgICAgICANCg0KICAgICAgICAgDQoNCiAgICAgICAgIA0KDQogICAgICAg ICANCg0KICAgICAgICAgDQoNCiAgICAgICAgIA0KDQogICAgICAgICANCg0KICAgICAgICAgDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAg DQogICAgICANCiAgICAgV2FkaHdhIGV0LmFsICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDI4 LCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgM10gDQogICAgICAgICANCgwgICAgIEludGVybmV0 LURyYWZ0ICAgICAgZHJhZnQtd2FkaHdhLWdzbXAtbDJjb250cm9sLWNvbmZpZ3VyYXRpb24tMDEg ICAgICAgIE1hcmNoIDIwMDYgDQogICAgICAgICANCg0KICAgICAgICAgDQoNCiAgICAgICAgIA0K DQogICAgICAgICANCg0KICAgICAgICAgDQoNCiAgICAgICAgIA0KDQogICAgIDEgIFNwZWNpZmlj YXRpb24gUmVxdWlyZW1lbnRzIA0KDQogICAgICAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVT VCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwgICANCiAgICAgICAgIlNI T1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwi IGluIHRoaXMgICANCiAgICAgICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRl c2NyaWJlZCBpbiBSRkMgMjExOS4gDQoNCiAgICAgICAgIA0KDQogICAgIDIgIEludHJvZHVjdGlv biANCg0KICAgICAgICBEU0wgaXMgYSB3aWRlbHkgZGVwbG95ZWQgYWNjZXNzIHRlY2hub2xvZ3kg Zm9yIEJyb2FkYmFuZCBBY2Nlc3MgZm9yIA0KICAgICAgICBOZXh0IEdlbmVyYXRpb24gTmV0d29y a3MuIFNldmVyYWwgc3BlY2lmaWNhdGlvbnMgbGlrZSBbMS0zXSBkZXNjcmliZSANCiAgICAgICAg cG9zc2libGUgYXJjaGl0ZWN0dXJlcyBmb3IgdGhlc2UgYWNjZXNzIG5ldHdvcmtzLiBJbiB0aGUg c2NvcGUgb2YgDQogICAgICAgIHRoZXNlIHNwZWNpZmljYXRpb25zIGFyZSB0aGUgZGVsaXZlcnkg b2Ygdm9pY2UsIHZpZGVvIGFuZCBkYXRhIA0KICAgICAgICBzZXJ2aWNlcy4gDQoNCiAgICAgICAg V2hlbiBkZXBsb3lpbmcgdmFsdWUtYWRkZWQgc2VydmljZXMgYWNyb3NzIERTTCBhY2Nlc3MgbmV0 d29ya3MsIA0KICAgICAgICBzcGVjaWFsIGF0dGVudGlvbiByZWdhcmRpbmcgcXVhbGl0eSBvZiBz ZXJ2aWNlIGFuZCBzZXJ2aWNlIGNvbnRyb2wgaXMgDQogICAgICAgIHJlcXVpcmVkLCB3aGljaCBp bXBsaWVzIGEgdGlnaHRlciBjb29yZGluYXRpb24gYmV0d2VlbiBuZXR3b3JrIA0KICAgICAgICBl bGVtZW50cyBpbiB0aGUgYnJvYWRiYW5kIGFjY2VzcyBuZXR3b3JrIHdpdGhvdXQgYnVyZGVuaW5n IHRoZSBPU1MgDQogICAgICAgIGxheWVyLiAgDQoNCiAgICAgICAgVGhpcyBkcmFmdCBkZWZpbmVz IGV4dGVuc2lvbnMgdG8gR1NNUHYzIHRvIGJlIHVzZWQgYXMgYSBjb250cm9sIHBsYW5lIA0KICAg ICAgICBiZXR3ZWVuIGEgc2VydmljZS1vcmllbnRlZCBsYXllciAzIGVkZ2UgZGV2aWNlICh0aGUg QlJBUykgYW5kIGEgDQogICAgICAgIGxheWVyMiBBY2Nlc3MgTm9kZSAoZS5nLiBEU0xBTSkgaW4g b3JkZXIgdG8gcGVyZm9ybSBRb1MtcmVsYXRlZCwgDQogICAgICAgIHNlcnZpY2UtcmVsYXRlZCBh bmQgc3Vic2NyaWJlci1yZWxhdGVkIG9wZXJhdGlvbnMuIA0KDQogICAgICAgICANCiAgICAgMyAg QnJvYWRiYW5kIEFjY2VzcyBBZ2dyZWdhdGlvbiAgDQoNCiAgICAgICAgIA0KICAgICAzLjEgQVRN LWJhc2VkIGJyb2FkYmFuZCBhZ2dyZWdhdGlvbiAgDQoNCiAgICAgICAgRW5kIHRvIGVuZCBEU0wg bmV0d29yayBjb25zaXN0cyBvZiBuZXR3b3JrIGFuZCBhcHBsaWNhdGlvbiBzZXJ2aWNlIA0KICAg ICAgICBwcm92aWRlciBuZXR3b3JrcyAoTlNQIGFuZCBBU1AgbmV0d29ya3MpLCByZWdpb25hbC9h Y2Nlc3MgbmV0d29yaywgDQogICAgICAgIGFuZCBjdXN0b21lciBwcmVtaXNlcyBuZXR3b3JrLiBG aWcgMS4gc2hvd3MgQVRNIGJyb2FkYmFuZCBhY2Nlc3MgDQogICAgICAgIG5ldHdvcmsgY29tcG9u ZW50cy4gDQogICAgICANCiAgICAgIA0KICAgICBXYWRod2EgZXQuYWwgICAgICAgICAgRXhwaXJl cyBTZXB0ZW1iZXIgMjgsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSA0XSANCiAgICAgICAgIA0K DCAgICAgSW50ZXJuZXQtRHJhZnQgICAgICBkcmFmdC13YWRod2EtZ3NtcC1sMmNvbnRyb2wtY29u ZmlndXJhdGlvbi0wMSAgICAgICAgTWFyY2ggMjAwNiANCiAgICAgICAgIA0KDQogICAgICAgIFRo ZSBOU1AgYXV0aGVudGljYXRlcyBhY2Nlc3MgYW5kIHByb3ZpZGVzIGFuZCBtYW5hZ2VzIHRoZSBJ UCBhZGRyZXNzIA0KICAgICAgICB0byBzdWJzY3JpYmVycy4gSXQgaXMgcmVzcG9uc2libGUgZm9y IG92ZXJhbGwgc2VydmljZSBhc3N1cmFuY2UgYW5kIA0KICAgICAgICBpbmNsdWRlcyBpbnRlcm5l dCBzZXJ2aWNlIHByb3ZpZGVycy4gQVNQIHByb3ZpZGVzIGFwcGxpY2F0aW9uIA0KICAgICAgICBz ZXJ2aWNlcyB0byB0aGUgYXBwbGljYXRpb24gc3Vic2NyaWJlciAoZ2FtaW5nLCB2aWRlbywgY29u dGVudCBvbiANCiAgICAgICAgZGVtYW5kLCBJUCB0ZWxlcGhvbnkgZXRjLikuICANCg0KICAgICAg ICAgDQoNCiAgICAgICAgVGhlIFJlZ2lvbmFsL0FjY2VzcyBOZXR3b3JrIGNvbnNpc3RzIG9mIHRo ZSBSZWdpb25hbCBOZXR3b3JrLCANCiAgICAgICAgQnJvYWRiYW5kIFJlbW90ZSBBY2Nlc3MgU2Vy dmVyLCBhbmQgdGhlIEFjY2VzcyBOZXR3b3JrIGFzIHNob3cgaW4gRmlnIA0KICAgICAgICAxLiBJ dHMgcHJpbWFyeSBmdW5jdGlvbiBpcyB0byBwcm92aWRlIGVuZC10by1lbmQgdHJhbnNwb3J0IGJl dHdlZW4gDQogICAgICAgIHRoZSBjdXN0b21lciBwcmVtaXNlcyBhbmQgdGhlIE5TUCBvciBBU1Au IFRoZSBSZWdpb25hbC9BY2Nlc3MgTmV0d29yayANCiAgICAgICAgbWF5IGFsc28gcHJvdmlkZSBo aWdoZXIgbGF5ZXIgZnVuY3Rpb25zIHN1Y2ggYXMgUW9TIGFuZCBjb250ZW50IA0KICAgICAgICBk aXN0cmlidXRpb24uICANCg0KICAgICAgICBUaGUgUmVnaW9uYWwgTmV0d29yayBjb25uZWN0cyBv bmUgb3IgbW9yZSBCUkFTIGFuZCBhc3NvY2lhdGVkIEFjY2VzcyANCiAgICAgICAgTmV0d29yayB0 byBOU1BzIGFuZCBBU1BzLiBJdCBzdXBwb3J0cyBhZ2dyZWdhdGlvbiBvZiB0cmFmZmljIGZyb20g DQogICAgICAgIG11bHRpcGxlIEFjY2VzcyBOZXR3b3JrcyBhbmQgaGFuZHMgb2ZmIGxhcmdlciBn ZW9ncmFwaGljIGxvY2F0aW9ucyB0byANCiAgICAgICAgTlNQcyBhbmQgQVNQcyAtIHJlbGlldmlu ZyBhIHBvdGVudGlhbCByZXF1aXJlbWVudCBmb3IgdGhlbSB0byBidWlsZCANCiAgICAgICAgaW5m cmFzdHJ1Y3R1cmUgdG8gYXR0YWNoIG1vcmUgZGlyZWN0bHkgdG8gdGhlIHZhcmlvdXMgQWNjZXNz IA0KICAgICAgICBOZXR3b3Jrcy4gICANCg0KICAgICAgICBUaGUgQWNjZXNzIE5vZGUgdGVybWlu YXRlcyB0aGUgRFNMIHNpZ25hbC4gSXQgY291bGQgY29uc2lzdCBvZiBEU0xBTSANCiAgICAgICAg aW4gdGhlIGNlbnRyYWwgb2ZmaWNlICwgb3IgcmVtb3RlIERTTEFNLCBvciBhIFJlbW90ZSBBY2Nl c3MgDQogICAgICAgIE11bHRpcGxleGVyIChSQU0pLiBBIERTTEFNIGh1YiBjYW4gYmUgdXNlZCBp biBhIGNlbnRyYWwgb2ZmaWNlIHRvIA0KICAgICAgICBhZ2dyZWdhdGUgdHJhZmZpYyBmcm9tIG11 bHRpcGxlIHJlbW90ZSBwaHlzaWNhbCBkZXZpY2VzLCBhbmQgaXMgDQogICAgICAgIGNvbnNpZGVy ZWQgbG9naWNhbGx5IHRvIGJlIGEgcGFydCBvZiB0aGUgQWNjZXNzIE5vZGUuIEFjY2VzcyBub2Rl IGlzIA0KICAgICAgICB0aGUgZmlyc3QgcG9pbnQgaW4gdGhlIG5ldHdvcmsgd2hlcmUgdHJhZmZp YyBvbiBtdWx0aXBsZSBEU0wgbGluZXMgDQogICAgICAgIHdpbGwgYmUgYWdncmVnYXRlZCBvbnRv IGEgc2luZ2xlIG5ldHdvcmsuIEluIGFuIEFUTSBhY2Nlc3MgbmV0d29yaywgDQogICAgICAgIGFj Y2VzcyBOb2RlIGlzIHByaW1hcmlseSBhbiBBVE0gY29uY2VudHJhdG9yLCBtYXBwaW5nIFBWQ3Mg ZnJvbSB0aGUgDQogICAgICAgIERTTCBtb2RlbSB0byBQVkNzIGluIHRoZSBBVE0gY29yZS4gIA0K DQogICAgICAgIFRoZSBCUkFTIHBlcmZvcm1zIG11bHRpcGxlIGZ1bmN0aW9ucyBpbiB0aGUgbmV0 d29yay4gVGhlIEJSQVMgaXMgdGhlIA0KICAgICAgICBhZ2dyZWdhdGlvbiBwb2ludCBmb3IgdGhl IHN1YnNjcmliZXIgdHJhZmZpYy4gSXQgcHJvdmlkZXMgYWdncmVnYXRpb24gDQogICAgICAgIGNh cGFiaWxpdGllcyAoZS5nLiBJUCwgUFBQLCBBVE0pIGJldHdlZW4gdGhlIFJlZ2lvbmFsL0FjY2Vz cyBOZXR3b3JrIA0KICAgICAgICBhbmQgdGhlIE5TUCBvciBBU1AuIFRoZXNlIGluY2x1ZGUgdHJh ZGl0aW9uYWwgQVRNLWJhc2VkIG9mZmVyaW5ncyBhbmQgDQogICAgICAgIG5ld2VyLCBtb3JlIG5h dGl2ZSBJUC1iYXNlZCBzZXJ2aWNlcy4gVGhpcyBpbmNsdWRlcyBzdXBwb3J0IGZvciANCiAgICAg ICAgUG9pbnQtdG8tUG9pbnQgUHJvdG9jb2wgb3ZlciBBVE0gKFBQUG9BKSBhbmQgUFBQIG92ZXIg RXRoZXJuZXQgDQogICAgICAgIChQUFBvRSksIGFzIHdlbGwgYXMgZGlyZWN0IElQIHNlcnZpY2Vz IGVuY2Fwc3VsYXRlZCBvdmVyIGFuIA0KICAgICAgICBhcHByb3ByaWF0ZSBsYXllciBJSSB0cmFu c3BvcnQuICANCg0KICAgICAgICBCZXlvbmQgYWdncmVnYXRpb24sIEJSQVMgaXMgYWxzbyB0aGUg aW5qZWN0aW9uIHBvaW50IGZvciBwb2xpY3kgDQogICAgICAgIG1hbmFnZW1lbnQgYW5kIElQIFFv UyBpbiB0aGUgUmVnaW9uYWwvQWNjZXNzIE5ldHdvcmtzLiBJbiBvcmRlciB0byANCiAgICAgICAg YWxsb3cgSVAgUW9TIHN1cHBvcnQgb3ZlciBhbiBleGlzdGluZyBub24tSVAtYXdhcmUgbGF5ZXIg MiBhY2Nlc3MgDQogICAgICAgIG5ldHdvcmsgd2l0aG91dCB1c2luZyBtdWx0aXBsZSBsYXllciAy IFFvUyBjbGFzc2VzLCBhIG1lY2hhbmlzbSBiYXNlZCANCiAgICAgICAgb24gaGllcmFyY2hpY2Fs IHNjaGVkdWxpbmcgaXMgdXNlZC4gVGhpcyBtZWNoYW5pc20gZGVmaW5lZCBpbiBbMV0sIA0KICAg ICAgICBwcmVzZXJ2ZXMgSVAgUW9TIG92ZXIgdGhlIEFUTSBuZXR3b3JrIGJldHdlZW4gdGhlIEJS QVMgYW5kIHRoZSBSR3MgYnkgICAgDQogICAgICANCiAgICAgIA0KICAgICBXYWRod2EgZXQuYWwg ICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjgsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSA1 XSANCiAgICAgICAgIA0KDCAgICAgSW50ZXJuZXQtRHJhZnQgICAgICBkcmFmdC13YWRod2EtZ3Nt cC1sMmNvbnRyb2wtY29uZmlndXJhdGlvbi0wMSAgICAgICAgTWFyY2ggMjAwNiANCiAgICAgICAg IA0KDQogICAgICAgIGNhcmVmdWxseSBjb250cm9sbGluZyBkb3duc3RyZWFtIHRyYWZmaWMgaW4g dGhlIEJSQVMsIHNvIHRoYXQgICANCiAgICAgICAgc2lnbmlmaWNhbnQgcXVldWluZyBhbmQgY29u Z2VzdGlvbiBkb2VzIG5vdCBvY2N1ciBmdXJ0aGVyIGRvd24gdGhlICANCg0KICAgICAgICBBVE0g bmV0d29yay4gVGhpcyBpcyBhY2hpZXZlZCBieSB1c2luZyBhIGRpZmZzZXJ2LWF3YXJlIGhpZXJh cmNoaWNhbCANCiAgICAgICAgc2NoZWR1bGVyIGluIHRoZSBCUkFTIHRoYXQgd2lsbCBhY2NvdW50 IGZvciBkb3duc3RyZWFtIHRydW5rIA0KICAgICAgICBiYW5kd2lkdGhzIGFuZCBEU0wgc3luY2gg cmF0ZXMuIA0KICAgICAgICAgDQogICAgICAgIFJvdXRpbmcgR2F0ZXdheSBpcyBhIGN1c3RvbWVy IHByZW1pc2VzIGZ1bmN0aW9uYWwgZWxlbWVudCB0aGF0IA0KICAgICAgICBwcm92aWRlcyBJUCBy b3V0aW5nIGFuZCBRT1MgY2FwYWJpbGl0aWVzLiBJdCBtYXkgYmUgaW50ZWdyYXRlZCBpbnRvIA0K ICAgICAgICBvciBiZSBzZXBhcmF0ZSBmcm9tIHRoZSBtb2RlbS4gDQogICAgICAgICANCiAgICAg ICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBY2Nlc3Mg ICAgICAgICAgICAgICAgICAgICBDdXN0b21lciAgDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDwtLS0gQWdncmVnYXRpb24gLS0tPiAgIDwtLS0tLS0tIFByZW1pc2VzIC0t LS0tLS0+ICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTmV0 d29yayAgICAgICAgICAgICAgICAgICAgIE5ldHdvcmsgDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0t LS0tLS0tLS0tLSsgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgDQogICAgICAgICAgICAg ICstLS0tLS0tLS0tKyAgICstLS0tLSsgICB8ICstLS0tLSsgICstLS0tLS0rIHwtLXwrLS0tLS0r ICstLSsgKy0tLS0tLS0tLS0rIHwgDQogICAgICAgICAgICAgIHwgICAgICAgICAgfCArLXxCUkFT IHwtLS18IHxBVE0gIHwtLXxBY2Nlc3N8IHwgIHx8RFNMICB8LXxSR3wtfFN1YnNjcmliZXJ8IHwg DQogICAgICAgIE5TUC0tLStSZWdpb25hbCAgfCB8ICstLS0tLSsgICB8ICstLS0tLSsgIHwgTm9k ZSB8IHwgIHx8TW9kZW18ICstLSsgfERldmljZXMgICB8IHwgDQogICAgICAgICAgICAgIHxCcm9h ZGJhbmQgfCB8ICstLS0tLSsgICB8ICAgICAgICAgICstLS0tLS0rIHwgIHwrLS0tLS0rICAgICAg Ky0tLS0tLS0tLS0rIHwgDQogICAgICAgICAgICAgIHxOZXR3b3JrICAgfC0rLXxCUkFTIHwgICAr LS0tLS0tLS0tLS0tLS0tfC0tLSsgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgDQogICAg ICAgIEFTUC0tLSsgICAgICAgICAgfCB8ICstLS0tLSsgICAgICAgICAgICAgICAgICAgfCAgICAg ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgDQogICAgICAgICAgICAgIHwgICAgICAgICAg fCB8ICstLS0tLSsgICAgICAgICAgICAgICAgICAgfCAgICAgIHwgKy0tLS0tKyArLS0rICstLS0t LS0tLS0tK3wgDQogICAgICAgICAgICAgICstLS0tLS0tLS0tKyArLXxCUkFTIHwgICAgICAgICAg ICAgICAgICAgKy0tLS0tLXwgfCBEU0wgfC18Ukd8LXxTdWJzY3JpYmVyfHwgDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICstLS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAgIHwgfE1v ZGVtfCArLS0rIHxEZXZpY2VzICAgfHwgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgKy0tLS0tKyAgICAgICstLS0tLS0tLS0t K3wgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgDQogICAgICAgICBSRyAgIDog Um91dGluZyBHYXRld2F5IA0KICAgICAgICAgQlJBUyA6IEJyb2FkYmFuZCBSZW1vdGUgQWNjZXNz IFNlcnZlciANCiAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICBG aWcuMSAgQVRNIEJyb2FkYmFuZCBBZ2dyZWdhdGlvbiBUb3BvbG9neSANCiAgICAgICAgIA0KICAg ICAgICAgDQoNCiAgICAgMy4yIEV0aGVybmV0LWJhc2VkIGJyb2FkYmFuZCBhZ2dyZWdhdGlvbiAg DQoNCiAgICAgVGhlIEV0aGVybmV0IGFnZ3JlZ2F0aW9uIG5ldHdvcmsgYXJjaGl0ZWN0dXJlIGJ1 aWxkcyBvbiB0aGUgRXRoZXJuZXQgDQogICAgIGJyaWRnaW5nL3N3aXRjaGluZyBjb25jZXB0cyBk ZWZpbmVkIGluIElFRUUgODAyLiBUaGUgRXRoZXJuZXQgDQogICAgIGFnZ3JlZ2F0aW9uIG5ldHdv cmsgcHJvdmlkZXMgdHJhZmZpYyBhZ2dyZWdhdGlvbiwgY2xhc3Mgb2Ygc2VydmljZSANCiAgICAg ZGlzdGluY3Rpb24sIGFuZCBjdXN0b21lciBzZXBhcmF0aW9uIGFuZCB0cmFjZWFiaWxpdHkuIFZM QU4gdGFnZ2luZyANCiAgICAgZGVmaW5lZCBpbiBJRUVFIDgwMi4xUSBhbmQgYmVpbmcgZW5oYW5j ZWQgYnkgSUVFRSA4MDIuMWFkIGlzIHVzZWQgYXMgDQogICAgIHN0YW5kYXJkIHZpcnR1YWxpemF0 aW9uIG1lY2hhbmlzbSBpbiB0aGUgRXRoZXJuZXQgYWdncmVnYXRpb24gbmV0d29yay4gDQogICAg IFRoZSBhZ2dyZWdhdGlvbiBkZXZpY2VzIGFyZSAicHJvdmlkZXIgZWRnZSBicmlkZ2VzIiBkZWZp bmVkIGluIElFRUUgDQogICAgIDgwMi5hZC4gIA0KICAgICBTdGFja2VkIFZMQU4gdGFncyBwcm92 aWRlIG9uZSBwb3NzaWJsZSB3YXkgdG8gY3JlYXRlIGVxdWl2YWxlbnQgb2YgDQogICAgICJ2aXJ0 dWFsIHBhdGhzIiBhbmQgInZpcnR1YWwgY2lyY3VpdHMiIGluIHRoZSBhZ2dyZWdhdGlvbiBuZXR3 b3JrLiBUaGUgDQogICAgICANCiAgICAgIA0KICAgICBXYWRod2EgZXQuYWwgICAgICAgICAgRXhw aXJlcyBTZXB0ZW1iZXIgMjgsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSA2XSANCiAgICAgICAg IA0KDCAgICAgSW50ZXJuZXQtRHJhZnQgICAgICBkcmFmdC13YWRod2EtZ3NtcC1sMmNvbnRyb2wt Y29uZmlndXJhdGlvbi0wMSAgICAgICAgTWFyY2ggMjAwNiANCiAgICAgICAgIA0KDQogICAgICJv dXRlciIgdmxhbiBjb3VsZCBiZSB1c2VkIHRvIGNyZWF0ZSBhIGZvcm0gb2YgInZpcnR1YWwgcGF0 aCIgYmV0d2VlbiBhIA0KICAgICBnaXZlbiBEU0xBTSBhbmQgYSBnaXZlbiBCUkFTLiBBbmQgImlu bmVyIiBWTEFOIHRhZ3MgdG8gY3JlYXRlIGEgZm9ybSBvZiANCiAgICAgInZpcnR1YWwgY2lyY3Vp dCIgb24gYSBwZXIgRFNMIGxpbmUgYmFzaXMuIFRoaXMgaXMgMToxIFZMQU4gYWxsb2NhdGlvbiAN CiAgICAgbW9kZWwuIEFuIGFsdGVybmF0aXZlIG1vZGVsIGlzIHRvIGJyaWRnZSBzZXNzaW9ucyBm cm9tIG11bHRpcGxlIA0KICAgICBzdWJzY3JpYmVycyBiZWhpbmQgYSBEU0xBTSBpbnRvIGEgc2lu Z2xlIFZMQU4gaW4gdGhlIGFnZ3JlZ2F0aW9uIA0KICAgICBuZXR3b3JrLiBUaGlzIGlzIE46MSBW TEFOIGFsbG9jYXRpb24gbW9kZWwuIEFyY2hpdGVjdHVyYWwgYW5kIA0KICAgICB0b3BvbG9naWNh bCBtb2RlbHMgb2YgYW4gRXRoZXJuZXQgYWdncmVnYXRpb24gbmV0d29yayBpbiBjb250ZXh0IG9m IERTTCANCiAgICAgYWdncmVnYXRpb24gYXJlIGRlZmluZWQgaW4gWzhdLiAgDQogICAgICAgICAN Cg0KICAgICA0ICBMYXllcjIgQ29udHJvbCBQcm90b2NvbCANCg0KICAgICA0LjEgT3ZlcnZpZXcg DQoNCiAgICAgICAgVGhlcmUgaXMgYSByZXF1aXJlbWVudCBmb3IgYSBjb250cm9sIHBsYW5lIGJl dHdlZW4gc2VydmljZS1vcmllbnRlZCANCiAgICAgICAgbGF5ZXIgMyBlZGdlIGRldmljZSAodGhl IEJSQVMpIGFuZCBhIGxheWVyIDIgQWNjZXNzIE5vZGUgKGUuZy4gRFNMQU0pICAgIA0KICAgICAg ICBpbiBvcmRlciB0byBwZXJmb3JtIFFvUy1yZWxhdGVkLCBzZXJ2aWNlLXJlbGF0ZWQgYW5kIHN1 YnNjcmliZXItDQogICAgICAgIHJlbGF0ZWQgb3BlcmF0aW9ucy4gQSBkZWRpY2F0ZWQgY29udHJv bCBwcm90b2NvbCBiZXR3ZWVuIEJSQVMgYW5kIA0KICAgICAgICBhY2Nlc3Mgbm9kZXMgY2FuIGZl Y2lsaXRhdGUgIkJSQVMgbWFuYWdlZCIgdGlnaHQgUU9TIGNvbnRyb2wgaW4gdGhlIA0KICAgICAg ICBhY2Nlc3MgbmV0d29yaywgc2ltcGxpZmllZCBPU1MgaW5mcmFzdHJ1Y3R1cmUgZm9yIHNlcnZp Y2UgbWFuYWdlbWVudCwgDQogICAgICAgIG9wdGltaXplZCBtdWx0aWNhc3QgcmVwbGljYXRpb24g dG8gZW5hYmxlIHZpZGVvIHNlcnZpY2VzIG92ZXIgRFNMLCANCiAgICAgICAgc3Vic2NyaWJlciBz dGF0aXN0aWNzIHJldHJpZXZhbCBvbiB0aGUgQlJBUyBmb3IgYWNjb3VudGluZyBwdXJwb3Nlcywg DQogICAgICAgIGFuZCBmYXVsdCBpc29sYXRpb24gY2FwYWJpbGl0eSBvbiB0aGUgQlJBUyBmb3Ig dGhlIHVuZGVybHlpbmcgYWNjY2VzcyANCiAgICAgICAgdGVjaG5vbG9neS4gVGhpcyBkb2N1bWVu dCBwcm92aWRlcyBleHRlbnNpb25zIHRvIEdTTVB2MyBbNF0gdG8gDQogICAgICAgIGltcGxlbWVu dCBsYXllcjIgY29udHJvbCBwcm90b2NvbC4gDQoNCiAgICAgICAgRm9sbG93aW5nIHNlY3Rpb25z IGRpc2N1c3MgdGhlIHVzZSBvZiBsYXllcjIgY29udHJvbCBwcm90b2NvbCBmb3IgDQogICAgICAg IGltcGxlbWVudGluZzogDQoNCiAgICAgICAgICAuIER5bmFtaWMgZGlzY292ZXJ5IG9mIGFjY2Vz cyB0b3BvbG9neSBieSB0aGUgQlJBUyB0byBwcm92aWRlIA0KICAgICAgICAgICAgIHRpZ2h0IFFP UyBjb250cm9sIGluIHRoZSBhY2Nlc3MgbmV0d29yay4gDQoNCiAgICAgICAgICAuIFB1c2hpbmcg dG8gdGhlIGFjY2Vzcy1ub2Rlcywgc3Vic2NyaWJlciBhbmQgc2VydmljZSBkYXRhIA0KICAgICAg ICAgICAgIHJldHJpZXZlZCBieSB0aGUgQlJBUyBmcm9tIGFuIE9TUyBzeXN0ZW0gKGUuZy4gcmFk aXVzIHNlcnZlciksIA0KICAgICAgICAgICAgIHRvIHNpbXBsaWZ5IE9TUyBpbmZyYXN0cnVjdHVy ZSBmb3Igc2VydmljZSBtYW5hZ2VtZW50LiANCg0KICAgICAgICAgIC4gT3B0aW1pemVkLCAiQlJB UyBjb250cm9sbGVkIGFuZCBtYW5hZ2VkIiBtdWx0aWNhc3QgcmVwbGljYXRpb24gDQogICAgICAg ICAgICAgYnkgYWNjZXNzLW5vZGVzIGF0IEwyIGxheWVyLiAgDQoNCiAgICAgICAgICAuIEJSQVMg Y29udHJvbGxlZCwgb24tZGVtYW5kIGFjY2Vzcy1saW5lIHRlc3QgY2FwYWJpbGl0eSANCiAgICAg ICAgICAgICAocnVkaW1lbnRhcnkgZW5kLXRvLWVuZCBPQU0pLiAgICANCg0KICAgICAgICBJbiBh ZGRpdGlvbiB0byBEU0wsIGFsdGVybmF0ZSBicm9hZGJhbmQgYWNjZXNzIHRlY2hub2xvZ2llcyAo ZS5nLiANCiAgICAgICAgTWV0cm8tRXRoZXJuZXQsIFBhc3NpdmUgT3B0aWNhbCBOZXR3b3JraW5n LCBXaU1heCkgd2lsbCBoYXZlIHNpbWlsYXIgDQogICAgICAgIGNoYWxsZW5nZXMgdG8gYWRkcmVz cywgYW5kIGNvdWxkIGJlbmVmaXQgZnJvbSB0aGUgc2FtZSBhcHByb2FjaCBvZiBhIA0KICAgICAg ICBjb250cm9sIHBsYW5lIGJldHdlZW4gYSBCUkFTIGFuZCBhbiBBY2Nlc3MgTm9kZSAoZS5nLiBP TFQpLCBwcm92aWRpbmcgDQogICAgICAgIGEgdW5pZmllZCBjb250cm9sIGFuZCBtYW5hZ2VtZW50 IGFyY2hpdGVjdHVyZSBmb3IgbXVsdGlwbGUgYWNjZXNzIA0KICAgICAgDQogICAgICANCiAgICAg V2FkaHdhIGV0LmFsICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDI4LCAyMDA2ICAgICAgICAg ICAgICAgW1BhZ2UgN10gDQogICAgICAgICANCgwgICAgIEludGVybmV0LURyYWZ0ICAgICAgZHJh ZnQtd2FkaHdhLWdzbXAtbDJjb250cm9sLWNvbmZpZ3VyYXRpb24tMDEgICAgICAgIE1hcmNoIDIw MDYgDQogICAgICAgICANCg0KICAgICAgICB0ZWNobm9sb2dpZXMsIGhlbmNlIGZhY2lsaXRhdGlu ZyBtaWdyYXRpb24gZnJvbSBvbmUgdG8gdGhlIG90aGVyIA0KICAgICAgICBhbmQvb3IgcGFyYWxs ZWwgZGVwbG95bWVudHMuICANCg0KICAgICAgICBHU01QdjMgaXMgYW4gaWRlYWwgZml0IGZvciBp bXBsZW1lbnRpbmcgbGF5ZXIyIGNvbnRyb2wgcHJvdG9jb2wuIEl0IA0KICAgICAgICBpcyBleHRl bnNpYmxlIGFuZCBjYW4gYmUgcnVuIG92ZXIgVENQL0lQLCB3aGljaCBtYWtlcyBpdCBwb3NzaWJs ZSB0byANCiAgICAgICAgcnVuIG92ZXIgZGlmZmVyZW50IGFjY2VzcyB0ZWNobm9sb2dpZXMuIA0K DQogICAgICAgICANCg0KICAgICA0LjIgTGF5ZXIyIGNvbnRyb2wgZm9yIEFjY2VzcyBUb3BvbG9n eSBEaXNjb3ZlcnkgDQoNCiAgICAgNC4yLjEgR29hbHMgDQoNCiAgICAgICAgWzFdIGRpc2N1c3Nl cyB2YXJpb3VzIHF1ZXVpbmcvc2NoZWR1bGluZyBtZWNoYW5pc21zIHRvIGF2b2lkIA0KICAgICAg ICBjb25nZXN0aW9uIGluIHRoZSBhY2Nlc3MgbmV0d29yayB3aGlsZSBkZWFsaW5nIHdpdGggbXVs dGlwbGUgZmxvd3MgDQogICAgICAgIHdpdGggZGlzdGluY3QgUW9TIHJlcXVpcmVtZW50cy4gU3Vj aCBtZWNoYW5pc21zIHJlcXVpcmUgdGhhdCB0aGUgQlJBUyANCiAgICAgICAgZ2FpbnMga25vd2xl ZGdlIGFib3V0IHRoZSB0b3BvbG9neSBvZiB0aGUgYWNjZXNzIG5ldHdvcmssIHRoZSB2YXJpb3Vz IA0KICAgICAgICBsaW5rcyBiZWluZyB1c2VkIGFuZCB0aGVpciByZXNwZWN0aXZlIHJhdGVzLiBT b21lIG9mIHRoZSBpbmZvcm1hdGlvbiANCiAgICAgICAgcmVxdWlyZWQgaXMgc29tZXdoYXQgZHlu YW1pYyBpbiBuYXR1cmUgKGUuZy4gRFNMIHN5bmMgcmF0ZSksIGhlbmNlIA0KICAgICAgICBjYW5u b3QgY29tZSBmcm9tIGEgcHJvdmlzaW9uaW5nIGFuZC9vciBpbnZlbnRvcnkgbWFuYWdlbWVudCBP U1MgDQogICAgICAgIHN5c3RlbS4gU29tZSBvZiB0aGUgaW5mb3JtYXRpb24gdmFyaWVzIGxlc3Mg ZnJlcXVlbnRseSAoZS5nLiBjYXBhY2l0eSANCiAgICAgICAgb2YgYSBEU0xBTSB1cGxpbmspLCBi dXQgbmV2ZXJ0aGVsZXNzIG5lZWRzIHRvIGJlIGtlcHQgc3RyaWN0bHkgaW4gDQogICAgICAgIHN5 bmMgYmV0d2VlbiB0aGUgYWN0dWFsIGNhcGFjaXR5IG9mIHRoZSB1cGxpbmsgYW5kIHRoZSBpbWFn ZSB0aGUgQlJBUyANCiAgICAgICAgaGFzIG9mIGl0LiAgDQoNCiAgICAgICAgT1NTIHN5c3RlbXMg YXJlIHJhcmVseSBhYmxlIHRvIGVuZm9yY2UgaW4gYSByZWxpYWJsZSBhbmQgc2NhbGFibGUgDQog ICAgICAgIG1hbm5lciB0aGUgY29uc2lzdGVuY3kgb2Ygc3VjaCBkYXRhLCBub3RhYmx5IGFjcm9z cyBvcmdhbml6YXRpb25hbCANCiAgICAgICAgYm91bmRhcmllcy4gRHluYW1pYyBhbmQgYXV0b21h dGVkIGRpc2NvdmVyeSBvZiB0aGUgYWNjZXNzIG5ldHdvcmsgDQogICAgICAgIHRvcG9sb2d5IHdv dWxkIGhlbHAgdG8gYWRkcmVzcyB0aGVzZSBpc3N1ZXMsIG5vdGFibHkgd2hlbiBwZXJmb3JtZWQg DQogICAgICAgIGJ5IGFuIGludGVyb3BlcmFibGUgYW5kIHN0YW5kYXJkaXplZCBwcm90b2NvbC4g Rm9sbG93aW5nIHNlY3Rpb24gDQogICAgICAgIGRlc2NyaWJlcyBHU01QdjMgbWVzc2FnZXMgdGhh dCBhbGxvdyB0aGUgQWNjZXNzIE5vZGUgKGUuZy4gRFNMQU0pIHRvIA0KICAgICAgICBjb21tdW5p Y2F0ZSB0byB0aGUgQlJBUywgYWNjZXNzIG5ldHdvcmsgdG9wb2xvZ3kgaW5mb3JtYXRpb24gYW5k IGFueSANCiAgICAgICAgY29ycmVzcG9uZGluZyB1cGRhdGVzLiAgDQoNCiAgICAgICAgU29tZSBv ZiB0aGUgcGFyYW1ldGVycyB0aGF0IGNhbiBiZSBjb21tdW5pY2F0ZWQgZnJvbSB0aGUgRFNMQU0g dG8gdGhlIA0KICAgICAgICBCUkFTIGluY2x1ZGUgRFNMIGxpbmUgc3RhdGUsIGFjdHVhbCB1cHN0 cmVhbSBhbmQgZG93bnN0cmVhbSBkYXRhIA0KICAgICAgICByYXRlcyBvZiBhIHN5bmNocm9uaXpl ZCBEU0wgbGluaywgbWF4aW11bSBhdHRhaW5hYmxlIHVwc3RyZWFtIGFuZCANCiAgICAgICAgZG93 bnN0cmVhbSBkYXRhIHJhdGVzLCBpbnRlcmxlYXZpbmcgZGVsYXkgZXRjLiBUb3BvbG9neSBkaXNj b3ZlcnkgaXMgDQogICAgICAgIHNwZWNpZmljYWxseSBpbXBvcnRhbnQgaW4gY2FzZSB0aGUgbmV0 IGRhdGEgcmF0ZSBvZiB0aGUgRFNMIGxpbmUgDQogICAgICAgIGNoYW5nZXMgb3ZlciB0aW1lLiBU aGUgRFNMIG5ldCBkYXRhIHJhdGUgbWF5IGJlIGRpZmZlcmVudCBldmVyeSB0aW1lIA0KICAgICAg ICB0aGUgRFNMIG1vZGVtIGlzIHR1cm5lZCBvbi4gQWRkaXRpb25hbGx5LCBkdXJpbmcgdGhlIHRp bWUgdGhlIERTTCANCiAgICAgICAgbW9kZW0gaXMgYWN0aXZlLCBkYXRhIHJhdGUgY2hhbmdlcyBj YW4gb2NjdXIgZHVlIHRvIGVudmlyb25tZW50YWwgDQogICAgICAgIGNvbmRpdGlvbnMgKHRoZSBE U0wgbGluZSBjYW4gZ2V0ICJvdXQgb2Ygc3luYyIgYW5kIGNhbiByZXRyYWluIHRvIGEgDQogICAg ICAgIGxvd2VyIHZhbHVlLiAgDQoNCg0KDQogICAgICANCiAgICAgIA0KICAgICBXYWRod2EgZXQu YWwgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjgsIDIwMDYgICAgICAgICAgICAgICBbUGFn ZSA4XSANCiAgICAgICAgIA0KDCAgICAgSW50ZXJuZXQtRHJhZnQgICAgICBkcmFmdC13YWRod2Et Z3NtcC1sMmNvbnRyb2wtY29uZmlndXJhdGlvbi0wMSAgICAgICAgTWFyY2ggMjAwNiANCiAgICAg ICAgIA0KDQogICAgIDQuMi4yIE1lc3NhZ2UgRmxvdyAtIEdTTVAgbWFwcGluZyANCg0KICAgICBX aGVuIGEgRFNMIGxpbmUgaW5pdGlhbGx5IGNvbWVzIHVwIG9yIHJlc3luY2hyb25pemVzIHRvIGEg ZGlmZmVyZW50IA0KICAgICByYXRlLCB0aGUgRFNMQU0gZ2VuZXJhdGVzIGFuZCB0cmFuc21pdHMg YSBHU01QIFBPUlQgVVAgRVZFTlQgbWVzc2FnZSB0byAgICAgDQogICAgIHRoZSBCUkFTLiBUaGUg ZXh0ZW5zaW9uIGZpZWxkIGluIHRoZSBtZXNzYWdlIGNhcnJpZXMgdGhlIFRMVnMgY29udGFpbmlu ZyANCiAgICAgRFNMIGxpbmUgc3BlY2lmaWMgcGFyYW1ldGVycy4gT24gYSBsb3NzIG9mIHNpZ25h bCBvbiB0aGUgRFNMIGxpbmUsIGEgICAgDQogICAgIEdTTVAgUE9SVCBET1dOIG1lc3NhZ2UgaXMg Z2VuZXJhdGVkIGJ5IHRoZSBEU0xBTSB0byB0aGUgQlJBUy4gSW4gb3JkZXIgDQogICAgIHRvIHBy b3ZpZGUgZXhwZWN0ZWQgc2VydmljZSBsZXZlbCwgQlJBUyBuZWVkcyB0byBsZWFybiB0aGUgaW5p dGlhbCAgICAgDQogICAgIGF0dHJpYnV0ZXMgb2YgdGhlIERTTCBsaW5lIGJlZm9yZSB0aGUgc3Vi c2NyaWJlciBjYW4gbG9nIGluIGFuZCBhY2Nlc3MgDQogICAgIHRoZSBwcm92aXNpb25lZCBzZXJ2 aWNlcyBmb3IgdGhlIHN1YnNjcmliZXIuICANCg0KICAgICAgICAgDQoNCiAgICAgICAgICAgICAg ICAgPC0tLS0tIFBvcnQgVVAoRVZFTlQgTWVzc2FnZSkgIDwtLS0tLSBEU0wgIA0KICAgICAgICAg ICAgICAgICAgICAgIChkZWZhdWx0IGxpbmUgcGFyYW1ldGVycykgICAgICAgU2lnbmFsIA0KICAg ICAgICAgDQogICAgICAgIDEuICBCUkFTIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIERTTEFNIC0t LS0tLS0tLS0tIFJvdXRpbmcgLS0tLS0gU3Vic2NyaWJlciANCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdhdGV3YXkgICAgICAgICAg ICANCiAgICAgICAgIA0KICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgIDwtLS0tLSBQb3J0 IFVQIChFVkVOVCBNZXNzYWdlKSAgPC0tLS0tIERTTCAgDQogICAgICAgICAgICAgICAgICAgICAg ICh1cGRhdGVkIGxpbmUgcGFyYW1ldGVycykgICAgICAgUmVzeW5jaCANCiAgICAgICAgIDIuICBC UkFTIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIERTTEFNIC0tLS0tLS0tLS0tIFJvdXRpbmcgLS0t LS0tIFN1YnNjcmliZXIgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBHYXRld2F5IA0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQogICAgICAgICAgICAgICAgPC0tLSBQb3J0 IERPV04gKEVWRU5UIE1lc3NhZ2UpIDwtLS0tIERTTCAgDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBMb3NzIG9mIFNpZ25hbCAgDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAzLiAg QlJBUyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tIERTTEFNIC0tLS0tLS0tLS0tLS0gUm91dGluZyAt LS0tLSBTdWJzY3JpYmVyICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHYXRld2F5IA0KDQogICAgICAgICAg ICAgICAgRmlnIDIuIE1lc3NhZ2UgZmxvdyAoR1NNUCBtYXBwaW5nKSBmb3IgdG9wb2xvZ3kgZGlz Y292ZXJ5ICAgICAgDQogICAgICAgICANCg0KICAgICAgICAgDQoNCiAgICAgICAgVGhlIEV2ZW50 IG1lc3NhZ2Ugd2l0aCBQT1JUIFVQIG1lc3NhZ2UgdHlwZSAoODApIGlzIHVzZWQgZm9yIA0KICAg ICAgICBjb252ZXlpbmcgRFNMIGxpbmUgYXR0cmlidXRlcyB0byB0aGUgQlJBUy4gVGhlIGZvcm1h dCBvZiBleHRlbnNpb25zIA0KICAgICAgICB0byB0aGUgbWVzc2FnZSBpcyBkZWZpbmVkIGluIHNl Y3Rpb24gNS40LjEuICAgIA0KDQogICAgICAgICAgICAgDQoNCg0KDQoNCiAgICAgIA0KICAgICAg DQogICAgIFdhZGh3YSBldC5hbCAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAyOCwgMjAwNiAg ICAgICAgICAgICAgIFtQYWdlIDldIA0KICAgICAgICAgDQoMICAgICBJbnRlcm5ldC1EcmFmdCAg ICAgIGRyYWZ0LXdhZGh3YS1nc21wLWwyY29udHJvbC1jb25maWd1cmF0aW9uLTAxICAgICAgICBN YXJjaCAyMDA2IA0KICAgICAgICAgDQoNCiAgICAgNC4zIExheWVyMiBjb250cm9sIGZvciBMaW5l IENvbmZpZ3VyYXRpb24gDQoNCiAgICAgNC4zLjEgR29hbHMgDQoNCiAgICAgICAgRm9sbG93aW5n IGR5bmFtaWMgZGlzY292ZXJ5IG9mIGFjY2VzcyB0b3BvbG9neSAoaWRlbnRpZmljYXRpb24gb2Yg RFNMIA0KICAgICAgICBsaW5lIGFuZCBpdCdzIGF0dHJpYnV0ZXMpIGFzIGFzc2lzdGVkIGJ5IHRo ZSBtZWNoYW5pc20gZGVzY3JpYmVkICAgIA0KICAgICAgICBpbiB0aGUgcHJldmlvdXMgc2VjdGlv biAodG9wb2xvZ3kgZGlzY292ZXJ5KSwgdGhlIEJSQVMgY291bGQgdGhlbiANCiAgICAgICAgcXVl cnkgYSBzdWJzY3JpYmVyIG1hbmFnZW1lbnQgT1NTIHN5c3RlbSAoZS5nLiBSQURJVVMgc2VydmVy KSB0byAgICAgDQogICAgICAgIHJldHJpZXZlIHN1YnNjcmliZXIgYXV0aG9yaXphdGlvbiBkYXRh IChzZXJ2aWNlIHByb2ZpbGVzLCBha2EgdXNlciANCiAgICAgICAgZW50aXRsZW1lbnQpLiBNb3N0 IG9mIHN1Y2ggc2VydmljZSBtZWNoYW5pc21zIGFyZSB0eXBpY2FsbHkgZW5mb3JjZWQgICAgIA0K ICAgICAgICBieSB0aGUgQlJBUyBpdHNlbGYsIGJ1dCB0aGVyZSBhcmUgYSBmZXcgY2FzZXMgd2hl cmUgaXQgbWlnaHQgYmUgDQogICAgICAgIHVzZWZ1bCB0byBwdXNoIHN1Y2ggc2VydmljZSBwYXJh bWV0ZXIgdG8gdGhlIERTTEFNIGZvciBsb2NhbCANCiAgICAgICAgZW5mb3JjZW1lbnQgb2YgYSBt ZWNoYW5pc20gKGUuZy4gRFNMLXJlbGF0ZWQpIG9uIHRoZSBjb3JyZXNwb25kaW5nIA0KICAgICAg ICBzdWJzY3JpYmVyIGxpbmUuIE9uZSBzdWNoIGV4YW1wbGUgb2YgYSBzZXJ2aWNlIHBhcmFtZXRl ciB0aGF0IGNhbiBiZSANCiAgICAgICAgcHVzaGVkIHRvIHRoZSBEU0xBTSBmb3IgbG9jYWwgZW5m b3JjZW1lbnQgaXMgRFNMICJpbnRlcmxlYXZpbmcgDQogICAgICAgIGRlbGF5Ii4gTG9uZ2VyIGlu dGVybGVhdmluZyBkZWxheSAoYW5kIGhlbmNlIHN0cmluZ2VudCBlcnJvciANCiAgICAgICAgY29y cmVjdGlvbikgaXMgcmVxdWlyZWQgZm9yIGEgdmlkZW8gc2VydmljZSB0byBlbnN1cmUgYmV0dGVy IHZpZGVvIA0KICAgICAgICAicXVhbGl0eSBvZiBleHBlcmllbmNlIiwgd2hlcmVhcyBmb3IgYSBW b0lQIHNlcnZpY2Ugb3IgZm9yICJzaG9vdCANCiAgICAgICAgZmlyc3QiIGdhbWluZyBzZXJ2aWNl LCBhIHZlcnkgc2hvcnQgaW50ZXJsZWF2aW5nIGRlbGF5IGlzIG1vcmUgDQogICAgICAgIGFwcHJv cHJpYXRlLiBBbm90aGVyIHJlbGV2YW50IGFwcGxpY2F0aW9uIGlzIGRvd25sb2FkaW5nIHBlciAN CiAgICAgICAgc3Vic2NyaWJlciBtdWx0aWNhc3QgY2hhbm5lbCBlbnRpdGxlbWVudCBpbmZvcm1h dGlvbiBpbiBJUFRWIA0KICAgICAgICBhcHBsaWNhdGlvbnMgd2hlcmUgdGhlIERTTEFNIGlzIHBl cmZvcm1pbmcgSUdNUCBzbm9vcGluZyBvciBJR01QIA0KICAgICAgICBwcm94eSBmdW5jdGlvbi4g VXNpbmcgR1NNUCwgdGhlIEJSQVMgY291bGQgYWNoaWV2ZSB0aGUgZ29hbCBvZiANCiAgICAgICAg cHVzaGluZyBsaW5lIGNvbmZpZ3VyYXRpb24gdG8gdGhlIERTTEFNIGJ5IGFuIGludGVyb3BlcmFi bGUgYW5kIA0KICAgICAgICBzdGFuZGFyZGl6ZWQgcHJvdG9jb2wuICANCg0KICAgICAgICBJZiBh IHN1YnNjcmliZXIgd2FudHMgdG8gY2hvb3NlIGEgZGlmZmVyZW50IHNlcnZpY2UsIGl0IGNhbiBy ZXF1aXJlIA0KICAgICAgICBhbiBPUEVYIGludGVuc2l2ZSByZWNvbmZpZ3VyYXRpb24gb2YgdGhl IGxpbmUgdmlhIGEgbmV0d29yayBvcGVyYXRvciwgDQogICAgICAgIHBvc3NpYmx5IGltcGx5aW5n IGEgYnVzaW5lc3MtdG8tYnVzaW5lc3MgdHJhbnNhY3Rpb24gYmV0d2VlbiBhbiBJU1AgDQogICAg ICAgIGFuZCBhbiBhY2Nlc3MgcHJvdmlkZXIuIFVzaW5nIEwyQyBmb3IgbGluZSBjb25maWd1cmF0 aW9uIGZyb20gdGhlIA0KICAgICAgICBCUkFTIGRyYW1hdGljYWxseSBzaW1wbGlmaWVzIHRoZSBP U1MgaW5mcmFzdHJ1Y3R1cmUgZm9yIHNlcnZpY2UgDQogICAgICAgIG1hbmFnZW1lbnQsIGFsbG93 aW5nIGZ1bGx5IGNlbnRyYWxpemVkIHN1YnNjcmliZXItcmVsYXRlZCBzZXJ2aWNlIA0KICAgICAg ICBkYXRhIChlLmcuIFJBRElVUyBzZXJ2ZXIgYmFjay1lbmQpIGFuZCBhdm9pZGluZyBjb21wbGV4 IGNyb3NzLQ0KICAgICAgICBvcmdhbml6YXRpb24gQjJCIGludGVyYWN0aW9ucy4gIA0KDQogICAg ICAgIFRoZXJlZm9yZSwgcHJvcG9zZWQgR1NNUCBiYXNlZCBsaW5lIGNvbmZpZ3VyYXRpb24gc3Vw cG9ydCBwcm92aWRlcyANCiAgICAgICAgZm9yIG1vcmUgZmxleGlibGUgYXBwcm9hY2ggZm9yIGFj aGlldmluZyAic2VydmljZSBvbiBkZW1hbmQiLiBNb3JlIA0KICAgICAgICBnZW5lcmFsbHkgc2V2 ZXJhbCBzZXJ2aWNlL3N1YnNjcmliZXIgRFNMIHBhcmFtZXRlcnMgKGUuZy4gaW50ZXItDQogICAg ICAgIGxlYXZpbmcgZGVsYXksIHJhdGUgZXRjLikgY291bGQgYmVuZWZpdCBmcm9tIHN1Y2ggZmxl eGlibGUgYXBwcm9hY2ggDQogICAgICAgIHRvIGVuYWJsZSBhICJzZXJ2aWNlIG9uIGRlbWFuZCIg bW9kZWwuICANCg0KICAgICAgICBUaGUgYmVzdCB3YXkgdG8gY2hhbmdlIGxpbmUgcGFyYW1ldGVy cyB3b3VsZCBiZSBieSB1c2luZyBwcm9maWxlcy4gDQogICAgICAgIFRoZXNlIHByb2ZpbGVzIChE U0wgcHJvZmlsZXMgZm9yIGRpZmZlcmVudCBzZXJ2aWNlcykgYXJlIHByZS0NCiAgICAgICAgY29u ZmlndXJlZCBvbiB0aGUgRFNMQU1zLiBUaGUgQlJBUyBjYW4gdGhlbiBpbmRpY2F0ZSBhIHJlZmVy ZW5jZSB0byANCiAgICAgICAgdGhlIHJpZ2h0IERTTCBwcm9maWxlIHZpYSBHU01QLiBBbHRlcm5h dGl2ZWx5LCBkaXNjcmV0ZSBEU0wgDQogICAgICAgIHBhcmFtZXRlcnMgY2FuIGFsc28gYmUgY29u dmV5ZWQgYnkgdGhlIEJSQVMgaW4gR1NNUC4gDQoNCiAgICAgIA0KICAgICAgDQogICAgIFdhZGh3 YSBldC5hbCAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAyOCwgMjAwNiAgICAgICAgICAgICAg W1BhZ2UgMTBdIA0KICAgICAgICAgDQoMICAgICBJbnRlcm5ldC1EcmFmdCAgICAgIGRyYWZ0LXdh ZGh3YS1nc21wLWwyY29udHJvbC1jb25maWd1cmF0aW9uLTAxICAgICAgICBNYXJjaCAyMDA2IA0K ICAgICAgICAgDQoNCiAgICAgICAgIA0KDQogICAgIDQuMy4yIE1lc3NhZ2UgRmxvdyAtIEdTTVAg bWFwcGluZyANCg0KICAgICBUcmlnZ2VyZWQgYnkgdG9wb2xvZ3kgaW5mb3JtYXRpb24gcmVwb3J0 aW5nIGEgbmV3IERTTCBsaW5lIG9yIHRyaWdnZXJlZCANCiAgICAgYnkgYSBzdWJzZXF1ZW50IHVz ZXIgc2Vzc2lvbiBlc3RhYmxpc2htZW50IChQUFAgb3IgREhDUCksIHRoZSBCUkFTIG1heSANCiAg ICAgc2VuZCBsaW5lIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gKGUuZy4gcmVmZXJlbmNlIHRv IGEgRFNMIHByb2ZpbGUpIHRvIA0KICAgICB0aGUgRFNMQU0gdXNpbmcgUG9ydCBNYW5hZ2VtZW50 IG1lc3NhZ2VzLiBUaGUgQlJBUyBtYXkgZ2V0IHN1Y2ggbGluZSAgICAgDQogICAgIGNvbmZpZ3Vy YXRpb24gZGF0YSBmcm9tIGEgcG9saWN5IHNlcnZlciAoZS5nLiBSQURJVVMpLiBGaWd1cmUgMyAN CiAgICAgc3VtbWFyaXplcyB0aGUgaW50ZXJhY3Rpb24uICAgIA0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCiAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgMS5EU0wgU2lnbmFsIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDwtLS0tLS0tLS0tLSANCiAgICAgICAgICAgICAgICAgICAgICAyLiBQ b3J0IFVQIChFVkVOVCBNZXNzYWdlKSANCiAgICAgICAgICAgICAgICAgICAgICAgICAoQWNjZXNz IFRvcG9sb2d5IERpc2NvdmVyeSkgDQogICAgICAgICAgICAgICAgICAgICAgIDwtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgMy4gUFBQL0RIQ1AgU2Vzc2lvbiANCiAgICAgICAg ICAgICAgICAgICAgICAgICA8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0gDQogICAgICAgNC4gQXV0aG9yaXphdGlvbiANCiAgICAgICAgICYgQXV0 aGVudGljYXRpb24gDQogICAgICAgPC0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICAgICAgICAgICAg ICAgICAgICAgICAgUG9ydCBNYW5hZ2VtZW50IE1lc3NhZ2UgIA0KICAgICAgICAgICAgICAgICAg ICAgICAgIChMaW5lIENvbmZpZ3VyYXRpb24pIA0KICAgICAgICAgICAgICAgICAgICAgICA1LiAt LS0tLS0tLS0tLS0tLS0tPiANCiAgICAgKy0tLS0tLS0tLS0tLS0rICAgICAgKy0tLS0tKyAgICAg ICAgICstLS0tLS0tKyAgICAgICArLS0tLS0tLS0tLSsgICAgICAgKy0tLS0tLS0tLS0tKyAgICAg ICAgICAgIA0KICAgICB8UmFkaXVzL0FBQSAgICB8LS0tLS0tfEJSQVMgfC0tLS0tLS0tLXwgRFNM QU0gfC0tLS0tLSB8IFJvdXRpbmcgIHwtLS0tLS0gfFN1YnNjcmliZXIgfCAgICANCiAgICAgfFBv bGljeSBTZXJ2ZXJ8ICAgICAgKy0tLS0tKyAgICAgICAgICstLS0tLS0tKyAgICAgICB8IEdhdGV3 YXkgIHwgICAgICAgKy0tLS0tLS0tLS0tKyAgICAgICAgICAgIA0KICAgICArLS0tLS0tLS0tLS0t LSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tKyAgICAg ICAgDQogICAgICAgDQogICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgRmlnIDMuIE1lc3Nh Z2UgZmxvdyAtIEdTTVAgbWFwcGluZyBmb3IgSW5pdGlhbCBMaW5lIENvbmZpZ3VyYXRpb24gDQog ICAgICAgICANCg0KICAgICBUaGUgQlJBUyBtYXkgdXBkYXRlIHRoZSBsaW5lIGNvbmZpZ3VyYXRp b24gZHVlIHRvIGEgc3Vic2NyaWJlciBzZXJ2aWNlIA0KICAgICBjaGFuZ2UgKGUuZy4gdHJpZ2dl cmVkIGJ5IHRoZSBwb2xpY3kgc2VydmVyKS4gRmlndXJlIDQgc3VtbWFyaXplcyB0aGUgDQogICAg IGludGVyYWN0aW9uLiANCg0KDQoNCg0KDQoNCg0KDQogICAgICANCiAgICAgIA0KICAgICBXYWRo d2EgZXQuYWwgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjgsIDIwMDYgICAgICAgICAgICAg IFtQYWdlIDExXSANCiAgICAgICAgIA0KDCAgICAgSW50ZXJuZXQtRHJhZnQgICAgICBkcmFmdC13 YWRod2EtZ3NtcC1sMmNvbnRyb2wtY29uZmlndXJhdGlvbi0wMSAgICAgICAgTWFyY2ggMjAwNiAN CiAgICAgICAgIA0KDQogICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEuIFBQUC9ESENQIFNlc3Npb24gDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAr LS0tLS0tLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAyLiBTZXJ2aWNlIE9uIERlbWFu ZCANCiAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfDwtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICAgICAgICAgICAgICAgICAgICB8 IFdlYiBwb3J0YWwgIHwgDQogICAgICAgICAgICAgICAgICAgICB8ICBPU1MgZXRjICAgIHwgMy5D aGFuZ2Ugb2YgICA0LlBvcnQgTWFuYWdlbWVudCANCiAgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgfCBBdXRob3JpemF0aW9uICAgTWVzc2FnZSAgDQogICAgICAgICAgICAgICAgICAg ICB8IFJhZGl1cyBBQUEgIHwgLS0tLS0tLS0+ICAgICAoVXBkYXRlZCBMaW5lICANCiAgICAgICAg ICAgICAgICAgICAgIHwgIFBvbGljeSAgICAgfCAgICAgICAgICAgICAgICBDb25maWcgLSBOZXcg UHJvZmlsZSkgDQogICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAg LS0tLS0tLS0tLS0tLS4gIA0KICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAg ICstLS0tLS0rICAgICArLS0tLS0tLSsgICArLS0tLS0tLS0tKyAgKy0tLS0tLS0tLS0rICAgICAg ICAgICANCiAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfC0tLS18IEJSQVMgfC0t LS0tfCBEU0xBTSB8LS0tfCBSb3V0aW5nIHwtLXxTdWJzY3JpYmVyfCANCiAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgfCAgICArLS0tLS0tKyAgICAgKy0tLS0tLS0rICAgfCBHYXRl d2F5IHwgICstLS0tLS0tLS0tKyAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICArLS0t LS0tLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0rICAgDQog ICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgIEZpZyA0LiBNZXNzYWdlIGZsb3cgLSBHU01Q IG1hcHBpbmcgZm9yIFVwZGF0ZWQgTGluZSBDb25maWd1cmF0aW9uIA0KICAgICAgICAgDQogICAg ICANCg0KICAgICAgICBUaGUgZm9ybWF0IG9mIGV4dGVuc2lvbnMgdG8gcG9ydCBtYW5hZ2VtZW50 IG1lc3NhZ2UgaXMgZGVmaW5lZCBpbiANCiAgICAgICAgc2VjdGlvbiA1LjQuMi4gVGhlIGxpbmUg Y29uZmlndXJhdGlvbiBtb2RlbHMgY291bGQgYmUgdmlld2VkIGFzIGEgDQogICAgICAgIGZvcm0g b2YgZGVsZWdhdGlvbiBvZiBhdXRob3JpemF0aW9uIGZyb20gdGhlIEJSQVMgdG8gdGhlIERTTEFN LiANCg0KICAgDQoNCiAgICAgNC40IExheWVyMiBDb250cm9sIGZvciBUcmFuc2FjdGlvbmFsIE11 bHRpY2FzdCANCg0KICAgICAgICBUeXBpY2FsIElQIG11bHRpY2FzdCBpbiBhY2Nlc3MgbmV0d29y a3MgaW52b2x2ZXMgdGhlIEJSQVMgdGVybWluYXRpbmcgDQogICAgICAgIHVzZXIgcmVxdWVzdHMg Zm9yIHJlY2VpdmluZyBtdWx0aWNhc3QgY2hhbm5lbHMgdmlhIElHTVAuIFRoZSBCUkFTIA0KICAg ICAgICBhdXRob3JpemVzIHRoZSBzdWJzY3JpYmVyLCBhbmQgZHluYW1pY2FsbHkgZGV0ZXJtaW5l cyB0aGUgbXVsdGljYXN0IA0KICAgICAgICBzdWJzY3JpcHRpb24gcmlnaHRzIGZvciB0aGUgc3Vi c2NyaWJlci4gQmFzZWQgb24gdGhlIHVzZXIncyANCiAgICAgICAgc3Vic2NyaXB0aW9uLCB0aGUg QlJBUyBjYW4gcmVwbGljYXRlIHRoZSBzYW1lIG11bHRpY2FzdCBzdHJlYW0gdG8gDQogICAgICAg IG11bHRpcGxlIHN1YnNjcmliZXJzLiBUaGlzIGxlYWRzIHRvIGEgd2FzdGUgb2YgYWNjZXNzIGJh bmR3aWR0aCBpZiANCiAgICAgICAgbXVsdGlwbGUgc3Vic2NyaWJlcnMgYWNjZXNzIG5ldHdvcmsg c2VydmljZXMgdmlhIHRoZSBzYW1lIGFjY2Vzcy1ub2RlIA0KICAgICAgICAoZS5nLiBEU0xBTSku IFRoZSBhbW91bnQgb2YgbXVsdGljYXN0IHJlcGxpY2F0aW9uIGlzIG9mIHRoZSBvcmRlciBvZiAN CiAgICAgICAgbnVtYmVyIG9mIHN1YnNjcmliZXJzIHJhdGhlciB0aGFuIHRoZSBudW1iZXIgb2Yg YWNjZXNzLW5vZGVzLiANCg0KICAgICAgICBJdCBpcyBpZGVhbCBmb3IgQlJBUyB0byBzZW5kIGEg c2luZ2xlIGNvcHkgb2YgdGhlIG11bHRpY2FzdCBzdHJlYW0gdG8gDQogICAgICAgIGEgZ2l2ZW4g YWNjZXNzLW5vZGUsIGFuZCBsZXQgdGhlIGFjY2Vzcy1ub2RlIHBlcmZvcm0gbXVsdGljYXN0IA0K ICAgICAgICByZXBsaWNhdGlvbiAgIGJ5IGxheWVyMiBtZWFucyAoZS5nLiBBVE0gcG9pbnQtdG8t bXVsdGlwb2ludCBjZWxsIA0KICAgICAgICByZXBsaWNhdGlvbiBvciBldGhlcm5ldCBkYXRhLWxp bmsgYnJpZGdpbmcpIGZvciBzdWJzY3JpYmVycyBiZWhpbmQgDQogICAgICAgIHRoZSBhY2Nlc3Mt bm9kZS4gSG93ZXZlciwgb3BlcmF0aW9uYWxseSwgQlJBUyBpcyB0aGUgaWRlYWwgY2hvaWNlIHRv IA0KICAgICAgICBoYW5kbGUgc3Vic2NyaWJlciBtYW5hZ2VtZW50IGZ1bmN0aW9ucyAoYXV0aGVu dGljYXRpb24sIA0KICAgICAgICBhdXRob3JpemF0aW9uLCBhY2NvdW50aW5nIGFuZCBhZGRyZXNz IG1hbmFnZW1lbnQpLCBtdWx0aWNhc3QgcG9saWNpZXMgDQogICAgICAgIHN1Y2ggYXMgcGVyLWNo YW5uZWwgYXV0aG9yaXphdGlvbiwgYW5kIGNvbXBsZXggbXVsdGljYXN0IHJvdXRpbmcgDQogICAg ICANCiAgICAgIA0KICAgICBXYWRod2EgZXQuYWwgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIg MjgsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDEyXSANCiAgICAgICAgIA0KDCAgICAgSW50ZXJu ZXQtRHJhZnQgICAgICBkcmFmdC13YWRod2EtZ3NtcC1sMmNvbnRyb2wtY29uZmlndXJhdGlvbi0w MSAgICAgICAgTWFyY2ggMjAwNiANCiAgICAgICAgIA0KDQogICAgICAgIHByb3RvY29scy4gVGhl cmVmb3JlLCBzb21lIG1lYW5zIGlzIG5lZWRlZCBmb3IgdGhlIEJSQVMgdG8gc2V0dXAgDQogICAg ICAgIG11bHRpY2FzdCByZXBsaWNhdGlvbiBzdGF0ZSBpbiB0aGUgYWNjZXNzLW5vZGVzLiBJbiBB VE0gYWNjZXNzIA0KICAgICAgICBuZXR3b3JrcywgTGF5ZXIyIGNvbnRyb2wgcHJvdG9jb2wgY2Fu IGJlIHVzZWQgYnkgdGhlIEJSQVMgdG8gc2V0dXAgDQogICAgICAgIFAyTVAgY3Jvc3MtY29ubmVj dHMgaW4gdGhlIERTTEFNcy4gR1NNUHYzIGV4dGVuc2lvbnMgZm9yIHRoaXMgdXNlLQ0KICAgICAg ICBjYXNlIG9mIGxheWVyMiBjb250cm9sIHByb3RvY29sIHdpbGwgYmUgcHJvdmlkZWQgaW4gYSBz ZXBhcmF0ZSBJRCANCiAgICAgICAgWzZdLiANCg0KICAgICAgDQoNCiAgICAgNC41IExheWVyMiBP QU0gDQoNCiAgICAgICAgSW4gY2FzZSBvZiBhbiBBVE0gYmFzZWQgYWNjZXNzIGFnZ3JlZ2F0aW9u IG5ldHdvcmsgYW5kIGFuIEFUTSBiYXNlZCANCiAgICAgICAgbG9jYWwgbG9vcCwgZW5kLXRvLWVu ZCBBVE0gT0FNIGNhbiBiZSB1c2VkIGZvciBvbi1kZW1hbmQgY29ubmVjdGl2aXR5IA0KICAgICAg ICB0ZXN0aW5nLCBtb25pdG9yaW5nIGFuZCBmYXVsdCBsb2NhbGl6YXRpb24uIEhvd2V2ZXIsIGlu IGNhc2UgdGhlIA0KICAgICAgICBhZ2dyZWdhdGlvbiBuZXR3b3JrIGJldHdlZW4gdGhlIEJSQVMg YW5kIGFjY2Vzcy1ub2RlIGlzIGV0aGVybmV0IA0KICAgICAgICBiYXNlZCwgZW5kLXRvLWVuZCBB VE0gT0FNIHRlc3QgY2FuIG5vdCBiZSB1c2VkLiBJZGVhbGx5IGluIEV0aGVybmV0IA0KICAgICAg ICBiYXNlZCBhZ2dyZWdhdGlvbiwgZW5kLXRvLWVuZCBldGhlcm5ldCBPQU0gYXMgc3BlY2lmaWVk IGJ5IElUVSBhbmQgDQogICAgICAgIElFRUUgKDgwMS5hZyAvIFkuMTcgZXRob2FtKSBjYW4gcHJv dmlkZSBhY2Nlc3MtbGluZSBjb25uZWN0aXZpdHkgDQogICAgICAgIHRlc3RpbmcgYW5kIGZhdWx0 IGlzb2xhdGlvbi4gSG93ZXZlciwgbW9zdCBEU0wgbW9kZW1zIGRvIG5vdCB5ZXQgDQogICAgICAg IHN1cHBvcnQgdGhlc2Ugc3RhbmRhcmQgZXRoZXJuZXQgT0FNIHByb2NlZHVyZXMuIEFsc28sIHZh cmlvdXMgDQogICAgICAgIHRlY2hub2xvZ2llcyBleGlzdCBpbiB0aGUgYWNjZXNzIG5ldHdvcmsg LSBBVE0sIEVGTSAoZXRoZXJuZXQgaW4gdGhlIA0KICAgICAgICBmaXJzdCBtaWxlLCBzdGFuZGFy ZGl6ZWQgaW4gSUVFRSA4MDIuM2FoKSwgR1BPTiBldGMuIFRoZXNlIA0KICAgICAgICB0ZWNobm9s b2dpZXMgaGF2ZSB0aGVpciBvd24gbGluay1iYXNlZCBPQU0gbWVjaGFuaXNtcyB0aGF0IGhhdmUg YmVlbiANCiAgICAgICAgc3RhbmRhcmRpemVkIG9yIGFyZSB1bmRlciBzdGFuZGFyZGl6YXRpb24g aW4gZGlmZmVyZW50IHN0YW5kYXJkIA0KICAgICAgICBib2RpZXMuIEludGVyLXdvcmtpbmcgYmV0 d2VlbiA4MDIuMWFnIGFuZCBkaWZmZXJlbnQgbGluay1PQU0gDQogICAgICAgIG1lY2hhbmlzbXMg YXJlIGEgd29yayBpbiBwcm9ncmVzcyBhbmQgYXJlIGJlaW5nIGV2YWx1YXRlZCBvbiBhIGNhc2Ug DQogICAgICAgIGJ5IGNhc2UgYmFzaXMuIA0KDQogICAgICAgIEhvd2V2ZXIsIGEgc2ltcGxlIHNv bHV0aW9uIGJhc2VkIG9uIEwyQyBjYW4gcHJvdmlkZSBCUkFTIHdpdGggYW4gDQogICAgICAgIGFj Y2Vzcy1saW5lIHRlc3QgY2FwYWJpbGl0eSBhbmQgdG8gc29tZSBleHRlbnQgZmF1bHQgaXNvbGF0 aW9uLiANCiAgICAgICAgQ29udHJvbGxlZCBieSBhIGxvY2FsIG1hbmFnZW1lbnQgaW50ZXJmYWNl IHRoZSBCUkFTIGNhbiB1c2UgYW4gTDJDIA0KICAgICAgICBvcGVyYXRpb24gdG8gdHJpZ2dlciB0 aGUgYWNjZXNzLW5vZGUgdG8gcGVyZm9ybSBhIGxvb3BiYWNrIHRlc3Qgb24gDQogICAgICAgIHRo ZSBsb2NhbC1sb29wIChiZXR3ZWVuIHRoZSBhY2Nlc3Mtbm9kZSBhbmQgdGhlIENQRSkuIFRoZSBh Y2Nlc3Mtbm9kZSANCiAgICAgICAgY2FuIHJlc3BvbmQgdmlhIGFub3RoZXIgTDJDIG9wZXJhdGlv biB0aGUgcmVzdWx0IG9mIHRoZSB0cmlnZ2VyZWQgDQogICAgICAgIGxvb3BiYWNrIHRlc3QuIElu IGNhc2Ugb2YgQVRNIGJhc2VkIGxvY2FsLWxvb3AgdGhlIEwyQyBvcGVyYXRpb24gY2FuIA0KICAg ICAgICB0cmlnZ2VyIHRoZSBhY2Nlc3Mtbm9kZSB0byBnZW5lcmF0ZSBBVE0gKEY0L0Y1KSBsb29w YmFjayBjZWxscyBvbiB0aGUgDQogICAgICAgIGxvY2FsIGxvb3AuIEluIGNhc2Ugb2YgRXRoZXJu ZXQsIHRoZSBhY2Nlc3Mtbm9kZSBjYW4gdHJpZ2dlciBhbiANCiAgICAgICAgZXRoZXJuZXQgbG9v cGJhY2sgbWVzc2FnZXMocGVyIEVGTSBPQU0pIG9uIHRoZSBsb2NhbC1sb29wLiANCg0KICAgICA0 LjUuMSBNZXNzYWdlIEZsb3cgLSBHU01QIG1hcHBpbmcgDQoNCiAgICAgICAgR1NNUCAiUG9ydCBN YW5hZ2VtZW50IiBtZXNzYWdlIGNhbiBiZSB1c2VkIGJ5IHRoZSBCUkFTIHRvIHJlcXVlc3QgDQog ICAgICAgIGFjY2VzcyBub2RlIHRvIHRyaWdnZXIgYSAicmVtb3RlIGxvb3BiYWNrIiB0ZXN0IG9u IHRoZSBsb2NhbCBsb29wLiANCiAgICAgICAgVGhlIHJlc3VsdCBvZiB0aGUgbG9vcGJhY2sgdGVz dCBjYW4gYmUgYXN5bmNocm9ub3VzbHkgY29udmV5ZWQgYnkgdGhlIA0KICAgICAgICBhY2Nlc3Mg bm9kZSB0byB0aGUgQlJBUyBpbiBhICJQb3J0IE1hbmFnZW1lbnQiIHJlc3BvbnNlIG1lc3NhZ2Uu IA0KDQoNCiAgICAgIA0KICAgICAgDQogICAgIFdhZGh3YSBldC5hbCAgICAgICAgICBFeHBpcmVz IFNlcHRlbWJlciAyOCwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgMTNdIA0KICAgICAgICAgDQoM ICAgICBJbnRlcm5ldC1EcmFmdCAgICAgIGRyYWZ0LXdhZGh3YS1nc21wLWwyY29udHJvbC1jb25m aWd1cmF0aW9uLTAxICAgICAgICBNYXJjaCAyMDA2IA0KICAgICAgICAgDQoNCiAgICAgIA0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgUG9ydCBNYW5hZ2VtZW50IE1lc3NhZ2UgIA0KICAgICAg ICAgICAgICAgICAgICAgICAgIChSZW1vdGUgTG9vcGJhY2sgICAgICAgICAgQVRNIGxvb3BiYWNr ICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgVHJpZ2dlciBSZXF1ZXN0KSAgICAgICAgIE9S IEVGTSBMb29wYmFjayANCiAgICAgICAgICAgICAgICAgICAgICAgMS4gIC0tLS0tLS0tLS0tLS0t LS0+ICAgICAyLiAtLS0tLS0tLS0tPiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8LS0tLS0tLS0tKyANCiAgICAgKy0tLS0tLS0tLS0tLS0rICAg ICAgKy0tLS0tKyAgICAgICAgICstLS0tLS0tKyAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0t LS0rICAgICAgICAgICAgICAgICAgIA0KICAgICB8UmFkaXVzL0FBQSAgICB8LS0tLS0tfEJSQVMg fC0tLS0tLS0tLXwgRFNMQU0gfC0tLS0tLS0tLS0tLS18ICAgICBDUEUgICAgICAgICB8ICAgICAg IA0KICAgICB8UG9saWN5IFNlcnZlcnwgICAgICArLS0tLS0rICAgICAgICAgKy0tLS0tLS0rICAg ICAgICAgICAgIHwgIChEU0wgTW9kZW0gKyAgIHwgICAgICAgICAgICAgICAgICAgDQogICAgICst LS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCBSb3V0aW5nIEdhdGV3YXkpfCAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0t LS0tLS0tLS0rIA0KICAgICAgICAgICAgICAgICAgICAgICAgIDMuIDwtLS0tLS0tLS0tLS0tLS0g ICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICBQb3J0IE1hbmFn ZW1lbnQgTWVzc2FnZSANCiAgICAgICAgICAgICAgICAgICAgICAgKFJlbW90ZSBMb29wYmFjayBU ZXN0IFJlc3BvbnNlKSANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAg DQogICAgICAgICANCiAgICAgICAgIA0KICAgICAgICAgDQogICAgICAgICANCiAgICAgNSAgR1NN UCBmb3IgTGF5ZXIyIENvbnRyb2wgUHJvdG9jb2wgDQoNCiAgICAgNS4xIEdTTVAvVENQIGNvbm5l Y3Rpb24gZXN0YWJsaXNobWVudCANCg0KICAgICAgICBUaGUgTDIgY29udHJvbCBwcm90b2NvbCB3 aWxsIHVzZSBUQ1AgZm9yIGV4Y2hhbmdpbmcgR1NNUCBwcm90b2NvbCANCiAgICAgICAgbWVzc2Fn ZXMuIFs1XSBkZWZpbmVzIHRoZSBHU01QIG1lc3NhZ2UgZW5jYXBzdWxhdGlvbiBmb3IgVENQLiBU aGUgVENQICAgDQogICAgICAgIHNlc3Npb24gaXMgaW5pdGlhdGVkIGZyb20gdGhlIERTTEFNIChh Y2Nlc3Mgbm9kZSkgdG8gdGhlIEJSQVMgDQogICAgICAgIChjb250cm9sbGVyKS4gVGhpcyBpcyBu ZWNlc3NhcnkgdG8gYXZvaWQgc3RhdGljIHByb3Zpc2lvbmluZyBvbiB0aGUgDQogICAgICAgIEJS QVMgZm9yIGFsbCB0aGUgRFNMQU1zIHRoYXQgYXJlIGJlaW5nIHNlcnZlZCBieSB0aGUgQlJBUy4g SXQgaXMgDQogICAgICAgIGVhc2llciB0byBjb25maWd1cmUgYSBnaXZlbiBEU0xBTSB3aXRoIHRo ZSBzaW5nbGUgaXAgYWRkcmVzcyBvZiB0aGUgDQogICAgICAgIEJSQVMgdGhhdCBzZXJ2ZXMgdGhl IERTTEFNLiBUaGlzIGlzIGEgZGV2aWF0aW9uIGZyb20gWzVdIHdoaWNoIA0KICAgICAgICBpbmRp Y2F0ZXMgdGhhdCB0aGUgY29udHJvbGxlciBpbml0aWF0ZXMgdGhlIFRDUCBjb25uZWN0aW9uIHRv IHRoZSANCiAgICAgICAgc3dpdGNoLiANCg0KICAgICAgICBCUkFTIGxpc3RlbnMgZm9yIGluY29t aW5nIGNvbm5lY3Rpb25zIGZyb20gdGhlIGFjY2VzcyBub2Rlcy4gUG9ydCANCiAgICAgICAgNjA2 OCBpcyB1c2VkIGZvciBUQ1AgY29ubmVjdGlvbi4gQWRqYWNlbmN5IHByb3RvY29sIG1lc3NhZ2Vz LCB3aGljaCANCiAgICAgICAgYXJlIHVzZWQgdG8gc3luY2hyb25pemUgdGhlIEJSQVMgYW5kIGFj Y2Vzcy1ub2RlcyBhbmQgbWFpbnRhaW4gDQogICAgICAgIGhhbmRzaGFrZXMsIGFyZSBzZW50IGFm dGVyIHRoZSBUQ1AgY29ubmVjdGlvbiBpcyBlc3RhYmxpc2hlZC4gR1NNUCANCiAgICAgICAgbWVz c2FnZXMgb3RoZXIgdGhhbiBhZGphY2VuY3kgcHJvdG9jb2wgbWVzc2FnZXMgbWF5IGJlIHNlbnQg b25seSANCiAgICAgICAgYWZ0ZXIgdGhlIGFkamFjZW5jeSBwcm90b2NvbCBoYXMgYWNoaWV2ZWQg c3luY2hyb25pemF0aW9uLiANCg0KICAgICAgICBJbiB0aGUgY2FzZSBvZiBBVE0gYWNjZXNzLCBh IHNlcGFyYXRlIFBWQyAoY29udHJvbCBjaGFubmVsKSBjYXBhYmxlIA0KICAgICAgICBvZiB0cmFu c3BvcnRpbmcgSVAgd291bGQgYmUgY29uZmlndXJlZCBiZXR3ZWVuIEJSQVMgYW5kIHRoZSBEU0xB TSBmb3IgICAgIA0KICAgICAgICBsYXllcjIgcHJvdG9jb2wgbWVzc2FnZXMuICANCg0KDQogICAg ICANCiAgICAgIA0KICAgICBXYWRod2EgZXQuYWwgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIg MjgsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDE0XSANCiAgICAgICAgIA0KDCAgICAgSW50ZXJu ZXQtRHJhZnQgICAgICBkcmFmdC13YWRod2EtZ3NtcC1sMmNvbnRyb2wtY29uZmlndXJhdGlvbi0w MSAgICAgICAgTWFyY2ggMjAwNiANCiAgICAgICAgIA0KDQogICAgIDUuMiBHU01QIGNvbm5lY3Rp b24ga2VlcC1hbGl2ZSANCg0KICAgICAgICBHU01QIGRlZmluZXMgYW4gYWRqYWNlbmN5IHByb3Rv Y29sLiAgVGhlIGFkamFjZW5jeSBwcm90b2NvbCBpcyB1c2VkIA0KICAgICAgICB0byBzeW5jaHJv bml6ZSBzdGF0ZXMgYWNyb3NzIHRoZSBsaW5rLCB0byBuZWdvdGlhdGUgd2hpY2ggdmVyc2lvbiBv ZiANCiAgICAgICAgdGhlIEdTTVAgcHJvdG9jb2wgdG8gdXNlLCB0byBkaXNjb3ZlciB0aGUgaWRl bnRpdHkgb2YgdGhlIGVudGl0eSBhdCANCiAgICAgICAgdGhlIG90aGVyIGVuZCBvZiBhIGxpbmss IGFuZCB0byBkZXRlY3Qgd2hlbiBpdCBjaGFuZ2VzLiBHU01QIGlzIGEgDQogICAgICAgIGhhcmQg ICAgIHN0YXRlIHByb3RvY29sLiAgSXQgaXMgdGhlcmVmb3JlIGltcG9ydGFudCB0byBkZXRlY3Qg bG9zcyBvZiANCiAgICAgICAgY29udGFjdCBiZXR3ZWVuIHN3aXRjaCBhbmQgY29udHJvbGxlciwg YW5kIHRvIGRldGVjdCBhbnkgY2hhbmdlIG9mIA0KICAgICAgICBpZGVudGl0eSAgICBvZiBzd2l0 Y2ggb3IgY29udHJvbGxlci4gTm8gR1NNUCBtZXNzYWdlcyBvdGhlciB0aGFuIA0KICAgICAgICB0 aG9zZSBvZiB0aGUgYWRqYWNlbmN5IHByb3RvY29sIG1heSBiZSBzZW50IGFjcm9zcyB0aGUgbGlu ayB1bnRpbCB0aGUgDQogICAgICAgIGFkamFjZW5jeSBwcm90b2NvbCBoYXMgYWNoaWV2ZWQgc3lu Y2hyb25pemF0aW9uLiBUaGVyZSBhcmUgbm8gY2hhbmdlcyANCiAgICAgICAgdG8gdGhlIGJhc2Ug R1NNUCBhZGphY2VuY3kgcHJvdG9jb2wgZm9yIGltcGxlbWVudGluZyBsYXllcjIgY29udHJvbC4g DQoNCiAgICAgICAgVGhlIEJSQVMgd2lsbCBzZXQgdGhlIE0tZmxhZyBpbiB0aGUgU1lOIG1lc3Nh Z2UgKHNpZ25pZnlpbmcgaXQgaXMgdGhlIA0KICAgICAgICBtYXN0ZXIpLiBPbmNlIHRoZSBhZGph Y2VuY3kgaXMgZXN0YWJsaXNoZWQsIHBlcmlvZGljIGFkamFjZW5jeSANCiAgICAgICAgbWVzc2Fn ZXMgICAgICh0eXBlIEFDSykgYXJlIGV4Y2hhbmdlZC4gVGhlIGRlZmF1bHQgQUNLIGludGVydmFs IGFzIA0KICAgICAgICBhZHZlcnRpc2VkIGluIHRoZSBhZGphY2VuY3kgbWVzc2FnZXMgaXMgMTAg c2VjIGZvciBsYXllcjIgY29udHJvbCANCiAgICAgICAgcHJvdG9jb2wuIEl0IFNIT1VMRCBiZSBj b25maWd1cmFibGUgYW5kIGlzIGFuIGltcGxlbWVudGF0aW9uIGNob2ljZS4gDQogICAgICAgIEl0 IGlzIHJlY29tbWVuZGVkIHRoYXQgYm90aCBlbmRzIHNwZWNpZnkgdGhlIHNhbWUgdGltZXIgdmFs dWUuIA0KICAgICAgICBIb3dldmVyLCBpdCBpcyBub3QgbmVjZXNzYXJ5IGZvciB0aGUgdGltZXIg dmFsdWVzIHRvIG1hdGNoLiANCg0KICAgICAgICBUaGUgYWRqYWNlbmN5IG1lc3NhZ2UgaXMgc2hv d24gaW4gdGhlIGZvbGxvd2luZyBzZWN0aW9uLiBUaGUgDQogICAgICAgIHNlbWFudGljcyBhbmQg c3VnZ2VzdGVkIHZhbHVlcyBmb3IgdmVyc2lvbiwgQ29kZSwgIlNlbmRlciBOYW1lIiwgDQogICAg ICAgICJSZWNlaXZlciBOYW1lIiwgIlNlbmRlciBJbnN0YW5jZSIsIGFuZCAiUmVjZWl2ZXIgSW5z dGFuY2UiIGZpZWxkcyANCiAgICAgICAgYXJlIGFzIGRlZmluZWQgaW4gWzRdLiBUaGUgIlNlbmRl ciBQb3J0IiwgYW5kICJSZWNlaXZlciBQb3J0IiBzaG91bGQgDQogICAgICAgIGJlIHNldCB0byAw IGJ5IGJvdGggZW5kcy4gVGhlIHBUeXBlIGZpZWxkIHNob3VsZCBiZSBzZXQgdG8gMC4gVGhlIA0K ICAgICAgICBwRmxhZyBzaG91bGQgYmUgc2V0IHRvIDEuIA0KDQogICAgICAgIElmIHRoZSBhZGph Y2VuY3kgdGltZXMgb3V0IG9uIGVpdGhlciBlbmQsIGR1ZSB0byBub3QgcmVjZWl2aW5nIGFuIA0K ICAgICAgICBhZGphY2VuY3kgbWVzc2FnZSBmb3IgYSBkdXJhdGlvbiBvZiAoMyAqIFRpbWVyIHZh bHVlKSwgd2hlcmUgdGhlIA0KICAgICAgICB0aW1lciB2YWx1ZSBpcyBzcGVjaWZpZWQgaW4gdGhl IGFkamFjZW5jeSBtZXNzYWdlLCBhbGwgdGhlIHN0YXRlIA0KICAgICAgICByZWNlaXZlZCBmcm9t IHRoZSBMMkMgbmVpZ2hib3Igc2hvdWxkIGJlIGNsZWFuZWQgdXAsIGFuZCB0aGUgVENQIA0KICAg ICAgICBjb25uZWN0aW9uIHNob3VsZCBiZSBjbG9zZWQuIFRoZSBCUkFTIHdvdWxkIGNvbnRpbnVl IHRvIGxpc3RlbiBmb3IgDQogICAgICAgIG5ldyBjb25uZWN0aW9uIHJlcXVlc3RzLiBUaGUgRFNM QU0gd2lsbCB0cnkgdG8gcmUtZXN0YWJsaXNoIHRoZSBUQ1AgDQogICAgICAgIGNvbm5lY3Rpb24g YW5kIGJvdGggc2lkZXMgd2lsbCBhdHRlbXB0IHRvIHJlLWVzdGFibGlzaCB0aGUgYWRqYWNlbmN5 LiANCg0KICAgICAgICBUaGUgaGFuZGxpbmcgZGVmaW5lZCBhYm92ZSB3aWxsIG5lZWQgc29tZSBt b2RpZmljYXRpb25zIHdoZW4gTDJDIA0KICAgICAgICBncmFjZWZ1bCByZXN0YXJ0IHByb2NlZHVy ZXMgYXJlIGRlZmluZWQuIFRoZXNlIHByb2NlZHVyZXMgYXJlIA0KICAgICAgICBjdXJyZW50bHkg bm90IGluIHNjb3BlIGFuZCB3aWxsIGJlIGRlZmluZWQgaW4gYSBzZXBhcmF0ZSBkcmFmdC4gDQoN CiAgICAgICAgICANCg0KICAgICA1LjMgQ2FwYWJpbGl0eSBuZWdvdGlhdGlvbiANCg0KICAgICAg ICBUaGUgR1NNUCBhZGphY2VuY3kgbWVzc2FnZSBpcyBleHRlbmRlZCB0byBjYXJyeSB0ZWNobm9s b2d5IHNwZWNpZmljIA0KICAgICAgICAiQ2FwYWJpbGl0eSBUTFZzIi4gQm90aCB0aGUgQlJBUyBh bmQgdGhlIGFjY2VzcyBub2RlIHdpbGwgYWR2ZXJ0aXNlIA0KICAgICAgICBzdXBwb3J0ZWQgY2Fw YWJpbGl0aWVzIGluIHRoZSBvcmlnaW5hdGVkIGFkamFjZW5jeSBtZXNzYWdlcy4gSWYgYSANCiAg ICAgIA0KICAgICAgDQogICAgIFdhZGh3YSBldC5hbCAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJl ciAyOCwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgMTVdIA0KICAgICAgICAgDQoMICAgICBJbnRl cm5ldC1EcmFmdCAgICAgIGRyYWZ0LXdhZGh3YS1nc21wLWwyY29udHJvbC1jb25maWd1cmF0aW9u LTAxICAgICAgICBNYXJjaCAyMDA2IA0KICAgICAgICAgDQoNCiAgICAgICAgcmVjZWl2ZWQgYWRq YWNlbmN5IG1lc3NhZ2UgaW5kaWNhdGVzIGFic2VuY2Ugb2Ygc3VwcG9ydCBmb3IgYSANCiAgICAg ICAgY2FwYWJpbGl0eSB0aGF0IGlzIHN1cHBvcnRlZCBieSB0aGUgcmVjZWl2aW5nIGRldmljZSwg aXQgd2lsbCB0dXJuIA0KICAgICAgICBvZmYgdGhlIGNhcGFiaWxpdHkgbG9jYWxseSBhbmQgd2ls bCBzZW5kIGFuIHVwZGF0ZWQgYWRqYWNlbmN5IG1lc3NhZ2UgDQogICAgICAgIHdpdGggdGhlIGNh cGFiaWxpdHkgdHVybmVkIG9mZiB0byBtYXRjaCB0aGUgcmVjZWl2ZWQgY2FwYWJpbGl0eSBzZXQu IA0KICAgICAgICBUaGlzIHByb2Nlc3Mgd2lsbCBldmVudHVhbGx5IHJlc3VsdCBpbiBib3RoIHNp ZGVzIGFncmVlaW5nIG9uIHRoZSANCiAgICAgICAgbWluaW1hbCBzZXQgb2Ygc3VwcG9ydGVkIGNh cGFiaWxpdGllcy4gVGhlIGFkamFjZW5jeSB3aWxsIG5vdCBjb21lIHVwIA0KICAgICAgICB1bmxl c3MgdGhlIGNhcGFiaWxpdGllcyBhZHZlcnRpc2VkIGJ5IHRoZSBjb250cm9sbGVyIGFuZCB0aGUg DQogICAgICAgIGNvbnRyb2xsZWQgZGV2aWNlIG1hdGNoLiANCg0KICAgICAgICBBZnRlciBpbml0 aWFsIHN5bmNocm9uaXphdGlvbiwgaWYgYXQgYW55dGltZSBhIGNhcGFiaWxpdHkgbWlzbWF0Y2gg aXMgDQogICAgICAgIGRldGVjdGVkLCB0aGUgYWRqYWNlbmN5IHdpbGwgYmUgYnJvdWdodCBkb3du IChSU1RBQ0sgd2lsbCBiZSANCiAgICAgICAgZ2VuZXJhdGVkIGJ5IHRoZSBkZXZpY2UgZGV0ZWN0 aW5nIHRoZSBtaXNtYXRjaCksIGFuZCBzeW5jaHJvbml6YXRpb24gDQogICAgICAgIHdpbGwgYmUg cmUtYXR0ZW1wdGVkLiANCg0KICAgICAgICAgDQoNCiAgICAgICAgICAgIDAgICAgICAgICAgICAg ICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMgDQogICAgICAg ICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDEgDQogICAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0KICAgICAgICAgICB8ICAgVmVyIHwg IFN1YiAgfCBNZXNzYWdlIFR5cGUgIHwgICAgIFRpbWVyICAgICB8TXwgICAgIENvZGUgICAgfCAN CiAgICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsgDQogICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgIFNlbmRlciBOYW1lICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAr ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKyANCiAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAgICAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArIA0KICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgIFJlY2VpdmVyIE5hbWUgICAgICAgICAg ICAgICAgICAgICAgICAgfCANCiAgICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQogICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgIFNlbmRlciBQb3J0ICAgICAgICAgICAgICAgICAgICAgICAg ICB8IA0KICAgICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCiAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICBSZWNlaXZlciBQb3J0ICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAg ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rIA0KICAgICAgICAgICB8IFBUeXBlIHwgUEZsYWcgfCAgICAgICAgICAgICAg IFNlbmRlciBJbnN0YW5jZSAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsg DQogICAgICAgICAgIHwgUGFydGl0aW9uIElEICB8ICAgICAgICAgICAgICBSZWNlaXZlciBJbnN0 YW5jZSAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCiAgICAgICAgICAg fCBUZWNoIFR5cGUgICAgIHwgIyBvZiBUTFZzICAgICB8IFRvdGFsIExlbmd0aCAgICAgICAgICAg ICAgICAgIHwgDQogICAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0KICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCiAg ICAgICAgICAgfiAgICAgICAgICAgICAgICAgICBDYXBhYmlsaXR5IFRMVnMgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIH4gDQogICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKyANCiAgICAgICAgICAgIA0KDQogICAgICAgICAgIA0KDQogICAgICAgICANCg0KICAgICAg DQogICAgICANCiAgICAgV2FkaHdhIGV0LmFsICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDI4 LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSAxNl0gDQogICAgICAgICANCgwgICAgIEludGVybmV0 LURyYWZ0ICAgICAgZHJhZnQtd2FkaHdhLWdzbXAtbDJjb250cm9sLWNvbmZpZ3VyYXRpb24tMDEg ICAgICAgIE1hcmNoIDIwMDYgDQogICAgICAgICANCg0KICAgICAgICAgVGhlIGZvcm1hdCBvZiBj YXBhYmlsaXR5IFRMViBpczogDQoNCiAgICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQogICAgICAgICAgIHwg ICAgIENhcGFiaWxpdHkgVHlwZSAgICAgICAgIHwgICBDYXBhYmlsaXR5IExlbmd0aCAgICAgICAg ICAgICB8IA0KICAgICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCiAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQogICAg ICAgICAgIH4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB+IA0KICAgICAgICAgICB+ICAgICAgICAgICAgICAgICAgIENhcGFiaWxp dHkgRGF0YSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfiAgDQogICAgICAgICAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rIA0KICAgICAgICAgDQoNCiAgICAgICAgVGhlIFRlY2ggVHlwZSBmaWVsZCB0eXBlIGluZGlj YXRlcyB0aGUgdGVjaG5vbG9neSB0byB3aGljaCB0aGUgDQogICAgICAgIGNhcGFiaWxpdHkgZXh0 ZW5zaW9uIGFwcGxpZXMuIEZvciBsYXllcjIgY29udHJvbCBpbiBjYXNlIG9mIERTTCANCiAgICAg ICAgbmV0d29ya3MsIG5ldyB0eXBlICJEU0wiIGlzIHByb3Bvc2VkLiBUaGUgdmFsdWUgZm9yIHRo aXMgZmllbGQgaXMgDQogICAgICAgIDB4MDUuIFRoaXMgaXMgdGhlIGZpcnN0IGF2YWlsYWJsZSB2 YWx1ZSBpbiB0aGUgcmFuZ2UgdGhhdCBpcyBub3QgDQogICAgICAgIGN1cnJlbnRseSBhbGxvY2F0 ZWQuIEl0IHdpbGwgbmVlZCB0byBiZSByZXNlcnZlZCB3aXRoIElBTkEuIA0KDQogICAgICAgIENh cGFiaWxpdHkgbGVuZ3RoIGlzIHRoZSBudW1iZXIgb2YgYWN0dWFsIGJ5dGVzIGNvbnRhaW5lZCBp biB0aGUgDQogICAgICAgIHZhbHVlIHBvcnRpb24gb2YgdGhlIFRMVi4gVGhlIFRMViBpcyBwYWRk ZWQgdG8gYSA0LW9jdGV0IGFsaWdubWVudC4gDQogICAgICAgIFRoZXJlZm9yZSwgYSBUTFYgd2l0 aCBubyBkYXRhIHdpbGwgY29udGFpbiBhIHplcm8gaW4gdGhlIGxlbmd0aCBmaWVsZCANCiAgICAg ICAgKGlmIGNhcGFiaWxpdHkgZGF0YSBpcyB0aHJlZSBvY3RldHMsIHRoZSBsZW5ndGggZmllbGQg d2lsbCBjb250YWluIGEgDQogICAgICAgIHRocmVlLCBidXQgdGhlIHNpemUgb2YgdGhlIGFjdHVh bCBUTFYgaXMgZWlnaHQgb2N0ZXRzKS4gDQoNCiAgICAgICAgQ2FwYWJpbGl0eSBkYXRhIGZpZWxk IGNhbiBiZSBlbXB0eSBpZiB0aGUgY2FwYWJpbGl0eSBpcyBqdXN0IGEgDQogICAgICAgIGJvb2xl YW4uIEluIGNhc2UgdGhlIGNhcGFiaWxpdHkgaXMgYSBib29sZWFuLCBpdCBpcyBpbmZlcnJlZCBm cm9tIHRoZSANCiAgICAgICAgcHJlc2VuY2Ugb2YgdGhlIFRMViAod2l0aCBubyBkYXRhKS4gQ2Fw YWJpbGl0eSBkYXRhIHByb3ZpZGVzIHRoZSANCiAgICAgICAgZmxleGliaWxpdHkgdG8gYWR2ZXJ0 aXNlIG1vcmUgdGhhbiBtZXJlIHByZXNlbmNlIG9yIGFic2VuY2Ugb2YgYSANCiAgICAgICAgY2Fw YWJpbGl0eS4gQ2FwYWJpbGl0eSB0eXBlcyBjYW4gYmUgcmVnaXN0ZXJlZCB3aXRoIElBTkEuIEZv bGxvd2luZyANCiAgICAgICAgY2FwYWJpbGl0aWVzIGFyZSBkZWZpbmVkIGZvciBsYXllcjIgY29u dHJvbCBwcm90b2NvbCBhcyBhcHBsaWVkIHRvIA0KICAgICAgICBEU0wgYWNjZXNzOiANCg0KICAg ICAgICAgDQoNCiAgICAgICAgICAxLiBDYXBhYmlsaXR5IFR5cGUgOiBEeW5hbWljLVRvcG9sb2d5 LURpc2NvdmVyeSA9IDB4MDEgDQoNCiAgICAgICAgICAgICBMZW5ndGggKGluIGJ5dGVzKSA6IDAg DQoNCiAgICAgICAgICAgICBDYXBhYmlsaXR5IERhdGEgOiBOVUxMIA0KDQogICAgICAgICANCg0K ICAgICAgICAgIDIuIENhcGFiaWxpdHkgVHlwZSA6IExpbmUtQ29uZmlndXJhdGlvbiA9IDB4MDIg DQoNCiAgICAgICAgICAgICBMZW5ndGggKGluIGJ5dGVzKSA6IDAgDQoNCiAgICAgICAgICAgICBD YXBhYmlsaXR5IERhdGEgOiBOVUxMIA0KDQogICAgICANCiAgICAgIA0KICAgICBXYWRod2EgZXQu YWwgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjgsIDIwMDYgICAgICAgICAgICAgIFtQYWdl IDE3XSANCiAgICAgICAgIA0KDCAgICAgSW50ZXJuZXQtRHJhZnQgICAgICBkcmFmdC13YWRod2Et Z3NtcC1sMmNvbnRyb2wtY29uZmlndXJhdGlvbi0wMSAgICAgICAgTWFyY2ggMjAwNiANCiAgICAg ICAgIA0KDQogICAgICAgICANCg0KICAgICAgICAgIDMuIENhcGFiaWxpdHkgVHlwZSA6IFRyYW5z YWN0aW9uYWwtTXVsdGljYXN0ID0gMHgwMyAoY29udHJvbGxlciANCiAgICAgICAgICAgICBpLmUu IEJSQVMgdGVybWluYXRlcyBJR01QIG1lc3NhZ2VzIGZyb20gc3Vic2NyaWJlcnMsIGFuZCB2aWEg bDIgDQogICAgICAgICAgICAgY29udHJvbCBwcm90b2NvbCwgc2lnbmFscyBzdGF0ZSB0byB0aGUg YWNjZXNzLW5vZGVzIChlLmcuIA0KICAgICAgICAgICAgIERTTEFNcykgdG8gZW5hYmxlIGxheWVy MiByZXBsaWNhdGlvbiBvZiBtdWx0aWNhc3Qgc3RyZWFtcy4gSW4gDQogICAgICAgICAgICAgQVRN IGFjY2VzcyBuZXR3b3JrIHRoaXMgaW1wbGllcyB0aGF0IEJSQVMgaW5zdHJ1Y3RzIHRoZSBhY2Nl c3MtDQogICAgICAgICAgICAgbm9kZSB0byBzZXR1cCBhIFAyTVAgY3Jvc3MtY29ubmVjdC4gVGhl IGRldGFpbHMgb2YgdGhpcyB3aWxsIGJlIA0KICAgICAgICAgICAgIGNvdmVyZWQgaW4gYSBzZXBh cmF0ZSBJRCBbNl0uICANCg0KICAgICAgICAgICAgIExlbmd0aCAoaW4gYnl0ZXMpIDogMCANCg0K ICAgICAgICAgICAgIENhcGFiaWxpdHkgRGF0YSA6IE5VTEwgDQoNCiAgICAgICAgIA0KDQogICAg ICAgICAgNC4gQ2FwYWJpbGl0eSBUeXBlIDogT0FNID0gMHgwNCAgDQoNCiAgICAgICAgICAgICBM ZW5ndGggKGluIGJ5dGVzKSA6IDAgDQoNCiAgICAgICAgICAgICBDYXBhYmlsaXR5IERhdGEgOiBO VUxMIA0KDQogICAgICAgICANCg0KICAgICA1LjQgR1NNUCBNZXNzYWdlIEV4dGVuc2lvbnMgZm9y IEwyIGNvbnRyb2wgDQoNCiAgICAgNS40LjEgVG9wb2xvZ3kgRGlzY292ZXJ5IA0KDQogICAgIFRo ZSBHU01QIEV2ZW50IG1lc3NhZ2Ugd2l0aCBQT1JUIFVQIG1lc3NhZ2UgdHlwZSAoODApIGlzIHVz ZWQgZm9yIA0KICAgICBjb252ZXlpbmcgRFNMIGxpbmUgYXR0cmlidXRlcyB0byB0aGUgQlJBUy4g VGhlIHZlcnNpb24gZmllbGQgc2hvdWxkIGJlIA0KICAgICBzZXQgdG8gMywgYW5kIHRoZSBzdWIg ZmllbGQgc2hvdWxkIGJlIHNldCB0byAxLiBUaGUgSSBhbmQgc3ViTWVzc2FnZSANCiAgICAgZmll bGRzIFNIT1VMRCBiZSBzZXQgdG8gMSB0byBzaWduaWZ5IG5vIGZyYWdtZW50YXRpb24uIFRoZSBQ b3J0IGFuZCANCiAgICAgTGFiZWwgZmllbGRzIHNob3VsZCBiZSBzZXQgdG8gMC4gVGhlICJQb3J0 IFNlc3Npb24gTnVtYmVyIiBzaG91bGQgYmUgc2V0IA0KICAgICB0byAwLCBhbmQgdGhlICJFdmVu dCBTZXF1ZW5jZSBOdW1iZXIiIHNob3VsZCBiZSAwLiBUaGUgVGVjaCBUeXBlIGZpZWxkIA0KICAg ICBpcyBleHRlbmRlZCB3aXRoIG5ldyB0eXBlICJEU0wiLiBUaGUgdmFsdWUgZm9yIHRoaXMgZmll bGQgaXMgMHgwNS4gVGhlIA0KICAgICBtZXNzYWdlIFNIT1VMRCBiZSBnZW5lcmF0ZWQgd2hlbiBh IGxpbmUgZmlyc3QgY29tZXMgVVAsIG9yIGFueSBvZiB0aGUgDQogICAgIGF0dHJpYnV0ZXMgb2Yg dGhlIGxpbmUgY2hhbmdlIGUuZy4gdGhlIGxpbmUgcmUtdHJhaW5zIHRvIGEgZGlmZmVyZW50IA0K ICAgICByYXRlIG9yIG9uZSBvciBtb3JlIG9mIHRoZSBjb25maWd1cmVkIGxpbmUgYXR0cmlidXRl cyBhcmUgDQogICAgIGFkbWluaXN0cmF0aXZlbHkgbW9kaWZpZWQuIEFsc28sIHdoZW4gdGhlIEwy QyBzZXNzaW9uIGZpcnN0IGNvbWVzIHVwLCANCiAgICAgdGhlIERTTFNNIFNIT1VMRCB0cmFuc21p dCBhIFBPUlQgVVAgbWVzc2FnZSB0byB0aGUgQlJBUyBmb3IgZWFjaCBsaW5lIA0KICAgICB0aGF0 IGlzIHVwLiBBIERTTEFNIE1BWSB1c2UgYSBCdWxrIFRyYW5zYWN0aW9uIG1lc3NhZ2UgYXMgZGVm aW5lZCBpbiBbNF0gDQogICAgIHRvIGFnZ3JlZ2F0ZSB0aGUgdHJhbnNtaXNzaW9uIG9mIFBPUlQg VVAgbWVzc2FnZXMuIA0KDQogICAgIFdoZW4gYSBEU0wgbGluZSBnb2VzIGRvd24gKGlkbGUgb3Ig c2lsZW50KSwgdGhlIERTTEFNIFNIT1VMRCB0cmFuc21pdCBhbiANCiAgICAgRXZlbnQgbWVzc2Fn ZSB3aXRoIFBPUlQgRE9XTiBtZXNzYWdlIHR5cGUgKDgxKSB0byB0aGUgQlJBUy4gSXQgaXMgDQog ICAgIHJlY29tbWVuZGVkIHRoYXQgdGhlIERTTEFNcyB1c2UgYSBkYW1wZW5pbmcgbWVjaGFuaXNt IHBlciBEU0wgbGluZSB0byANCg0KICAgICAgDQogICAgICANCiAgICAgV2FkaHdhIGV0LmFsICAg ICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDI4LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSAxOF0g DQogICAgICAgICANCgwgICAgIEludGVybmV0LURyYWZ0ICAgICAgZHJhZnQtd2FkaHdhLWdzbXAt bDJjb250cm9sLWNvbmZpZ3VyYXRpb24tMDEgICAgICAgIE1hcmNoIDIwMDYgDQogICAgICAgICAN Cg0KICAgICBjb250cm9sIHRoZSByYXRlIG9mIHN0YXRlIGNoYW5nZXMgcGVyIERTTCBsaW5lLCBj b21tdW5pY2F0ZWQgdG8gdGhlIA0KICAgICBCUkFTLiAgDQoNCiAgICAgICAgIDAgICAgICAgICAg ICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMgDQogICAg ICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDEgDQogICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0KICAgICAgICB8IFZlcnMgIHwgIFN1YiAg fCBNZXNzYWdlIFR5cGUgIHwgUmVzdWx0fCAgICAgICAgQ29kZSAgICAgICAgICAgfCANCiAgICAg ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsgDQogICAgICAgIHwgUGFydGl0aW9uIElEICB8ICAgICAgICAgICAgVHJhbnNh Y3Rpb24gSWRlbnRpZmllciAgICAgICAgICAgICB8ICAgICANCiAgICAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQog ICAgICAgIHxJfCAgICAgIFN1Yk1lc3NhZ2UgTnVtYmVyICAgICAgfCAgICAgICAgICAgTGVuZ3Ro ICAgICAgICAgICAgICB8IA0KICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCiAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgUG9ydCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQog ICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rIA0KICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgIFBvcnQgU2Vz c2lvbiBOdW1iZXIgICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQog ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICBFdmVudCBTZXF1ZW5jZSBOdW1iZXIgICAgICAg ICAgICAgICAgICAgICB8IA0KICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCiAgICAgICAgfHh8U3x4fHh8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQog ICAgICAgICstKy0rLSstKyAgICAgICAgICAgICAgICAgICAgIExhYmVsICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8IA0KICAgICAgICB+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfiANCiAgICAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQog ICAgICAgIHx4fHh8eHx4fHh8eHx4fHh8IE1lc3NhZ2UgVHlwZSAgfCAgIFRlY2ggVHlwZSAgIHwg QmxvY2sgTGVuZ3RoICB8IA0KICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCiAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQog ICAgICAgIH4gICAgICAgICAgICAgICAgICAgICAgICAgRXh0ZW5zaW9uIFZhbHVlICAgICAgICAg ICAgICAgICAgICAgICB+IA0KICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQog ICAgICAgICANCiAgICAgICAgIA0KICAgICAgICBUaGUgZm9ybWF0IG9mIHRoZSAiRXh0ZW5zaW9u IFZhbHVlIiBmaWVsZCBmb3IgVGVjaCBUeXBlICJEU0wiIGlzICANCiAgICAgICAgYXMgZm9sbG93 cyA6IA0KICAgICAgICAgDQogICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICAgICAgICANCiAgICAgICAgfCAgICAg ICAgICAgICAjIG9mIFRMVnMgICAgICAgICB8IEV4dGVuc2lvbiBibG9jayBsZW5ndGggKGJ5dGVz KXwgDQogICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rICAgICAgICAgICAgIA0KICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCiAg ICAgICAgfiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIH4gDQogICAgICAgIH4gICAgICAgICAgICAgICAgICAgICAgICAgICBUTFZz ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB+ICANCiAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQog ICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rIA0KICAgICAgDQoNCiAgICAgVGhlICJFeHRlbnNpb24gVmFsdWUiIGNv bnRhaW5zIG9uZSBvciBtb3JlIFRMVnMgdG8gaWRlbnRpZnkgYSBEU0wgbGluZSANCiAgICAgYW5k IGRlZmluZSBpdCdzIGNoYXJhY3RlcmlzdGljcy4gQSBUTFYgY2FuIGNvbnNpc3Qgb2YgbXVsdGlw bGUgc3ViLVRMVnMuIA0KICAgICBGaXJzdCAyIGJ5dGUgb2YgdGhlICJFeHRlbnNpb24gVmFsdWUi IGNvbnRhaW5zIHRoZSBudW1iZXIgb2YgVExWcyB0aGF0IA0KICAgICBmb2xsb3cuIFRoZSBuZXh0 IDIgYnl0ZXMgY29udGFpbiB0aGUgdG90YWwgbGVuZ3RoIG9mIHRoZSBUTFZzIGNhcnJpZWQgaW4g DQogICAgICANCiAgICAgIA0KICAgICBXYWRod2EgZXQuYWwgICAgICAgICAgRXhwaXJlcyBTZXB0 ZW1iZXIgMjgsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDE5XSANCiAgICAgICAgIA0KDCAgICAg SW50ZXJuZXQtRHJhZnQgICAgICBkcmFmdC13YWRod2EtZ3NtcC1sMmNvbnRyb2wtY29uZmlndXJh dGlvbi0wMSAgICAgICAgTWFyY2ggMjAwNiANCiAgICAgICAgIA0KDQogICAgIHRoZSBleHRlbnNp b24gYmxvY2sgaW4gYnl0ZXMgKGV4aXN0aW5nICJCbG9jayBMZW5ndGgiIGZpZWxkIGluIHRoZSBH U01QIA0KICAgICBtZXNzYWdlIGlzIGxpbWl0ZWQgdG8gMjU1IGJ5dGVzIGFuZCBpcyBub3Qgc3Vm ZmljaWVudCkuIA0KDQogICAgICANCg0KICAgICAgICBHZW5lcmFsIGZvcm1hdCBvZiBhIFRMViBp cyA6ICANCg0KICAgICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIA0KICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAgICAgICAgDQogICAg ICAgIHwgICAgICAgICAgICBUeXBlICAgICAgICAgICAgICAgfCAgICAgICAgICAgICBMZW5ndGgg ICAgICAgICAgICB8IA0KICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAgICAgICAgICAgICANCiAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgDQogICAgICAgIH4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB+IA0KICAgICAgICB+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgVmFsdWUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfiAgDQogICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8IA0KICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCiAgICAgICAgIA0KDQogICAgIFRoZSB2YWx1ZSBm aWVsZCBpbiBlYWNoIFRMViBpcyBwYWRkZWQgdG8gYSA0LW9jdGV0IGFsaWdubWVudC4gVGhlIExl bmd0aCANCiAgICAgZmllbGQgaW4gZWFjaCBUTFYgY29udGFpbnMgdGhlIGFjdHVhbCBudW1iZXIg b2YgYnl0ZXMgaW4gdGhlIFRMViAobm90IA0KICAgICBpbmNsdWRpbmcgdGhlIHBhZGRpbmcgaWYg cHJlc2VudCkuIElmIGEgVExWIGlzIG5vdCB1bmRlcnN0b29kIGJ5IHRoZSANCiAgICAgQlJBUywg aXQgaXMgc2lsZW50bHkgaWdub3JlZC4gQ3VycmVudGx5IGRlZmluZWQgdHlwZXMgc3RhcnQgZnJv bSAweDAxLiANCg0KICAgICBGb2xsb3dpbmcgVExWcyBhcmUgY3VycmVudGx5IGRlZmluZWQ6IA0K DQogICAgICAgMS4gVHlwZSAoQWNjZXNzLUxvb3AtQ2lyY3VpdC1JRCA9IDB4MDEpOiBUaGlzIGlz IGEgbWFuZGF0b3J5IFRMViBhbmQgDQogICAgICAgICAgY29udGFpbnMgYW4gaWRlbnRpZmllciBv ZiB0aGUgc3Vic2NyaWJlcidzIGNvbm5lY3Rpb24gdG8gdGhlIGFjY2VzcyANCiAgICAgICAgICBu b2RlIChpLmUuICAibG9jYWwgbG9vcCIpLiBUaGUgImxvY2FsIGxvb3AiIGNhbiBiZSBBVE0gYmFz ZWQgb3IgDQogICAgICAgICAgRXRoZXJuZXQgYmFzZWQuIFRoZSAiQWNjZXNzIExvb3AgQ2lyY3Vp dCBJRCIgaGFzIGxvY2FsIHNpZ25pZmljYW5jZSANCiAgICAgICAgICBhdCB0aGUgYWNjZXNzIG5v ZGUuIFRoZSBleGFjdCB1c2FnZSBvbiB0aGUgQlJBUyBpcyBiZXlvbmQgdGhlIHNjb3BlIA0KICAg ICAgICAgIG9mIHRoaXMgZG9jdW1lbnQuIEl0IGlzIGRlc2lyYWJsZSB0aGF0IHRoZSBmb3JtYXQg dXNlZCBmb3IgImxvY2FsIA0KICAgICAgICAgIGxvb3AiIGlkZW50aWZpY2F0aW9uIGluIEdTTVAg bWVzc2FnZXMgaXMgc2ltaWxhciB0byB3aGF0IGlzIHVzZWQgYnkgDQogICAgICAgICAgdGhlIGFj Y2VzcyBub2RlcyBpbiBzdWJzY3JpYmVyIHNpZ25hbGluZyBtZXNzYWdlcyB3aGVuIHRoZSBhY2Nl c3MgDQogICAgICAgICAgbm9kZXMgYWN0IGFzICJzaWduYWxpbmcgcmVsYXkgYWdlbnRzIiBhcyBv dXRsaW5lZCBpbiBbN10gYW5kIFs4XS4gIA0KDQogICAgICAgICAgTGVuZ3RoIDogKHVwdG8gNjMg Ynl0ZXMpICANCg0KICAgICAgICAgIFZhbHVlIDogQVNDSUkgc3RyaW5nLiAgICAgICAgICAgICAg ICAgICAgICAgDQoNCiAgICAgICAgICBGb3IgYW4gQVRNIGJhc2VkIGxvY2FsIGxvb3AgdGhlIHN0 cmluZyBjb25zaXN0cyBvZiBzbG90L3BvcnQgYW5kICAgDQogICAgICAgICAgVlBJL1ZDSSBpbmZv cm1hdGlvbiBjb3JyZXNwb25kaW5nIHRvIHRoZSBzdWJzY3JpYmVyJ3MgRFNMIA0KICAgICAgICAg IGNvbm5lY3Rpb24uIFR5cGljYWwgZm9ybWF0IGZvciB0aGUgc3RyaW5nIGluc2VydGVkIGJ5IHRo ZSBhY2Nlc3MgDQogICAgICAgICAgbm9kZSBpczogDQoNCiAgICAgICAgICBgYEFjY2Vzcy1Ob2Rl LUlkZW50aWZpZXIgYXRtIHNsb3QvcG9ydDp2cGkudmNpDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICcnICANCg0KDQogICAgICANCiAgICAgIA0KICAgICBX YWRod2EgZXQuYWwgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjgsIDIwMDYgICAgICAgICAg ICAgIFtQYWdlIDIwXSANCiAgICAgICAgIA0KDCAgICAgSW50ZXJuZXQtRHJhZnQgICAgICBkcmFm dC13YWRod2EtZ3NtcC1sMmNvbnRyb2wtY29uZmlndXJhdGlvbi0wMSAgICAgICAgTWFyY2ggMjAw NiANCiAgICAgICAgIA0KDQogICAgICAgICAgVGhlIEFjY2Vzcy1Ob2RlLUlkZW50aWZpZXIgdW5p cXVlbHkgaWRlbnRpZmllcyB0aGUgYWNjZXNzIG5vZGUgaW4gDQogICAgICAgICAgdGhlIGFjY2Vz cyBuZXR3b3JrLiBUaGUgc2xvdC9wb3J0IGFuZCBWUEkvVkNJIHVuaXF1ZWx5IGlkZW50aWZpZXMg DQogICAgICAgICAgdGhlIERTTCBsaW5lIG9uIHRoZSBhY2Nlc3Mgbm9kZS4gQWxzbywgdGhlcmUg aXMgb25lIHRvIG9uZSANCiAgICAgICAgICBjb3JyZXNwb25kZW5jZSBiZXR3ZWVuIERTTCBsaW5l IGFuZCB0aGUgVkMgYmV0d2VlbiB0aGUgYWNjZXNzIG5vZGUgDQogICAgICAgICAgYW5kIHRoZSBC UkFTLiAgDQoNCiAgICAgICAgICAgRm9yIGxvY2FsIGxvb3Agd2hpY2ggaXMgRXRoZXJuZXQgYmFz ZWQgKGFuZCB0YWdnZWQpLCB0aGUgc3RyaW5nIA0KICAgICAgICAgICBjb25zaXN0cyBvZiBzbG90 L3BvcnQgYW5kIFZMQU4gdGFnIGNvcnJlc3BvbmRpbmcgdG8gdGhlIA0KICAgICAgICAgICBzdWJz Y3JpYmVyLiBUeXBpY2FsIGZvcm1hdCBmb3IgdGhlIHN0cmluZyBpczogDQoNCiAgICAgICAgICAg ICJBY2Nlc3MtTm9kZS1JZGVudGlmaWVyIGV0aCBzbG90L3BvcnRbOnZsYW4taWRdIiAgDQogICAg ICANCiAgICAgICAgICAgDQogICAgICAgMi4gVHlwZSAoQWNjZXNzLUxvb3AtUmVtb3RlLUlkID0g MHgwMik6IFRoaXMgaXMgYW4gb3B0aW9uYWwgVExWIGFuZCANCiAgICAgICAgICBjb250YWlucyBh biBpZGVudGlmaWVyIHRvIHVuaXF1ZWx5IGlkZW50aWZ5IGEgdXNlciBvbiBhIGxvY2FsIGxvb3Ag DQogICAgICAgICAgb24gdGhlIGFjY2VzcyBub2RlLiBUaGUgZXhhY3QgdXNhZ2Ugb24gdGhlIEJS QVMgaXMgb3V0IG9mIHNjb3BlIG9mIA0KICAgICAgICAgIHRoaXMgZG9jdW1lbnQuIEl0IGlzIGRl c2lyYWJsZSB0aGF0IHRoZSBmb3JtYXQgdXNlZCBmb3IgdGhlIGZpZWxkIA0KICAgICAgICAgIGlz IHNpbWlsYXIgdG8gd2hhdCBpcyB1c2VkIGJ5IHRoZSBhY2Nlc3Mgbm9kZXMgaW4gc3Vic2NyaWJl ciANCiAgICAgICAgICBzaWduYWxpbmcgbWVzc2FnZXMgd2hlbiB0aGUgYWNjZXNzIG5vZGVzIGFj dCBhcyAic2lnbmFsaW5nIHJlbGF5IA0KICAgICAgICAgIGFnZW50cyIgYXMgb3V0bGluZWQgaW4g WzddIGFuZCBbOF0uIA0KDQogICAgICAgICAgTGVuZ3RoIDogKHVwdG8gNjMgYnl0ZXMpIA0KDQog ICAgICAgICAgVmFsdWUgIDogIEFTQ0lJIHN0cmluZyANCg0KICAgICAgICAgICAgICAgDQoNCiAg ICAgICAzLiBUeXBlIChBY2Nlc3MtQWdncmVnYXRpb24tQ2lyY3VpdC1JRC1CaW5hcnkgPSAweDA0 KSANCg0KICAgICAgICAgIExlbmd0aCA6ICg4IGJ5dGVzKSAgDQoNCiAgICAgICAgICBWYWx1ZSA6 IHR3byAzMiBiaXQgaW50ZWdlcnMuIA0KDQogICAgICAgICAgRm9yIGV0aGVybmV0IGFjY2VzcyBh Z2dyZWdhdGlvbiwgd2hlcmUgYSBwZXItc3Vic2NyaWJlciAoc3RhY2tlZCkgDQogICAgICAgICAg VkxBTiBjYW4gYmUgYXBwbGllZCAoMToxIG1vZGVsIGRlZmluZWQgaW4gWzhdKSwgdGhlIFZMQU4g c3RhY2sgDQogICAgICAgICAgcHJvdmlkZXMgYSBjb252ZW5pZW50IHdheSB0byB1bmlxdWVseSBp ZGVudGlmeSB0aGUgRFNMIGxpbmUuIFRoZSANCiAgICAgICAgICBvdXRlciBWTEFOIGlzIGVxdWl2 YWxlbnQgdG8gdmlydHVhbCBwYXRoIGJldHdlZW4gYSBEU0xBTSBhbmQgdGhlIA0KICAgICAgICAg IEJSQVMgYW5kIGlubmVyIFZMQU4gaXMgZXF1aXZhbGVudCB0byBhIHZpcnR1YWwgY2lyY3VpdCBv biBhIHBlciBEU0wgDQogICAgICAgICAgbGluZSBiYXNpcy4gSW4gdGhpcyBzY2VuYXJpbywgYW55 IHN1YnNjcmliZXIgZGF0YSByZWNlaXZlZCBieSB0aGUgDQogICAgICAgICAgYWNjZXNzIG5vZGUg YW5kIHRyYW5zbWl0dGVkIG91dCB0aGUgdXBsaW5rIHRvIHRoZSBhZ2dyZWdhdGlvbiANCiAgICAg ICAgICBuZXR3b3JrIHdpbGwgYmUgdGFnZ2VkIHdpdGggdGhlIFZMQU4gc3RhY2sgYXNzaWduZWQg YnkgdGhlIGFjY2VzcyANCiAgICAgICAgICBub2RlIA0KDQogICAgICAgICAgVGhpcyBUTFYgY2Fu IGNhcnJ5IHRoZSBWTEFOIHRhZ3MgYXNzaWduZWQgYnkgdGhlIGFjY2VzcyBub2RlIGluIHRoZSAN CiAgICAgICAgICBHU01QIG1lc3NhZ2VzLiBUaGUgVkxBTiB0YWdzIGNhbiB1bmlxdWVseSBpZGVu dGlmeSB0aGUgRFNMIGxpbmUgDQogICAgICAgICAgYmVpbmcgcmVmZXJyZWQgdG8gaW4gdGhlIEdT TVAgbWVzc2FnZXMsIGFzc3VtaW5nIHRoZSBWTEFOIHRhZ3MgYXJlIA0KICAgICAgICAgIG5vdCBp biBhbnkgd2F5IHRyYW5zbGF0ZWQgaW4gdGhlIGFnZ3JlZ2F0aW9uIG5ldHdvcmsgYW5kIGFyZSB1 bmlxdWUgDQogICAgICANCiAgICAgIA0KICAgICBXYWRod2EgZXQuYWwgICAgICAgICAgRXhwaXJl cyBTZXB0ZW1iZXIgMjgsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDIxXSANCiAgICAgICAgIA0K DCAgICAgSW50ZXJuZXQtRHJhZnQgICAgICBkcmFmdC13YWRod2EtZ3NtcC1sMmNvbnRyb2wtY29u ZmlndXJhdGlvbi0wMSAgICAgICAgTWFyY2ggMjAwNiANCiAgICAgICAgIA0KDQogICAgICAgICAg YWNyb3NzIHBoeXNpY2FsIHBvcnRzLiBFYWNoIDMyIGJpdCBpbnRlZ2VyIChsZWFzdCBzaWduaWZp Y2FudCBiaXRzKSANCiAgICAgICAgICBjb250YWlucyBhIDEyIGJpdCBWTEFOIGlkZW50aWZpZXIg KHdoaWNoIGlzIHBhcnQgb2YgdGhlIFZMQU4gdGFnIA0KICAgICAgICAgIGRlZmluZWQgYnkgSUVF RSA4MDIuMVEpLiANCg0KICAgICAgICAgIEFsc28sIGluIGNhc2Ugb2YgYW4gQVRNIGFnZ3JlZ2F0 aW9uIG5ldHdvcmssIHdoZXJlIHRoZSBEU0xBTSBpcyANCiAgICAgICAgICBkaXJlY3RseSBjb25u ZWN0ZWQgdG8gdGhlIEJSQVMgKHdpdGhvdXQgYW4gaW50ZXJtZWRpYXRlIEFUTSANCiAgICAgICAg ICBzd2l0Y2gpLCB0aGUgdHdvIHZhbHVlcyBjYW4gY29udGFpbiBWUEkgYW5kIFZDSSBvbiB0aGUg RFNMQU0gdXBsaW5rIA0KICAgICAgICAgIChhbmQgY2FuIHVuaXF1ZWx5IGlkZW50aWZ5IHRoZSBE U0wgbGluZSBvbiB0aGUgRFNMQU0pLiANCg0KICAgICAgICAgIFRoaXMgVExWIGlzIG9wdGlvbmFs LiANCg0KICAgICAgDQoNCiAgICAgICA0LiBUeXBlIChBY2Nlc3MtQWdncmVnYXRpb24tQ2lyY3Vp dC1JRC1BU0NJSSA9IDB4MDMpIA0KDQogICAgICAgICAgTGVuZ3RoIDogKHVwdG8gNjMgYnl0ZXMp ICANCg0KICAgICAgICAgIFZhbHVlIDogQVNDSUkgc3RyaW5nLiANCg0KICAgICAgICAgIFRoaXMg ZmllbGQgY29udGFpbnMgaW5mb3JtYXRpb24gcGVydGFpbmluZyB0byBhbiB1cGxpbmsgb24gdGhl IA0KICAgICAgICAgIGFjY2VzcyBub2RlLiBGb3IgRXRoZXJuZXQgYWNjZXNzIGFnZ3JlZ2F0aW9u LCBhc3N1bWluZyB0aGUgYWNjZXNzIA0KICAgICAgICAgIG5vZGUgYXNzaWducyBWTEFOIHRhZ3Mg KDE6MSBtb2RlbCksIHR5cGljYWwgZm9ybWF0IGZvciB0aGUgc3RyaW5nIA0KICAgICAgICAgIGlz OiANCg0KICAgICAgICAgIGBgDQogICAgICAgICAgIEFjY2Vzcy1Ob2RlLUlkZW50aWZpZXIgZXRo IHNsb3QvcG9ydCBbOmlubmVyLXZsYW4taWRdWzpvdXRlci12bGFuLWlkXQ0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICcn ICAgDQoNCiAgICAgICAgICBUaGUgc2xvdC9wb3J0IGNvcnJlc3BvbmRzIHRvIHRoZSBldGhlcm5l dCB1cGxpbmsgb24gdGhlIGFjY2VzcyBub2RlIA0KICAgICAgICAgIHRvd2FyZHMgdGhlIEJSQVMu IA0KDQogICAgICAgICAgRm9yIGFuIEFUTSBhZ2dyZWdhdGlvbiBuZXR3b3JrLCB0eXBpY2FsIGZv cm1hdCBmb3IgdGhlIHN0cmluZyBpczogDQoNCiAgICAgICAgICBgYA0KICAgICAgICAgICBBY2Nl c3MtTm9kZS1JZGVudGlmaWVyIGF0bSBzbG90L3BvcnQ6dnBpLnZjaQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAnJyANCg0KICAgICAgICAgIFRoaXMgVExW cyBhbGxvd3MgdGhlIEJSQVMgdG8gYXNzb2NpYXRlIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg aW4gDQogICAgICAgICAgdGhlIEdTTVAgbWVzc2FnZXMgdG8gdGhlIERTTCBsaW5lIG9uIHRoZSBh Y2Nlc3Mgbm9kZS4gDQoNCiAgICAgICAgICBJZiB0aGUgYWNjZXNzIG5vZGUgaW5zZXJ0cyB0aGlz IHN0cmluZyBpbiB0aGUgR1NNUCBtZXNzYWdlcywgd2hlbiANCiAgICAgICAgICByZWZlcnJpbmcg dG8gbG9jYWwgbG9vcCBjaGFyYWN0ZXJpc3RpY3MgKGUuZy4gRFNMIGxpbmUgaW4gY2FzZSBvZiBh IA0KICAgICAgICAgIERTTEFNKSwgdGhlbiBpdCBzaG91bGQgYmUgYWJsZSB0byBtYXAgdGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpbiANCiAgICAgICAgICB0aGUgc3RyaW5nIHVuaXF1ZWx5IHRv IHRoZSBsb2NhbCBsb29wIChlLmcuIERTTCBsaW5lKS4gDQoNCiAgICAgICAgICBPbiB0aGUgQlJB UywgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIHN0cmluZyBjYW4gYmUgdXNlZCAN CiAgICAgICAgICB0byBkZXJpdmUgYW4gImFnZ3JlZ2F0aW9uIG5ldHdvcmsiIGZhY2luZyBjb25z dHJ1Y3QgKGUuZy4gYW4gSVAgDQogICAgICAgICAgaW50ZXJmYWNlKSBjb3JyZXNwb25kaW5nIHRv IHRoZSBsb2NhbCBsb29wIChlLmcuIERTTCBsaW5lKS4gVGhlIA0KICAgICAgICAgIGFzc29jaWF0 aW9uIGNvdWxkIGJlIGJhc2VkIG9uICJsb2NhbCBjb25maWd1cmF0aW9uIiBvbiB0aGUgQlJBUy4g DQoNCg0KICAgICAgDQogICAgICANCiAgICAgV2FkaHdhIGV0LmFsICAgICAgICAgIEV4cGlyZXMg U2VwdGVtYmVyIDI4LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSAyMl0gDQogICAgICAgICANCgwg ICAgIEludGVybmV0LURyYWZ0ICAgICAgZHJhZnQtd2FkaHdhLWdzbXAtbDJjb250cm9sLWNvbmZp Z3VyYXRpb24tMDEgICAgICAgIE1hcmNoIDIwMDYgDQogICAgICAgICANCg0KICAgICAgICAgIFRo ZSBhY2Nlc3Mgbm9kZSBjYW4gYWxzbyBjb252ZXkgdG8gdGhlIEJSQVMsIHRoZSBjaGFyYWN0ZXJp c3RpY3MgDQogICAgICAgICAgKGUuZy4gYmFuZHdpZHRoKSBvZiB0aGUgdXBsaW5rIG9uIHRoZSBh Y2Nlc3Mgbm9kZS4gVGhpcyBUTFYgdGhlbiANCiAgICAgICAgICBzZXJ2ZXMgdGhlIHB1cnBvc2Ug b2YgdW5pcXVlbHkgaWRlbnRpZnlpbmcgdGhlIHVwbGluayB3aG9zZSANCiAgICAgICAgICBjaGFy YWN0ZXJpc3RpY3MgYXJlIGJlaW5nIGRlZmluZWQuIEEgc2VwYXJhdGUgc2V0IG9mIHN1Yi1UTFZz IHdpbGwgDQogICAgICAgICAgYmUgZGVmaW5lZCBmb3IgdGhlIHVwbGluayBjaGFyYWN0ZXJpc3Rp Y3MgKFRCRCkuIA0KDQogICAgICAgICAgVGhpcyBUTFYgaXMgb3B0aW9uYWwuIA0KDQogICAgICAg ICAgDQoNCiAgICAgICA1LiBUeXBlIChEU0wgTGluZSBBdHRyaWJ1dGVzID0gMHgwNCk6IA0KDQog ICAgICAgICAgTGVuZ3RoIDogdmFyaWFibGUgKHVwIHRvIDEwMjQgYnl0ZXMpIA0KDQogICAgICAg ICAgVmFsdWUgOiBUaGlzIGNvbnNpc3RzIG9mIG9uZSBvciBtb3JlIFN1Yi1UTFZzIGNvcnJlc3Bv bmRpbmcgdG8gRFNMICAgICANCiAgICAgICAgICBsaW5lIGF0dHJpYnV0ZXMuIE5vIHN1Yi1UTFZz IG90aGVyIHRoYW4gdGhlICJEU0wgdHlwZSIgYW5kICJEU0wgDQogICAgICAgICAgbGluZSBzdGF0 ZSIgU0hPVUxEIGJlIGluY2x1ZGVkIGluIGEgUE9SVCBET1dOIG1lc3NhZ2UuIA0KDQogICAgICAg ICAgVGhlIGdlbmVyYWwgZm9ybWF0IG9mIHRoZSBzdWItVExWcyBpcyBpZGVudGljYWwgdG8gdGhl IGdlbmVyYWwgVExWICAgDQogICAgICAgICAgZm9ybWF0LiBUaGUgdmFsdWUgZmllbGQgaW4gZWFj aCBzdWItVExWIGlzIHBhZGRlZCB0byBhIDQtb2N0ZXQgDQogICAgICAgICAgYWxpZ25tZW50LiBU aGUgTGVuZ3RoIGZpZWxkIGluIGVhY2ggc3ViLVRMViBjb250YWlucyB0aGUgYWN0dWFsIA0KICAg ICAgICAgIG51bWJlciBvZiBieXRlcyBpbiB0aGUgVExWIChub3QgaW5jbHVkaW5nIHRoZSBwYWRk aW5nIGlmIHByZXNlbnQpLiANCiAgICAgICAgICBDdXJyZW50IGRlZmluZWQgc3ViLVRMViB0eXBl cyBhcmUgc3RhcnQgZnJvbSAweDgxLiANCg0KICAgICAgICAgIEZvbGxvd2luZyBzdWItVExWcyBh cmUgY3VycmVudGx5IGRlZmluZWQgOiANCg0KICAgICAgICAgIC4gVHlwZSAoRFNMLVR5cGUgPSAw eDkxKSA6IERlZmluZXMgdGhlIHR5cGUgb2YgdHJhbnNtaXNzaW9uIHN5c3RlbSANCiAgICAgICAg ICAgICBpbiB1c2UuIFRoaXMgaXMgYSBtYW5kYXRvcnkgVExWLiANCg0KICAgICAgICAgICAgIExl bmd0aCA6ICAoNCBieXRlcykgICANCg0KICAgICAgICAgICAgIFZhbHVlICA6IChUcmFuc21pc3Np b24gc3lzdGVtIDogQURTTDEgPSAweDAxLCBBRFNMMiA9IDB4MDIsICAgICANCiAgICAgICAgICAg ICBBRFNMMisgPSAweDAzLCBWRFNMMSA9IDB4MDQsIFZEU0wyID0gMHgwNSwgU0RTTCA9IDB4MDYs IFVOS05PV04gDQogICAgICAgICAgICAgPSAweDA3KS4gDQoNCiAgICAgICAgICAuIFR5cGUgKEFj dHVhbC1EYXRhLVJhdGUtVXBzdHJlYW0gPSAweDgxKSA6IEFjdHVhbCBkYXRhIHJhdGUgDQogICAg ICAgICAgICAgdXBzdHJlYW0gb2YgYSBzeW5jaHJvbml6ZWQgRFNMIGxpbmUuIFRoaXMgaXMgYSBt YW5kYXRvcnkgVExWLiANCiAgICAgICAgICAgICBUaGlzIHJhdGUgdmFsdWUgYW5kIGFsbCB0aGUg c3Vic2VxdWVudCBvbmVzIGFjY291bnQgZm9yIHRoZSBEU0wgDQogICAgICAgICAgICAgb3Zlcmhl YWQgKGkuZS4gc2lnbmlmeSB0aGUgbmV0IHJhdGUpLiAgIA0KDQogICAgICAgICAgICBMZW5ndGgg IDogICg0IGJ5dGVzKSANCg0KICAgICAgICAgICAgVmFsdWUgICA6IChSYXRlIGluIEtiL3NlYykg DQoNCiAgICAgICAgICAuIFR5cGUgKEFjdHVhbC1EYXRhLVJhdGUtRG93bnN0cmVhbSA9IDB4ODIp IDogQWN0dWFsIGRhdGEgcmF0ZSANCiAgICAgICAgICAgICBkb3duc3RyZWFtIG9mIGEgc3luY2hy b25pemVkIERTTCBsaW5lLiBUaGlzIGlzIGEgbWFuZGF0b3J5IFRMVi4gDQoNCiAgICAgIA0KICAg ICAgDQogICAgIFdhZGh3YSBldC5hbCAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAyOCwgMjAw NiAgICAgICAgICAgICAgW1BhZ2UgMjNdIA0KICAgICAgICAgDQoMICAgICBJbnRlcm5ldC1EcmFm dCAgICAgIGRyYWZ0LXdhZGh3YS1nc21wLWwyY29udHJvbC1jb25maWd1cmF0aW9uLTAxICAgICAg ICBNYXJjaCAyMDA2IA0KICAgICAgICAgDQoNCiAgICAgICAgICAgICBMZW5ndGggOiAgKDQgYnl0 ZXMpIA0KDQogICAgICAgICAgICAgVmFsdWUgIDogIChSYXRlIGluIEtiL3NlYykgDQoNCiAgICAg ICAgICAuIFR5cGUgKE1pbmltdW0tRGF0YS1SYXRlLVVwc3RyZWFtID0gMHg4MykgOiBNaW5pbXVt IGRhdGEgcmF0ZSANCiAgICAgICAgICAgICBkZXNpcmVkIGJ5IHRoZSBvcGVyYXRvci4gVGhpcyBp cyBvcHRpb25hbC4gIA0KDQogICAgICAgICAgICBMZW5ndGggIDogICg0IGJ5dGVzKSANCg0KICAg ICAgICAgICAgVmFsdWUgICA6IChSYXRlIGluIEtiL3NlYykgDQoNCiAgICAgICAgICAuIFR5cGUg KE1pbmltdW0tRGF0YS1SYXRlLURvd25zdHJlYW0gPSAweDg0KSA6IE1pbmltdW0gZGF0YSByYXRl IA0KICAgICAgICAgICAgIGRlc2lyZWQgYnkgdGhlIG9wZXJhdG9yLiBUaGlzIGlzIG9wdGlvbmFs LiAgDQoNCiAgICAgICAgICAgIExlbmd0aCAgOiAgKDQgYnl0ZXMpIA0KDQogICAgICAgICAgICBW YWx1ZSAgIDogKFJhdGUgaW4gS2Ivc2VjKSANCg0KICAgICAgICAgIC4gVHlwZSAoQXR0YWluYWJs ZS1EYXRhLVJhdGUtVXBzdHJlYW0gPSAweDg1KSA6IE1heGltdW0gdXBzdHJlYW0gDQogICAgICAg ICAgICAgcmF0ZSB0aGF0IGNhbiBiZSBhdHRhaW5lZCBvbiB0aGUgRFNMIGxpbmUuIFRoaXMgaXMg YW4gb3B0aW9uYWwgDQogICAgICAgICAgICAgVExWLiANCg0KICAgICAgICAgICAgTGVuZ3RoICA6 ICAoNCBieXRlcykgDQoNCiAgICAgICAgICAgICBWYWx1ZSAgIDogKFJhdGUgaW4gS2Ivc2VjKSAN Cg0KICAgICAgICAgIC4gVHlwZSAoQXR0YWluYWJsZS1EYXRhLVJhdGUtRG93bnN0cmVhbSA9IDB4 ODYpIDogTWF4aW11bSANCiAgICAgICAgICAgICBkb3duc3RyZWFtIHJhdGUgdGhhdCBjYW4gYmUg YXR0YWluZWQgb24gdGhlIERTTCBsaW5lLiBUaGlzIGlzICANCiAgICAgICAgICAgICBhbiBvcHRp b25hbCBUTFYuIA0KDQogICAgICAgICAgICBMZW5ndGggIDogICg0IGJ5dGVzKSANCg0KICAgICAg ICAgICAgVmFsdWUgICA6IChSYXRlIGluIEtiL3NlYykgDQoNCiAgICAgICAgICAuIFR5cGUgKE1h eGltdW0tRGF0YS1SYXRlLVVwc3RyZWFtID0gMHg4NykgOiBNYXhpbXVtIGRhdGEgcmF0ZSANCiAg ICAgICAgICAgICBkZXNpcmVkIGJ5IHRoZSAgb3BlcmF0b3IuIFRoaXMgaXMgb3B0aW9uYWwuICAN Cg0KICAgICAgICAgICAgTGVuZ3RoICA6ICAoNCBieXRlcykgIA0KDQogICAgICAgICAgICBWYWx1 ZSAgIDogKFJhdGUgaW4gS2Ivc2VjKSANCg0KICAgICAgICAgICANCg0KICAgICAgICAgIC4gVHlw ZSAoTWF4aW11bS1EYXRhLVJhdGUtRG93bnN0cmVhbSA9IDB4ODgpIDogTWF4aW11bSBkYXRhIHJh dGUgDQogICAgICAgICAgICAgZGVzaXJlZCBieSB0aGUgb3BlcmF0b3IuIFRoaXMgaXMgb3B0aW9u YWwuICANCg0KICAgICAgICAgICAgTGVuZ3RoICA6ICAoNCBieXRlcykgDQogICAgICANCiAgICAg IA0KICAgICBXYWRod2EgZXQuYWwgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjgsIDIwMDYg ICAgICAgICAgICAgIFtQYWdlIDI0XSANCiAgICAgICAgIA0KDCAgICAgSW50ZXJuZXQtRHJhZnQg ICAgICBkcmFmdC13YWRod2EtZ3NtcC1sMmNvbnRyb2wtY29uZmlndXJhdGlvbi0wMSAgICAgICAg TWFyY2ggMjAwNiANCiAgICAgICAgIA0KDQogICAgICAgICAgICBWYWx1ZSAgIDogKFJhdGUgaW4g S2Ivc2VjKSANCg0KICAgICAgICAgIC4gVHlwZSAoTWluaW11bS1Mb3ctUG93ZXItRGF0YS1SYXRl LVVwc3RyZWFtID0gMHg4OSkgOiBNaW5pbXVtIA0KICAgICAgICAgICAgIGRhdGEgcmF0ZSBkZXNp cmVkIGJ5IHRoZSBvcGVyYXRvciBpbiBsb3cgcG93ZXIgc3RhdGUuIFRoaXMgaXMgDQogICAgICAg ICAgICAgb3B0aW9uYWwuIA0KDQogICAgICAgICAgICBMZW5ndGggIDogICg0IGJ5dGVzKSANCg0K ICAgICAgICAgICAgVmFsdWUgICA6IChSYXRlIGluIEtiL3NlYykgDQoNCiAgICAgICAgICAuIFR5 cGUgKE1pbmltdW0tTG93LVBvd2VyLURhdGEtUmF0ZS1Eb3duc3RyZWFtID0gMHg4QSkgOiBNaW5p bXVtIA0KICAgICAgICAgICAgIGRhdGEgcmF0ZSBkZXNpcmVkIGJ5IHRoZSBvcGVyYXRvciBpbiBs b3cgcG93ZXIgc3RhdGUuIFRoaXMgaXMgDQogICAgICAgICAgICAgb3B0aW9uYWwuIA0KDQogICAg ICAgICAgICBMZW5ndGggIDogICg0IGJ5dGVzKSANCg0KICAgICAgICAgICAgVmFsdWUgICA6IChS YXRlIGluIEtiL3NlYykgDQoNCiAgICAgICAgICAuIFR5cGUgKE1heGltdW0tSW50ZXJsZWF2aW5n LURlbGF5LVVwc3RyZWFtID0gMHg4QikgOiBtYXhpbXVtIG9uZSANCiAgICAgICAgICAgICB3YXkg aW50ZXJsZWF2aW5nIGRlbGF5LiBUaGlzIGlzIG9wdGlvbmFsLiANCg0KICAgICAgICAgICAgTGVu Z3RoICA6ICAoNCBieXRlcykgDQoNCiAgICAgICAgICAgIFZhbHVlICAgOiAoVGltZSBpbiBtc2Vj KSANCg0KICAgICAgICAgIC4gVHlwZSAoQWN0dWFsLUludGVybGVhdmluZy1EZWxheS1VcHN0cmVh bSA9IDB4OEMpIDogVmFsdWUgDQogICAgICAgICAgICAgY29ycmVzcG9uZGluZyB0byB0aGUgaW50 ZXJsZWF2ZXIgc2V0dGluZy4gVGhpcyBpcyBvcHRpb25hbC4gDQoNCiAgICAgICAgICAgIExlbmd0 aCAgOiAgKDQgYnl0ZXMpIA0KDQogICAgICAgICAgICBWYWx1ZSAgIDogKFRpbWUgaW4gbXNlYykg DQoNCiAgICAgICAgICAuIFR5cGUgKE1heGltdW0tSW50ZXJsZWF2aW5nLURlbGF5LURvd25zdHJl YW0gPSAweDhEKSA6IG1heGltdW0gDQogICAgICAgICAgICAgb25lIHdheSBpbnRlcmxlYXZpbmcg ZGVsYXkuIFRoaXMgaXMgb3B0aW9uYWwuIA0KDQogICAgICAgICAgICBMZW5ndGggIDogICg0IGJ5 dGVzKSANCg0KICAgICAgICAgICAgVmFsdWUgICA6IChUaW1lIGluIG1zZWMpIA0KDQogICAgICAg ICAgIA0KDQogICAgICAgICAgLiBUeXBlIChBY3R1YWwtSW50ZXJsZWF2aW5nLURlbGF5LURvd25z dHJlYW0gPSAweDhFKSA6IFZhbHVlIA0KICAgICAgICAgICAgIGNvcnJlc3BvbmRpbmcgdG8gdGhl IGludGVybGVhdmVyIHNldHRpbmcuIFRoaXMgaXMgb3B0aW9uYWwuIA0KDQogICAgICAgICAgICBM ZW5ndGggIDogICg0IGJ5dGVzKSANCg0KICAgICAgICAgICAgVmFsdWUgICA6IChUaW1lIGluIG1z ZWMpIA0KICAgICAgDQogICAgICANCiAgICAgV2FkaHdhIGV0LmFsICAgICAgICAgIEV4cGlyZXMg U2VwdGVtYmVyIDI4LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSAyNV0gDQogICAgICAgICANCgwg ICAgIEludGVybmV0LURyYWZ0ICAgICAgZHJhZnQtd2FkaHdhLWdzbXAtbDJjb250cm9sLWNvbmZp Z3VyYXRpb24tMDEgICAgICAgIE1hcmNoIDIwMDYgDQogICAgICAgICANCg0KICAgICAgICAgIC4g VHlwZSAoRFNMIGxpbmUgc3RhdGUgPSAweDhGKSA6IFRoZSBzdGF0ZSBvZiB0aGUgRFNMIGxpbmUu IEZvciANCiAgICAgICAgICAgICBQT1JUIFVQIG1lc3NhZ2UsIGF0IHRoaXMgdGltZSwgdGhlIFRM ViBpcyBvcHRpb25hbCAoc2luY2UgdGhlIA0KICAgICAgICAgICAgIG1lc3NhZ2UgdHlwZSBpbXBs aWNpdGx5IGNvbnZleXMgdGhlIHN0YXRlIG9mIHRoZSBsaW5lKS4gRm9yIFBPUlQgDQogICAgICAg ICAgICAgRE9XTiwgdGhlIFRMViBpcyBtYW5kYXRvcnksIHNpbmNlIGl0IGZ1cnRoZXIgY29tbXVu aWNhdGVzIHRoZSANCiAgICAgICAgICAgICBzdGF0ZSBvZiB0aGUgbGluZSBhcyBJRExFIG9yIFNJ TEVOVC4gIA0KDQogICAgICAgICAgICBMZW5ndGggIDogICg0IGJ5dGVzKSANCg0KICAgICAgICAg ICAgIFZhbHVlICAgOiAgeyBTSE9XVElNRSA9IDB4MDEsIElETEUgPSAweDAyLCBTSUxFTlQgPSAw eDAzIH0gDQoNCiAgICAgICAgICAuIFR5cGUgKEFjY2VzcyBMb29wIEVuY2Fwc3VsYXRpb24gPSAw eDkwKSA6IFRoZSBkYXRhIGxpbmsgcHJvdG9jb2wgDQogICAgICAgICAgICAgYW5kLCBvcHRpb25h bGx5IHRoZSBlbmNhcHN1bGF0aW9uIG92ZXJoZWFkIG9uIHRoZSBhY2Nlc3MgbG9vcC4gDQogICAg ICAgICAgICAgVGhpcyBpcyBhbiBvcHRpb25hbCBUTFYuIEhvd2V2ZXIsIHdoZW4gdGhpcyBUTFYg aXMgcHJlc2VudCwgdGhlIA0KICAgICAgICAgICAgIGRhdGEgbGluayBwcm90b2NvbCBNVVNUIG1p bmltYWxseSBiZSBpbmRpY2F0ZWQuIFRoZSANCiAgICAgICAgICAgICBlbmNhcHN1bGF0aW9uIG92 ZXJoZWFkIGNhbiBiZSBvcHRpb25hbGx5IGluZGljYXRlZC4gDQoNCiAgICAgICAgICAgICAgTGVu Z3RoICA6ICAoMyBieXRlcykgDQoNCiAgICAgICAgICAgICAgVmFsdWUgOiBUaGUgdGhyZWUgYnl0 ZXMgKG1vc3QgdG8gbGVhc3Qgc2lnbmlmaWNhbnQpIGFuZCB2YWxpZCAgIA0KICAgICAgICAgICAg ICBzZXQgb2YgdmFsdWVzIGZvciBlYWNoIGJ5dGUgYXJlIGRlZmluZWQgYmVsb3cuIA0KDQogICAg ICAgICAgICAgICAgICAgRGF0YSBMaW5rICgxIGJ5dGUpOiB7QVRNIEFBTDUgPSAwLCAgDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRVRIRVJORVQgPSAxfSANCg0K ICAgICAgICAgICAgICAgICAgICBFbmNhcHMgMSAoMSBieXRlKToge05BID0gMCwgIA0KDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVW50YWdnZWQgRXRoZXJuZXQgPSAx LCANCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNpbmdsZS10YWdn ZWQgRXRoZXJuZXQgPSAyfSAgICAgIA0KDQogICAgICAgICAgICAgICAgICAgIEVuY2FwcyAyICgx IGJ5dGUpOnsgTkEgPSAwLCAgDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBQUFBvQSBMTEMgPSAxLCAgDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBQUFBvQSBOVUxMID0gMiwgDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBJUG9BIExMQyA9IDMsICANCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IElQb0EgTnVMTCA9IDQsICANCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEV0aGVybmV0IG92ZXIgQUFMNSBMTEMgd2l0aCBGQ1MgPSA1LCANCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEV0aGVybmV0IG92ZXIgQUFMNSBMTEMgd2l0aG91dCBGQ1Mg PSA2LCANCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEV0aGVybmV0IG92 ZXIgQUFMNSBOVUxMIHdpdGggRkNTID0gNywgDQoNCiAgICAgIA0KICAgICAgDQogICAgIFdhZGh3 YSBldC5hbCAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAyOCwgMjAwNiAgICAgICAgICAgICAg W1BhZ2UgMjZdIA0KICAgICAgICAgDQoMICAgICBJbnRlcm5ldC1EcmFmdCAgICAgIGRyYWZ0LXdh ZGh3YS1nc21wLWwyY29udHJvbC1jb25maWd1cmF0aW9uLTAxICAgICAgICBNYXJjaCAyMDA2IA0K ICAgICAgICAgDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBFdGhlcm5l dCBvdmVyIEFBTDUgTlVMTCB3aXRob3V0IEZDUyA9IDh9IA0KDQogICAgIElmIHRoaXMgVExWIGlz IHByZXNlbnQsIHRoZSBEYXRhIExpbmsgcHJvdG9jb2wgTVVTVCBiZSBpbmRpY2F0ZWQgYXMgDQog ICAgIGRlZmluZWQgYWJvdmUuIEhvd2V2ZXIsIHRoZSBBY2Nlc3MgTm9kZSBjYW4gY2hvb3NlIHRv IG5vdCBjb252ZXkgdGhlIA0KICAgICBlbmNhcHN1bGF0aW9uIG9uIHRoZSBhY2Nlc3MgbG9vcCBi eSBzcGVjaWZ5aW5nIGEgdmFsdWUgb2YgMCAoTkEpIGZvciB0aGUgDQogICAgIHR3byBlbmNhcHN1 bGF0aW9uIGZpZWxkcy4gICAgDQoNCiAgICAgNS40LjIgTGluZSBDb25maWd1cmF0aW9uICANCg0K ICAgICBUaGUgQlJBUyB1c2VzIGV4dGVuc2lvbiBibG9jayBpbiB0aGUgUG9ydCBNYW5hZ2VtZW50 IG1lc3NhZ2VzIHRvIGNvbnZleSANCiAgICAgc2VydmljZSBhdHRyaWJ1dGVzIG9mIHRoZSBEU0wg bGluZXMgdG8gdGhlIERTTEFNLiBUTFZzIGFyZSBkZWZpbmVkIGZvciAgICAgIA0KICAgICBEU0wg bGluZSBpZGVudGlmaWNhdGlvbiBhbmQgc2VydmljZSBkYXRhIGZvciB0aGUgRFNMIGxpbmVzLiBQ b3J0IG51bWJlciANCiAgICAgaXMgc2V0IHRvIDAgaW4gdGhlIG1lc3NhZ2UuIEEgbmV3IGFjdGlv biB0eXBlICJDb25maWd1cmUgQ29ubmVjdGlvbiANCiAgICAgU2VydmljZSBEYXRhIiAodmFsdWUg MHg4KSBpcyBkZWZpbmVkLiBUaGUgIkZ1bmN0aW9uIiBmaWVsZCBpcyBzZXQgdG8gdGhlIA0KICAg ICBhY3Rpb24gdHlwZS4gVGhpcyBhY3Rpb24gdHlwZSBpbmRpY2F0ZXMgdG8gdGhlIGRldmljZSBi ZWluZyBjb250cm9sbGVkIA0KICAgICAoYWNjZXNzLW5vZGUgaS5lLiBEU0xBTSkgdG8gYXBwbHkg c2VydmljZSBjb25maWd1cmF0aW9uIGRhdGEgY29udGFpbmVkIA0KICAgICBpbiB0aGUgZXh0ZW5z aW9uIHZhbHVlIChUTFZzKSwgdG8gdGhlIERTTCBsaW5lIChpZGVudGlmaWVkIGJ5IG9uZSBvZiB0 aGUgDQogICAgIFRMVnMgaW4gdGhlIGV4dGVuc2lvbiB2YWx1ZSkuIFRoZSBUZWNoIFR5cGUgZmll bGQgaXMgZXh0ZW5kZWQgd2l0aCBuZXcgDQogICAgIHR5cGUgIkRTTCIuIFRoZSB2YWx1ZSBmb3Ig dGhpcyBmaWVsZCBpcyAweDA1LiANCg0KICAgICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAg ICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMyANCiAgICAgICAgIDAgMSAyIDMg NCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAN CiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsgDQogICAgICAgIHwgVmVycyAgfCAgU3ViICB8IE1lc3NhZ2UgVHlw ZSAgfCBSZXN1bHR8ICAgICAgICBDb2RlICAgICAgICAgICB8IA0KICAgICAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAN CiAgICAgICAgfCBQYXJ0aXRpb24gSUQgIHwgICAgICAgICAgICBUcmFuc2FjdGlvbiBJZGVudGlm aWVyICAgICAgICAgICAgIHwgDQogICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0KICAgICAgICB8SXwgICAgICBT dWJNZXNzYWdlIE51bWJlciAgICAgIHwgICAgICAgICAgIExlbmd0aCAgICAgICAgICAgICAgfCAN CiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsgDQogICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFBvcnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAN CiAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICBQb3J0IFNlc3Npb24gTnVtYmVyICAgICAg ICAgICAgICAgICAgICAgIHwgDQogICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0KICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgRXZlbnQgU2VxdWVuY2UgTnVtYmVyICAgICAgICAgICAgICAgICAgICAgfCAN CiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsgDQogICAgICAgIHxSfHh8eHx4fHh8eHx4fHh8ICAgRHVyYXRpb24g ICAgfCAgICBGdW5jdGlvbiAgIHwgWC1GdW5jdGlvbiAgICB8IA0KICAgICAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAN CiAgICAgICAgfCAgICAgICAgICAgRXZlbnQgRmxhZ3MgICAgICAgICB8ICAgICAgICBGbG93IENv bnRyb2wgRmxhZ3MgICAgIHwgDQogICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0KICAgICAgICB8eHx4fHh8eHx4 fHh8eHx4fCBNZXNzYWdlIFR5cGUgIHwgICBUZWNoIFR5cGUgICB8IEJsb2NrIExlbmd0aCAgfCAN CiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsgDQogICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICB+ICAgICAgICAg ICAgICAgICAgICAgICAgIEV4dGVuc2lvbiBWYWx1ZSAgICAgICAgICAgICAgICAgICAgICAgfiAN CiAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgDQogICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0KICAgICAgDQoNCiAgICAgIA0K ICAgICAgDQogICAgIFdhZGh3YSBldC5hbCAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAyOCwg MjAwNiAgICAgICAgICAgICAgW1BhZ2UgMjddIA0KICAgICAgICAgDQoMICAgICBJbnRlcm5ldC1E cmFmdCAgICAgIGRyYWZ0LXdhZGh3YS1nc21wLWwyY29udHJvbC1jb25maWd1cmF0aW9uLTAxICAg ICAgICBNYXJjaCAyMDA2IA0KICAgICAgICAgDQoNCiAgICAgIA0KDQogICAgICAgICAgIA0KDQog ICAgICAgIFRoZSBmb3JtYXQgb2YgdGhlICJFeHRlbnNpb24gVmFsdWUiIGZpZWxkIGlzIGFzIGZv bGxvd3MgOiANCiAgICAgICAgIA0KICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCiAgICAgICAgfCAgICAgICAg ICAgICAjIG9mIFRMVnMgICAgICAgICB8IEV4dGVuc2lvbiBCbG9jayBsZW5ndGggKGJ5dGVzKXwg DQogICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rIA0KICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgfiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH4g DQogICAgICAgIH4gICAgICAgICAgICAgICAgICAgICAgICAgICAgVExWcyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB+ICANCiAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r IA0KICAgICAgDQoNCiAgICAgICAgVGhlICJFeHRlbnNpb24gVmFsdWUiIGZpZWxkIGNvbnRhaW5z IG9uZSBvciBtb3JlIFRMVnMgY29udGFpbmluZyBEU0wgDQogICAgICAgIGxpbmUgaWRlbnRpZmll ciBhbmQgZGVzaXJlZCBzZXJ2aWNlIGF0dHJpYnV0ZXMgb2YgdGhlIHRoZSBEU0wgbGluZS4gDQog ICAgICAgIEZpcnN0IDIgYnl0ZSBvZiB0aGUgIkV4dGVuc2lvbiBWYWx1ZSIgY29udGFpbnMgdGhl IG51bWJlciBvZiBUTFZzIA0KICAgICAgICB0aGF0IGZvbGxvdy4gVGhlIG5leHQgMiBieXRlcyBj b250YWluIHRoZSB0b3RhbCBsZW5ndGggb2YgdGhlIA0KICAgICAgICBleHRlbnNpb24gYmxvY2sg aW4gYnl0ZXMgKGV4aXN0aW5nICJCbG9jayBMZW5ndGgiIGZpZWxkIGluIHRoZSBHU01QIA0KICAg ICAgICBtZXNzYWdlIGlzIGxpbWl0ZWQgdG8gMjU1IGJ5dGVzIGFuZCBpcyBub3Qgc3VmZmljaWVu dCkuIA0KDQogICAgICAgIEdlbmVyYWwgZm9ybWF0IG9mIGEgVExWIGlzIDogIA0KDQogICAgICAg ICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEgDQogICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICAgICAgICANCiAgICAgICAgfCAgICAgICAgICAg IFR5cGUgICAgICAgICAgICAgICB8ICAgICAgICAgICAgIExlbmd0aCAgICAgICAgICAgIHwgDQog ICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rICAgICAgICAgICAgIA0KICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAg fiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIH4gDQogICAgICAgIH4gICAgICAgICAgICAgICAgICAgICAgICAgICBWYWx1ZSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB+ICANCiAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rIA0KICAgICAgICAgDQoNCiAgICAgICAgVGhlIHZhbHVlIGZpZWxkIGlzIHBhZGRl ZCB0byBhIDQtb2N0ZXQgYWxpZ25tZW50LiBUaGUgTGVuZ3RoIGZpZWxkIGluIA0KICAgICAgICBl YWNoIFRMViBjb250YWlucyB0aGUgYWN0dWFsIG51bWJlciBvZiBieXRlcyBpbiB0aGUgVExWIChu b3QgDQogICAgICAgIGluY2x1ZGluZyB0aGUgcGFkZGluZyBpZiBwcmVzZW50KS4gSWYgYSBUTFYg aXMgbm90IHVuZGVyc3Rvb2QgYnkgdGhlIA0KICAgICAgICBhY2Nlc3Mtbm9kZSwgaXQgaXMgc2ls ZW50bHkgaWdub3JlZC4gRGVwZW5kaW5nIHVwb24gdGhlIGRlcGxveW1lbnQgDQogICAgICAgIHNj ZW5hcmlvLCB0aGUgQlJBUyBtYXkgc3BlY2lmeSAiQWNjZXNzIExvb3AgQ2lyY3VpdC1JRCIgb3Ig dGhlIA0KICAgICAgICAiQWNjZXNzIEFnZ3JlZ2F0aW9uIENpcmN1aXQtSUQpIGFzIGRlZmluZWQg aW4gc2VjdGlvbiA1LjQuMS4gDQogICAgICAgIEZvbGxvd2luZyBUTFZzIGNhbiBhcHBlYXIgaW4g dGhpcyBtZXNzYWdlOiANCg0KICAgICAgICBvICBUeXBlIChBY2Nlc3MtTG9vcC1DaXJjdWl0LUlE ID0gMHgwMSkgOiBkZWZpbmVkIGluIHNlY3Rpb24gNS40LjEgIA0KDQoNCiAgICAgIA0KICAgICAg DQogICAgIFdhZGh3YSBldC5hbCAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAyOCwgMjAwNiAg ICAgICAgICAgICAgW1BhZ2UgMjhdIA0KICAgICAgICAgDQoMICAgICBJbnRlcm5ldC1EcmFmdCAg ICAgIGRyYWZ0LXdhZGh3YS1nc21wLWwyY29udHJvbC1jb25maWd1cmF0aW9uLTAxICAgICAgICBN YXJjaCAyMDA2IA0KICAgICAgICAgDQoNCiAgICAgICAgbyAgVHlwZSAoQWNjZXNzLUFnZ3JlZ2F0 aW9uLUNpcmN1aXQtSUQtQmluYXJ5ID0gMHgwMik6IGRlZmluZWQgaW4gDQogICAgICAgICAgIHNl Y3Rpb24gNS40LjEuIA0KDQogICAgICAgIG8gIFR5cGUgKEFjY2Vzcy1BZ2dyZWdhdGlvbi1DaXJj dWl0LUlELUFTQ0lJID0gMHgwMykgOiBkZWZpbmVkIGluIA0KICAgICAgICAgICBzZWN0aW9uIDUu NC4xLiAgICAgIA0KDQogICAgICAgIG8gIFR5cGUgKFNlcnZpY2UtUHJvZmlsZS1OYW1lID0gMHgw NSkgOiBSZWZlcmVuY2UgdG8gYSBwcmUtY29uZmlndXJlZCANCiAgICAgICAgICAgcHJvZmlsZSBv biB0aGUgRFNMQU0gdGhhdCBjb250YWlucyBzZXJ2aWNlIHNwZWNpZmljIGRhdGEgZm9yIHRoZSAN CiAgICAgICAgICAgc3Vic2NyaWJlci4gICAgDQoNCiAgICAgICAgICAgTGVuZ3RoIDogKHVwdG8g NjQgYnl0ZXMpIA0KDQogICAgICAgICAgIFZhbHVlICA6IEFTQ0lJIHN0cmluZyBjb250YWluaW5n IHRoZSBwcm9maWxlIG5hbWUgKEJSQVMgbGVhcm5zICANCiAgICAgICAgICAgZnJvbSBhIHBvbGlj eSBzZXJ2ZXIgYWZ0ZXIgYSBzdWJzY3JpYmVyIGlzIGF1dGhvcml6ZWQpLiANCg0KICAgICAgICBJ biBmdXR1cmUsIG1vcmUgVExWcyBNQVkgYmUgZGVmaW5lZCBmb3IgaW5kaXZpZHVhbCBzZXJ2aWNl IGF0dHJpYnV0ZXMgDQogICAgICAgIG9mIGEgRFNMIGxpbmUgKGUuZy4gcmF0ZXMsIGludGVybGVh dmluZyBkZWxheSwgIG11bHRpY2FzdCBjaGFubmVsIA0KICAgICAgICBlbnRpdGxlbWVudCBhY2Nl c3MtbGlzdCBldGMpLiANCg0KICAgICAgICAgDQoNCiAgICAgNS40LjMgT0FNIA0KDQogICAgICAg IEdTTVAgIlBvcnQgTWFuYWdlbWVudCIgbWVzc2FnZSAodHlwZSAzMikgU0hPVUxEIGJlIHVzZWQg YnkgdGhlIEJSQVMgDQogICAgICAgIHRvIHRyaWdnZXIgYWNjZXNzIG5vZGUgdG8gcnVuIGEgbG9v cGJhY2sgdGVzdCBvbiB0aGUgbG9jYWwgbG9vcC4gVGhlIA0KICAgICAgICBtZXNzYWdlIGZvcm1h dCBpcyBkZWZpbmVkIGluIHNlY3Rpb24gNS40LjIuIFRoZSB2ZXJzaW9uIGZpZWxkIFNIT1VMRCAN CiAgICAgICAgYmUgc2V0IHRvIDMgYW5kIHN1Yi12ZXJzaW9uIGZpZWxkIFNIT1VMRCBiZSBzZXQg dG8gMS4gVGhlIHJlbWFpbmluZyANCiAgICAgICAgZmllbGRzIGluIHRoZSBHU01QIGhlYWRlciBo YXZlIHN0YW5kYXJkIHNlbWFudGljcy4gVGhlIGZ1bmN0aW9uIHR5cGUgDQogICAgICAgIHVzZWQg aW4gdGhlIHJlcXVlc3QgbWVzc2FnZSBTSE9VTEQgYmUgc2V0IHRvICJyZW1vdGUgbG9vcGJhY2si ICh0eXBlIA0KICAgICAgICA9IDB4MDkpLiBUaGUgcG9ydCwgInBvcnQgc2Vzc2lvbiBudW1iZXIi LCAiZXZlbnQgc2VxdWVuY2UgbnVtYmVyIiwgDQogICAgICAgIGR1cmF0aW9uLCAiZXZlbnQgZmxh Z3MiLCAiZmxvdyBjb250cm9sIGZsYWdzIiBhbmQgY29kZSBmaWVsZHMgU0hPVUxEIA0KICAgICAg ICBhbGwgYmUgc2V0IHRvIDAuIFRoZSByZXN1bHQgZmllbGQgU0hPVUxEIGJlIHNldCB0byAiQWNr QWxsIiB0byANCiAgICAgICAgaW5kaWNhdGUgcmVxdWlyZW1lbnQgZm9yIHRoZSBhY2Nlc3Mgbm9k ZSB0byBzZW5kIGEgc3VjY2VzcyBmb3IgDQogICAgICAgIGZhaWx1cmUgcmVzcG9uc2UuIFRoZSB0 cmFuc2FjdGlvbiBJRCBTSE9VTEQgY29udGFpbiBhIHNlcXVlbmNlIG51bWJlciANCiAgICAgICAg aW5zZXJ0ZWQgYnkgdGhlIEJSQVMgaW4gZWFjaCByZXF1ZXN0IHRoYXQgaXQgZ2VuZXJhdGVzLiBU aGUgZXh0ZW5zaW9uIA0KICAgICAgICBmaWVsZCBmb3JtYXQgaXMgYWxzbyBkZWZpbmVkIGFib3Zl IGluIHNlY3Rpb24gNS40LjIuIFRoZSBleHRlbnNpb24gDQogICAgICAgIHZhbHVlIGZpZWxkIGNh biBjb250YWluIG9uZSBvciBtb3JlIFRMVnMgaW5jbHVkaW5nIHRoZSBhY2Nlc3MtbGluZSANCiAg ICAgICAgaWRlbnRpZmllciBvbiB0aGUgRFNMQU0gYW5kIE9BTSB0ZXN0IGNoYXJhY3RlcmlzdGlj cyBkZXNpcmVkIGJ5IHRoZSANCiAgICAgICAgQlJBUy4gIA0KDQogICAgICAgIFRoZSBUTFYgZm9y bWF0IGlzIGRlZmluZWQgYWJvdmUgaW4gc2VjdGlvbiA1LjQuMi4gVGhlIHZhbHVlIGZpZWxkIGlz IA0KICAgICAgICBwYWRkZWQgdG8gYSA0LW9jdGV0IGFsaWdubWVudC4gVGhlIExlbmd0aCBmaWVs ZCBpbiBlYWNoIFRMViBjb250YWlucyANCiAgICAgICAgdGhlIGFjdHVhbCBudW1iZXIgb2YgYnl0 ZXMgaW4gdGhlIFRMViAobm90IGluY2x1ZGluZyB0aGUgcGFkZGluZyBpZiANCiAgICAgICAgcHJl c2VudCkuIElmIGEgVExWIGlzIG5vdCB1bmRlcnN0b29kIGJ5IHRoZSBCUkFTLCBpdCBpcyBzaWxl bnRseSANCiAgICAgICAgaWdub3JlZC4gRGVwZW5kaW5nIHVwb24gdGhlIGRlcGxveW1lbnQgc2Nl bmFyaW8sIHRoZSBCUkFTIG1heSBzcGVjaWZ5IA0KICAgICAgICAiQWNjZXNzIExvb3AgQ2lyY3Vp dC1JRCIgb3IgdGhlICJBY2Nlc3MgQWdncmVnYXRpb24gQ2lyY3VpdC1JRCkgYXMgDQogICAgICAg IGRlZmluZWQgaW4gc2VjdGlvbiA1LjQuMS4gRm9sbG93aW5nIFRMVnMgY2FuIGFwcGVhciBpbiB0 aGlzIG1lc3NhZ2U6IA0KICAgICAgDQogICAgICANCiAgICAgV2FkaHdhIGV0LmFsICAgICAgICAg IEV4cGlyZXMgU2VwdGVtYmVyIDI4LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSAyOV0gDQogICAg ICAgICANCgwgICAgIEludGVybmV0LURyYWZ0ICAgICAgZHJhZnQtd2FkaHdhLWdzbXAtbDJjb250 cm9sLWNvbmZpZ3VyYXRpb24tMDEgICAgICAgIE1hcmNoIDIwMDYgDQogICAgICAgICANCg0KICAg ICAgICBvICBUeXBlIChBY2Nlc3MtTG9vcC1DaXJjdWl0LUlEID0gMHgwMSkgOiBkZWZpbmVkIGlu IHNlY3Rpb24gNS40LjEgIA0KDQogICAgICAgIG8gIFR5cGUgKEFjY2Vzcy1BZ2dyZWdhdGlvbi1D aXJjdWl0LUlELUJpbmFyeSA9IDB4MDIpOiBkZWZpbmVkIGluIA0KICAgICAgICAgICBzZWN0aW9u IDUuNC4xLiANCg0KICAgICAgICBvICBUeXBlIChBY2Nlc3MtQWdncmVnYXRpb24tQ2lyY3VpdC1J RC1BU0NJSSA9IDB4MDMpIDogZGVmaW5lZCBpbiANCiAgICAgICAgICAgc2VjdGlvbiA1LjQuMS4g IA0KDQogICAgICAgIG8gIFR5cGUgKE9BTS1Mb29wYmFjay1UZXN0LVBhcmFtZXRlcnMgPSAweDA3 KSA6IFBhcmFtZXRlcnMgcmVsYXRlZCB0byAgDQogICAgICAgICAgIGxvb3BiYWNrIHRlc3QuIFRo aXMgaXMgYW4gb3B0aW9uYWwgVExWLiBJZiB0aGlzIFRMViBpcyBub3QgcHJlc2VudCANCiAgICAg ICAgICAgaW4gdGhlIHJlcXVlc3QgbWVzc2FnZSwgdGhlIERTTEFNIFNIT1VMRCB1c2UgbG9jYWxs eSBkZXRlcm1pbmVkIA0KICAgICAgICAgICBkZWZhdWx0IHZhbHVlcyBmb3IgdGhlIHRlc3QgcGFy YW1ldGVycy4gIA0KDQogICAgICAgICAgIExlbmd0aDogNCBieXRlcyANCg0KICAgICAgICAgICBW YWx1ZSAgOiB0d28gMSBieXRlIG51bWJlcnMgKGxpc3RlZCBpbiBvcmRlciBvZiBtb3N0IHRvIGxl YXN0ICANCiAgICAgICAgICAgc2lnbmlmaWNhbnQpICANCg0KICAgICAgICAgICAgbyAgQ291bnQg KDEgYnl0ZSkgOiBOdW1iZXIgb2YgbG9vcGJhY2sgY2VsbHMvbWVzc2FnZXMgdGhhdCBzaG91bGQg DQogICAgICAgICAgICAgICBiZSBnZW5lcmF0ZWQgb24gdGhlIGxvY2FsIGxvb3AgYXMgcGFydCBv ZiB0aGUgbG9vcGJhY2sgdGVzdC4gDQogICAgICAgICAgICAgICBUaGUgQlJBUyBTSE9VTEQgcmVz dHJpY3QgdGhlICJjb3VudCIgdG8gYmUgZ3JlYXRlciB0aGFuIDAgYW5kIA0KICAgICAgICAgICAg ICAgbGVzcyB0aGFuIG9yIGVxdWFsIHRvIDMyLiBUaGUgRFNMQU0gU0hPVUxEIGRpc2NhcmQgdGhl IHJlcXVlc3QgDQogICAgICAgICAgICAgICBmb3IgYSBsb29wYmFjayB0ZXN0LCBpZiB0aGUgcmVj ZWl2ZWQgdGVzdCBwYXJhbWV0ZXJzIGNvbnRhaW4gDQogICAgICAgICAgICAgICBhbiBvdXQgb2Yg cmFuZ2UgdmFsdWUgZm9yIHRoZSAiY291bnQiIGZpZWxkLiBUaGUgRFNMQU0gTUFZIA0KICAgICAg ICAgICAgICAgb3B0aW9uYWxseSBzZW5kIGEgZmFpbHVyZSByZXNwb25zZSB0byB0aGUgQlJBUyB3 aXRoIHRoZSBjb2RlIA0KICAgICAgICAgICAgICAgImludmFsaWQgdGVzdCBwYXJhbWV0ZXIiLiAg ICAgICAgIA0KDQogICAgICAgICAgICBvICBUaW1lb3V0ICgxIGJ5dGUpIDogVXBwZXIgYm91bmQg b24gdGhlIHRpbWUgaW4gc2Vjb25kcyB0aGF0IHRoZSANCiAgICAgICAgICAgICAgIEJSQVMgd291 bGQgd2FpdCBmb3IgYSByZXNwb25zZSBmcm9tIHRoZSBEU0xBTS4gSWYgdGhlIHRvdGFsIA0KICAg ICAgICAgICAgICAgdGltZSB0YWtlbiBieSB0aGUgRFNMQU0gdG8gY29tcGxldGUgYSB0ZXN0IHdp dGggcmVxdWVzdGVkIA0KICAgICAgICAgICAgICAgcGFyYW1ldGVycywgZXhjZWVkcyB0aGUgc3Bl Y2lmaWVkICJ0aW1lb3V0IiB2YWx1ZSwgaXQgY2FuIA0KICAgICAgICAgICAgICAgY2hvb3NlIHRv IG9taXQgdGhlIGdlbmVyYXRpb24gb2YgYSByZXNwb25zZSB0byB0aGUgQlJBUy4gRFNMQU0gDQog ICAgICAgICAgICAgICBTSE9VTEQgdXNlIGEgbG9jYWxseSBkZXRlcm1pbmVkIHZhbHVlIGZvciB0 aGUgInRpbWVvdXQiLCBpZiANCiAgICAgICAgICAgICAgIHRoZSByZWNlaXZlZCB2YWx1ZSBvZiB0 aGUgInRpbWVvdXQiIHBhcmFtZXRlciBpcyAwLiANCg0KICAgICAgICAgDQoNCiAgICAgICAgbyAg VHlwZSAoT3BhcXVlLURhdGEgPSAweDA4KSA6IFRoaXMgaXMgYW4gb3B0aW9uYWwgVExWLiBJZiBw cmVzZW50IGluIA0KICAgICAgICAgICB0aGUgcmVxdWVzdCBtZXNzYWdlLCB0aGUgRFNMQU0gU0hP VUxEIHJlZmxlY3QgaXQgYmFjayBpbiB0aGUgDQogICAgICAgICAgIHJlc3BvbnNlIHVubW9kaWZp ZWQuIA0KDQogICAgICAgICAgIExlbmd0aCA6IDggYnl0ZXMgDQoNCiAgICAgICAgICAgVmFsdWUg OiBUd28gMzIgYml0IGludGVnZXJzIGluc2VydGVkIGJ5IHRoZSBCUkFTIChub3QgdG8gYmUgDQog ICAgICAgICAgIGludGVycHJldGVkIGJ5IHRoZSBEU0xBTSwgYnV0IGp1c3QgcmVmbGVjdGVkIGJh Y2sgaW4gdGhlIA0KICAgICAgICAgICByZXNwb25zZSkuIA0KDQogICAgICANCiAgICAgIA0KICAg ICBXYWRod2EgZXQuYWwgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjgsIDIwMDYgICAgICAg ICAgICAgIFtQYWdlIDMwXSANCiAgICAgICAgIA0KDCAgICAgSW50ZXJuZXQtRHJhZnQgICAgICBk cmFmdC13YWRod2EtZ3NtcC1sMmNvbnRyb2wtY29uZmlndXJhdGlvbi0wMSAgICAgICAgTWFyY2gg MjAwNiANCiAgICAgICAgIA0KDQogICAgICAgIFRoZSBhY2Nlc3Mgbm9kZSBnZW5lcmF0ZXMgYSBz dWNjZXNzIG9yIGZhaWx1cmUgcmVzcG9uc2Ugd2hlbiBpdCBkZWVtcyANCiAgICAgICAgdGhlIGxv b3BiYWNrIHRlc3QgdG8gYmUgY29tcGxldGUuICJQb3J0IE1hbmFnZW1lbnQiIG1lc3NhZ2UgKHR5 cGUgMzIpIA0KICAgICAgICBpcyB1c2VkLiBUaGUgcmVzdWx0IGZpZWxkIFNIT1VMRCBiZSBzZXQg dG8gc3VjY2VzcyBvciBmYWlsdXJlLiBUaGUgDQogICAgICAgIGZ1bmN0aW9uIHR5cGUgU0hPVUxE IGJlIHNldCB0byAweDA5LiBUaGUgdHJhbnNhY3Rpb24gSUQgU0hPVUxEIGJlIA0KICAgICAgICBj b3BpZWQgZnJvbSB0aGUgc2VxdWVuY2UgbnVtYmVyIGNvbnRhaW5lZCBpbiB0aGUgY29ycmVzcG9u ZGluZyANCiAgICAgICAgcmVxdWVzdC4gVGhlIG90aGVyIHBhcmFtZXRlcnMgbm90IGV4cGxpY2l0 bHkgZGVmaW5lZCBoZXJlIFNIT1VMRCBiZSANCiAgICAgICAgc2V0IGFzIHNwZWNpZmllZCBpbiB0 aGUgcmVxdWVzdCBtZXNzYWdlIGFib3ZlLiBUaGUgY29kZSBmaWVsZCBTSE9VTEQgDQogICAgICAg IGJlIHNldCB0byBhIHZhbHVlIGluIHRoZSByYW5nZSAweDUwMCB0byAweDVmZiAodG8gYmUgcmVz ZXJ2ZWQgd2l0aCANCiAgICAgICAgSUFOQSkgdG8gaW5kaWNhdGUgdGhlIHN0YXR1cyBvZiB0aGUg ZXhlY3V0ZWQgdGVzdC4gVGhlIHZhbGlkIHZhbHVlcyANCiAgICAgICAgZGVmaW5lZCBhcmUgKGNh biBiZSBleHRlbmRlZCBpbiBmdXR1cmUpOiANCg0KICAgICAgICAgICAgICAweDUwMCA6IFNwZWNp ZmllZCBhY2Nlc3MgbGluZSBkb2VzIG5vdCBleGlzdC4gDQoNCiAgICAgICAgICAgICAgMHg1MDEg OiBMb29wYmFjayB0ZXN0IHRpbWVkIG91dC4gDQoNCiAgICAgICAgICAgICAgMHg1MDIgOiBSZXNl cnZlZCANCg0KICAgICAgICAgICAgICAweDUwMyA6IERTTCBsaW5lIHN0YXR1cyBzaG93dGltZS4g DQoNCiAgICAgICAgICAgICAgMHg1MDQgOiBEU0wgbGluZSBzdGF0dXMgaWRsZS4gDQoNCiAgICAg ICAgICAgICAgMHg1MDUgOiBEU0wgbGluZSBzdGF0dXMgc2lsZW50LiANCg0KICAgICAgICAgICAg ICAweDUwNiA6IERTTCBsaW5lIHN0YXR1cyB0cmFpbmluZy4gDQoNCiAgICAgICAgICAgICAgMHg1 MDcgOiBEU0wgbGluZSBpbnRlZ3JpdHkgZXJyb3IuIA0KDQogICAgICAgICAgICAgIDB4NTA4IDog RFNMQU0gcmVzb3VyY2Ugbm90IGF2YWlsYWJsZS4gDQoNCiAgICAgICAgICAgICAgMHg1MDkgOiBJ bnZhbGlkIHRlc3QgcGFyYW1ldGVyLiANCg0KICAgICBUaGUgRXh0ZW5zaW9uIHZhbHVlIGNhbiBj b250YWluIG9uZSBvciBtb3JlIFRMVnMgaW5jbHVkaW5nIHRoZSBUTFYgdG8gDQogICAgIGlkZW50 aWZ5IHRoZSBhY2Nlc3MgbGluZSBvbiB3aGljaCB0aGUgdGVzdCB3YXMgcGVyZm9ybWVkLCBhbmQg ZGV0YWlscyANCiAgICAgZnJvbSBleGVjdXRpbmcgdGhlIHRlc3QuIFRoZSBhY2Nlc3MgbGluZSBp ZGVudGlmaWVyIFNIT1VMRCBiZSBiZSANCiAgICAgaWRlbnRpY2FsIHRvIHdoYXQgd2FzIGNvbnRh aW5lZCBpbiB0aGUgcmVxdWVzdC4gVGhlIHJlbGV2YW50IFRMVnMgYXJlOiANCg0KICAgICAgICBv ICBUeXBlIChBY2Nlc3MtTG9vcC1DaXJjdWl0LUlEID0gMHgwMSkgOiBkZWZpbmVkIGluIHNlY3Rp b24gNS40LjEgIA0KDQogICAgICAgIG8gIFR5cGUgKEFjY2Vzcy1BZ2dyZWdhdGlvbi1DaXJjdWl0 LUlELUJpbmFyeSA9IDB4MDIpOiBkZWZpbmVkIGluIA0KICAgICAgICAgICBzZWN0aW9uIDUuNC4x LiANCg0KICAgICAgICBvICBUeXBlIChBY2Nlc3MtQWdncmVnYXRpb24tQ2lyY3VpdC1JRC1BU0NJ SSA9IDB4MDMpIDogZGVmaW5lZCBpbiANCiAgICAgICAgICAgc2VjdGlvbiA1LjQuMS4gIA0KDQog ICAgICAgIG8gIFR5cGUgKE9wYXF1ZS1EYXRhID0gMHgwOCkgOiBEYXRhIGluc2VydGVkIGJ5IHRo ZSBCUkFTIGluIHRoZSANCiAgICAgICAgICAgcmVxdWVzdCByZWZsZWN0ZWQgYmFjayBieSB0aGUg RFNMQU0uIA0KDQogICAgICANCiAgICAgIA0KICAgICBXYWRod2EgZXQuYWwgICAgICAgICAgRXhw aXJlcyBTZXB0ZW1iZXIgMjgsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDMxXSANCiAgICAgICAg IA0KDCAgICAgSW50ZXJuZXQtRHJhZnQgICAgICBkcmFmdC13YWRod2EtZ3NtcC1sMmNvbnRyb2wt Y29uZmlndXJhdGlvbi0wMSAgICAgICAgTWFyY2ggMjAwNiANCiAgICAgICAgIA0KDQogICAgICAg ICAgIExlbmd0aCA6IDggYnl0ZXMgDQoNCiAgICAgICAgICAgVmFsdWUgOiBUd28gMzIgYml0IGlu dGVnZXJzIGFzIHJlY2VpdmVkIGluIHRoZSByZXF1ZXN0IChvcGFxdWUgdG8gDQogICAgICAgICAg IHRoZSBEU0xBTSkuIA0KDQogICAgICAgIG8gIFR5cGUgKE9BTS1Mb29wYmFjay1UZXN0LVJlc3Bv bnNlLVN0cmluZyA9IDB4MDkpIA0KDQogICAgICAgICAgIExlbmd0aCAodXB0byAxMjggYnl0ZXMp IA0KDQogICAgICAgICAgIFZhbHVlIDogU3VpdGFibHkgZm9ybWF0dGVkIEFTQ0lJIHN0cmluZyBj b250YWluaW5nIHVzZWZ1bCBkZXRhaWxzIA0KICAgICAgICAgICBhYm91dCB0aGUgdGVzdCB0aGF0 IHRoZSBCUkFTIHdpbGwgZGlzcGxheSBmb3IgdGhlIG9wZXJhdG9yLCANCiAgICAgICAgICAgZXhh Y3RseSBhcyByZWNlaXZlZCBmcm9tIHRoZSBEU0xBTSAobm8gbWFuaXB1bGF0aW9uL2ludGVycHJl dGF0aW9uIA0KICAgICAgICAgICBieSB0aGUgQlJBUykuIFRoaXMgaXMgYW4gb3B0aW9uYWwgVExW LCBidXQgaXQgaXMgc3Ryb25nbHkgDQogICAgICAgICAgIHJlY29tbWVuZGVkLCB0aGF0IGluIGNh c2Ugb2YgQVRNIGJhc2VkIGxvY2FsIGxvb3AsIHRoZSBEU0xBTSBhdCANCiAgICAgICAgICAgdGhl IHZlcnkgbGVhc3QgaW5kaWNhdGVzIHZpYSB0aGlzIFRMViwgdGhlIHRvdGFsIGxvb3BiYWNrIGNl bGxzIA0KICAgICAgICAgICBnZW5lcmF0ZWQgYW5kIHRoZSB0b3RhbCBsb29wYmFjayBjZWxscyBz dWNjZXNzZnVsbHkgcmVjZWl2ZWQgYXMgDQogICAgICAgICAgIHBhcnQgb2YgZXhlY3V0aW5nIHRo ZSByZXF1ZXN0ZWQgbG9vcGJhY2sgdGVzdC4gICAgICANCg0KICAgICAgICAgICAgIA0KDQogICAg IDUuNSBBVE0tc3BlY2lmaWMgY29uc2lkZXJhdGlvbnMgDQoNCiAgICAgICAgVGhlIHRvcG9sb2d5 IGRpc2NvdmVyeSBhbmQgbGluZSBjb25maWd1cmF0aW9uIGludm9sdmUgdGhlIERTTCBsaW5lIA0K ICAgICAgICBhdHRyaWJ1dGVzLiBGb3IgQVRNIGJhc2VkIGFjY2VzcyBuZXR3b3JrcywgdGhlIERT TCBsaW5lIG9uIHRoZSBEU0xBTSANCiAgICAgICAgaXMgaWRlbnRpZmllZCBieSB0aGUgcG9ydCBh bmQgUFZQL1BWQyBjb3JyZXNwb25kaW5nIHRvIHRoZSANCiAgICAgICAgc3Vic2NyaWJlci4gVGhl IERTTEFNcyBhcmUgY29ubmVjdGVkIHRvIHRoZSBCUkFTIHZpYSBhbiBBVE0gYWNjZXNzIA0KICAg ICAgICBhZ2dyZWdhdGlvbiBuZXR3b3JrLiBTaW5jZSwgdGhlICAgRFNMQU0gKGFjY2Vzcy1ub2Rl KSBpcyBub3QgZGlyZWN0bHkgDQogICAgICAgIGNvbm5lY3RlZCB0byB0aGUgQlJBUywgdGhlIEJS QVMgbmVlZHMgYSBtZWNoYW5pc20gdG8gbGVhcm4gdGhlIERTTCANCiAgICAgICAgbGluZSBpZGVu dGlmaWVyIChtb3JlIGdlbmVyYWxseSByZWZlcnJlZCB0byBhcyAiQWNjZXNzIExvb3AgQ2lyY3Vp dC0NCiAgICAgICAgSUQiKSBjb3JyZXNwb25kaW5nIHRvIGEgc3Vic2NyaWJlci4gVGhlICJBY2Nl c3MgbG9vcCBjaXJjdWl0LUlEIiBoYXMgDQogICAgICAgIG5vIGxvY2FsIHNpZ25pZmljYW5jZSBv biB0aGUgQlJBUy4gVGhlIEdTTVAgbWVzc2FnZXMgZm9yIHRvcG9sb2d5IA0KICAgICAgICBkaXNj b3ZlcnkgYW5kIGxpbmUgY29uZmlndXJhdGlvbiBjYXJyeSBvcGFxdWUgIkFjY2VzcyBsb29wIENp cmN1aXQtDQogICAgICAgIElEIiB3aGljaCBoYXMgb25seSBsb2NhbCBzaWduaWZpY2FuY2Ugb24g dGhlIERTTEFNcy4gIA0KDQogICAgICAgIFRoZSBhY2Nlc3MgbG9vcCBjaXJjdWl0IGlkZW50aWZp ZXIgY2FuIGJlIGNhcnJpZWQgYXMgYW4gQVNDSUkgc3RyaW5nIA0KICAgICAgICBpbiB0aGUgR1NN UCBtZXNzYWdlcy4gVGhpcyBhbGxvd3MgbGF5ZXIyIGNvbnRyb2wgcHJvdG9jb2wgdG8gYmUgDQog ICAgICAgIGRlY291cGxlZCBmcm9tIHRoZSBzcGVjaWZpY3Mgb2YgdGhlIHVuZGVybHlpbmcgYWNj ZXNzIHRlY2hub2xvZ3kgDQogICAgICAgIGJlaW5nIGNvbnRyb2xsZWQuIE9uIHRoZSBvdGhlciBo YW5kLCB0aGlzIHJlcXVpcmVzIGEgQlJBUyBtZWNoYW5pc20gDQogICAgICAgIGJ5IHdoaWNoIHN1 Y2ggaWRlbnRpZmllciBjYW4gYmUgY29ycmVsYXRlZCB0byB0aGUgY29udGV4dCBvZiBhbiANCiAg ICAgICAgImFnZ3JlZ2F0aW9uIG5ldHdvcmsiIGZhY2luZyBJUCBpbnRlcmZhY2UgKGNvcnJlc3Bv bmRpbmcgdG8gdGhlIA0KICAgICAgICBzdWJzY3JpYmVyKSBvbiB0aGUgQlJBUy4gVGhpcyB3b3Vs ZCB0eXBpY2FsbHkgcmVxdWlyZSBsb2NhbCANCiAgICAgICAgY29uZmlndXJhdGlvbiBvZiBzdWNo IElQIGludGVyZmFjZXMsIG9yIG9mIHRoZSB1bmRlcmx5aW5nIEFUTSANCiAgICAgICAgaW50ZXJm YWNlcy4gIA0KDQogICAgICAgICANCg0KDQogICAgICANCiAgICAgIA0KICAgICBXYWRod2EgZXQu YWwgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjgsIDIwMDYgICAgICAgICAgICAgIFtQYWdl IDMyXSANCiAgICAgICAgIA0KDCAgICAgSW50ZXJuZXQtRHJhZnQgICAgICBkcmFmdC13YWRod2Et Z3NtcC1sMmNvbnRyb2wtY29uZmlndXJhdGlvbi0wMSAgICAgICAgTWFyY2ggMjAwNiANCiAgICAg ICAgIA0KDQogICAgIDUuNiBFdGhlcm5ldC1zcGVjaWZpYyBjb25zaWRlcmF0aW9ucyANCg0KICAg ICBPbmUgcG9zc2libGUgd2F5IG9mIGFwcHJvYWNoaW5nIHRoZSB1c2Ugb2YgRXRoZXJuZXQgdGVj aG5vbG9neSBpbiB0aGUgDQogICAgIGFjY2VzcyBhZ2dyZWdhdGlvbiBuZXR3b3JrIGlzIHRvIHJl Y3JlYXRlIHRoZSBlcXVpdmFsZW50IG9mIFZpcnR1YWwgDQogICAgIFBhdGhzIChWUHMpIGFuZCBW aXJ0dWFsIENpcmN1aXRzIChWQ3MpIGJ5IHVzaW5nIHN0YWNrZWQgVmlydHVhbCBMQU4gDQogICAg IHRhZ3MuIEFzIGFuIGV4YW1wbGUsIG9uZSBjb3VsZCB1c2UgYW4gIm91dGVyIiBWTEFOIHRvIGNy ZWF0ZSBhIGZvcm0gb2YgDQogICAgICJ2aXJ0dWFsIHBhdGgiIGJldHdlZW4gYSBnaXZlbiBEU0xB TSBhbmQgYSBnaXZlbiBCUkFTLiBBbmQgdGhlbiB1c2UgDQogICAgICJpbm5lciIgVkxBTiB0YWdz IHRvIGNyZWF0ZSBhIGZvcm0gb2YgInZpcnR1YWwgY2lyY3VpdCIgb24gYSBwZXIgRFNMIA0KICAg ICBsaW5lIGJhc2lzLiBJbiB0aGlzIGNhc2UsIFZMQU4gdGFncyBjb252ZXllZCBpbiB0b3BvbG9n eSBkaXNjb3ZlcnkgYW5kIA0KICAgICBsaW5lIGNvbmZpZ3VyYXRpb24gbWVzc2FnZXMgd2lsbCBh bGxvdyB0byB1bmlxdWVseSBpZGVudGlmeSB0aGUgRFNMIGxpbmUgDQogICAgIGluIGEgc3RyYWln aHRmb3J3YXJkIG1hbm5lciwgYXNzdW1pbmcgdGhlIFZMQU4gdGFncyBhcmUgbm90IHRyYW5zbGF0 ZWQgDQogICAgIGluIHNvbWUgd2F5IGJ5IHRoZSBhZ2dyZWdhdGlvbiBuZXR3b3JrLCBhbmQgYXJl IHVuaXF1ZSBhY3Jvc3MgcGh5c2ljYWwgDQogICAgIHBvcnRzLiANCiAgICAgIA0KICAgICBIb3dl dmVyLCBzb21lIGNhcnJpZXJzIGRvIG5vdCB3aXNoIHRvIHVzZSB0aGlzICJjb25uZWN0aW9uIG9y aWVudGVkIiANCiAgICAgYXBwcm9hY2guIFRoZXJlZm9yZSwgYW4gYWx0ZXJuYXRpdmUgbW9kZWwg aXMgdG8gYnJpZGdlIHNlc3Npb25zIGZyb20gDQogICAgIG11bHRpcGxlIHN1YnNjcmliZXJzIGJl aGluZCBhIERTTEFNIHRvIGEgc2luZ2xlIFZMQU4gaW4gdGhlIGFnZ3JlZ2F0aW9uIA0KICAgICBu ZXR3b3JrLiBUaGlzIGlzIHRoZSBOOjEgbW9kZWwuIEluIHRoaXMgbW9kZWwsIG9yIGluIHRoZSBj YXNlIHdoZXJlIHVzZXIgDQogICAgIHRyYWZmaWMgaXMgc2VudCB1bnRhZ2dlZCwgdGhlIGFjY2Vz cyBub2RlIG5lZWRzIHRvIGluc2VydCB0aGUgZXhhY3QgDQogICAgIGlkZW50aXR5IG9mIHRoZSBE U0wgbGluZSBpbiB0aGUgdG9wb2xvZ3kgZGlzY292ZXJ5IGFuZCBsaW5lIA0KICAgICBjb25maWd1 cmF0aW9uIG1lc3NhZ2VzLCBhbmQgdGhlbiBoYXZlIGEgbWVjaGFuaXNtIGJ5IHdoaWNoIHRoaXMg Y2FuIGJlIA0KICAgICBjb3JyZWxhdGVkIHRvIHRoZSBjb250ZXh0IG9mIGFuICJhZ2dyZWdhdGlv biBuZXR3b3JrIiBmYWNpbmcgSVAgDQogICAgIGludGVyZmFjZSAoZm9yIHRoZSBzdWJzY3JpYmVy KSBvbiB0aGUgQlJBUy4gVGhpcyBjYW4gZWl0aGVyIGJlIGJhc2VkIG9uIA0KICAgICBsb2NhbCBj b25maWd1cmF0aW9uIG9uIHRoZSBCUkFTLCBvciBvbiB0aGUgZmFjdCB0aGF0IHN1Y2ggRFNMQU0g KGFjY2VzcyANCiAgICAgbm9kZSkgdHlwaWNhbGx5IGluc2VydHMgdGhlICJBY2Nlc3MgTG9vcCBD aXJjdWl0IElEIiBpbiBzdWJzY3JpYmVyIA0KICAgICBzaWduYWxpbmcgbWVzc2FnZXMgcmVsYXll ZCB0byB0aGUgQlJBUyAoaS5lLiBESENQIG9yIFBQUG9FIGRpc2NvdmVyeSANCiAgICAgbWVzc2Fn ZXMpLiANCiAgICAgICANCiAgICAgU2VjdGlvbiA1LjQuMSBkZWZpbmVzICJBY2Nlc3MgTG9vcCBD aXJjdWl0IElEIi4gDQogICAgICAgDQoNCiAgICAgNS43IEdyYWNlZnVsIHJlc3RhcnQgY29uc2lk ZXJhdGlvbnMgKFRCRCkgDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQogICAgIDYgIElBTkEgQ29uc2lkZXJh dGlvbnMgDQoNCiAgICAgICAgTmV3IFRlY2gtVHlwZSwgY2FwYWJpbGl0eSB0eXBlcywgc3ViLVRM ViB0eXBlcyByZWxhdGVkIHRvIHRvcG9sb2d5IA0KICAgICAgICBkaXNjb3ZlcnkgYW5kIGxpbmUg Y29uZmlndXJhdGlvbiB3aWxsIG5lZWQgdG8gYmUgcmVzZXJ2ZWQuIA0KDQogICAgIDcgIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zIA0KDQogICAgICAgIFRoZSBCUkFTIGFuZCBEU0xBTXMgYXJlIGlt cGxpY2l0bHkgaW4gYSB0cnVzdGVkIGRvbWFpbiwgc28gc2VjdXJpdHkgICAgICAgIA0KICAgICAg ICBmb3IgTDItQ29udHJvbCBwcm90b2NvbCBpcyBub3QgYSBzdHJvbmcgcmVxdWlyZW1lbnQuIEhv d2V2ZXIgaWYgDQogICAgICAgIG5lZWRlZCBzZWN1cml0eSBjYW4gYmUgcHJvdmlkZWQgdXNpbmcg SVAgc2VjdXJpdHkgYXMgaW5kaWNhdGVkIGluIA0KICAgICAgICBbUkZDMzI5M10uICANCg0KICAg ICAgDQogICAgICANCiAgICAgV2FkaHdhIGV0LmFsICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVy IDI4LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSAzM10gDQogICAgICAgICANCgwgICAgIEludGVy bmV0LURyYWZ0ICAgICAgZHJhZnQtd2FkaHdhLWdzbXAtbDJjb250cm9sLWNvbmZpZ3VyYXRpb24t MDEgICAgICAgIE1hcmNoIDIwMDYgDQogICAgICAgICANCg0KICAgICAgICAgDQoNCiAgICAgOCAg UmVmZXJlbmNlcyANCg0KICAgICAgICBbMV0gICBEU0xGb3J1bSBUUi0wNTksIERTTCBFdm9sdXRp b24gLSBBcmNoaXRlY3R1cmUgUmVxdWlyZW1lbnRzIGZvciANCiAgICAgICAgICAgICAgdGhlIFN1 cHBvcnQgb2YgUW9TLUVuYWJsZWQgSVAgU2VydmljZXMsIFRvbSBBbnNjaHV0eiAoQmVsbFNvdXRo IA0KICAgICAgICAgICAgICBUZWxlY29tbXVuaWNhdGlvbnMpLCAwOS8yMDAzLiANCg0KICAgICAg ICBbMl0gICBEU0xGb3J1bSBUUi0wNTgsIE11bHRpLVNlcnZpY2UgQXJjaGl0ZWN0dXJlICYgRnJh bWV3b3JrIA0KICAgICAgICAgICAgICBSZXF1aXJlbWVudHMsIE1hcmsgRWxpYXMgKFNCQykgYW5k IFN2ZW4gT29naGUgKEFsY2F0ZWwpLCANCiAgICAgICAgICAgICAgMDkvMjAwMy4gDQoNCiAgICAg ICAgWzNdICAgRFNMRm9ydW0gVFItMDkyLCBCcm9hZGJhbmQgUmVtb3RlIGFjY2VzcyBzZXJ2ZXIg cmVxdWlyZW1lbnRzIA0KICAgICAgICAgICAgICBkb2N1bWVudC4gDQoNCiAgICAgICAgWzRdICAg RG9yaWEsIEEuLCAiR1NNUHYzIEJhc2UgU3BlY2lmaWNhdGlvbiIsIGRyYWZ0LWlldGYtZ3NtcC12 My0NCiAgICAgICAgICAgICAgYmFzZS1zcGVjLTA2LCBOb3YgMjAwNC4gDQoNCiAgICAgICAgWzVd ICAgV29yc3RlciwgVC4sIERvcmlhLCBBLiBhbmQgSi4gQnVlcmtsZSwgIkdlbmVyYWwgU3dpdGNo IA0KICAgICAgICAgICAgICBNYW5hZ2VtZW50IFByb3RvY29sIChHU01QKSBQYWNrZXQgRW5jYXBz dWxhdGlvbnMgZm9yIA0KICAgICAgICAgICAgICBBc3luY2hyb25vdXMgVHJhbnNmZXIgTW9kZSAo QVRNKSwgRXRoZXJuZXQgYW5kIFRyYW5zbWlzc2lvbiANCiAgICAgICAgICAgICAgQ29udHJvbCBQ cm90b2NvbCAoVENQKSIsIFJGQyAzMjkzLCBKdW5lIDIwMDIuIA0KDQogICAgICAgIFs2XSAgIEdT TVAgZXh0ZW5zaW9ucyBmb3IgbGF5ZXIyIGNvbnRyb2wgLSBUcmFuc2FjdGlvbmFsIE11bHRpY2Fz dCwgDQogICAgICAgICAgICAgIGRyYWZ0LW1vaXNhbmQtZ3NtcC1sMmNvbnRyb2wtbXVsdGljYXN0 LTAwICh3b3JrIGluIHByb2dyZXNzKS4gDQoNCiAgICAgICAgWzddICAgIkRIQ1AgUmVsYXkgQWdl bnQgSW5mb3JtYXRpb24gT3B0aW9uIiwgUkZDIDMwNDYsIEphbnVhcnkgMjAwMS4gDQoNCiAgICAg ICAgWzhdICAgQXJjaGl0ZWN0dXJlICYgVHJhbnNwb3J0OiBNaWdyYXRpb24gdG8gRXRoZXJuZXQg QmFzZWQgRFNMIA0KICAgICAgICAgICAgICBBZ2dyZWdhdGlvbiwgRFNMIEZvcnVtIFdULTEwMSwg Q29oZW4gZXQgYWwuIA0KDQogICAgICAgICANCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN CiAgICAgIA0KICAgICAgDQogICAgIFdhZGh3YSBldC5hbCAgICAgICAgICBFeHBpcmVzIFNlcHRl bWJlciAyOCwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgMzRdIA0KICAgICAgICAgDQoMICAgICBJ bnRlcm5ldC1EcmFmdCAgICAgIGRyYWZ0LXdhZGh3YS1nc21wLWwyY29udHJvbC1jb25maWd1cmF0 aW9uLTAxICAgICAgICBNYXJjaCAyMDA2IA0KICAgICAgICAgDQoNCiAgICAgQXV0aG9yJ3MgQWRk cmVzc2VzIA0KDQogICAgICAgIFNhbmpheSBXYWRod2EgIA0KICAgICAgICBKdW5pcGVyIE5ldHdv cmtzIA0KICAgICAgICAxMCBUZWNobm9sb2d5IFBhcmsgRHJpdmUgDQogICAgICAgIFdlc3Rmb3Jk LCBNQSAwMTg4NiANCiAgICAgICAgIA0KICAgICAgICBFbWFpbDogc3dhZGh3YUBqdW5pcGVyLm5l dCANCiAgICAgICAgICAgIA0KICAgICAgICBKZXJvbWUgTW9pc2FuZCANCiAgICAgICAgSnVuaXBl ciBOZXR3b3JrcyANCiAgICAgICAgMTAgVGVjaG5vbG9neSBQYXJrIERyaXZlIA0KICAgICAgICBX ZXN0Zm9yZCwgTUEgMDE4ODYgDQogICAgICAgICANCiAgICAgICAgICAgIA0KICAgICAgICBFbWFp bDogam1vaXNhbmRAanVuaXBlci5uZXQgDQogICAgICAgICANCiAgICAgICAgU3dhbWkgU3VicmFt YW5pYW4gDQogICAgICAgIEp1bmlwZXIgTmV0d29ya3MgDQogICAgICAgIDEwIFRlY2hub2xvZ3kg UGFyayBEcml2ZSANCiAgICAgICAgV2VzdGZvcmQsIE1BIDAxODg2IA0KICAgICAgICAgDQogICAg ICAgICAgICANCiAgICAgICAgRW1haWw6IHNzdWJyYW1hbmlhbkBqdW5pcGVyLm5ldCANCiAgICAg ICAgIA0KICAgICAgICBUaG9tYXMgSGFhZyANCiAgICAgICAgVC1zeXN0ZW1zIA0KICAgICAgICAg DQogICAgICAgIEVtYWlsOiB0aG9tYXMuaGFhZ0B0LXN5c3RlbXMuY29tIA0KICAgICAgICAgDQog ICAgICAgIE5vcmJlciBWb2lndCANCiAgICAgICAgU2llbWVucyANCiAgICAgICAgIA0KICAgICAg ICBFbWFpbDogbm9yYmVydC52b2lndEBzaWVtZW5zLmNvbSANCiAgICAgICAgIA0KICAgICBJbnRl bGxlY3R1YWwgUHJvcGVydHkgU3RhdGVtZW50IA0KDQogICAgICAgIFRoZSBJRVRGIHRha2VzIG5v IHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55IA0KICAgICAg ICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0 IGJlIGNsYWltZWQgdG8gDQogICAgICAgIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9y IHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4gDQogICAgICAgIHRoaXMgZG9jdW1l bnQgb3IgdGhlIGV4dGVudCB0byB3aGljaCBhbnkgbGljZW5zZSB1bmRlciBzdWNoIHJpZ2h0cyAN CiAgICAgICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVw cmVzZW50IHRoYXQgaXQgaGFzIA0KICAgICAgICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQg dG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24gDQogICAgICAgIG9uIHRo ZSBwcm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gUkZDIGRvY3VtZW50cyBjYW4g YmUgDQogICAgICAgIGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQIDc5LiANCg0KDQogICAgICANCiAg ICAgIA0KICAgICBXYWRod2EgZXQuYWwgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjgsIDIw MDYgICAgICAgICAgICAgIFtQYWdlIDM1XSANCiAgICAgICAgIA0KDCAgICAgSW50ZXJuZXQtRHJh ZnQgICAgICBkcmFmdC13YWRod2EtZ3NtcC1sMmNvbnRyb2wtY29uZmlndXJhdGlvbi0wMSAgICAg ICAgTWFyY2ggMjAwNiANCiAgICAgICAgIA0KDQogICAgICAgIENvcGllcyBvZiBJUFIgZGlzY2xv c3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNyZXRhcmlhdCBhbmQgYW55IA0KICAgICAgICBhc3N1 cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBvciB0aGUgcmVzdWx0IG9m IGFuIA0KICAgICAgICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9y IHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YgDQogICAgICAgIHN1Y2ggcHJvcHJpZXRhcnkgcmln aHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzIA0KICAgICAgICBzcGVjaWZpY2F0 aW9uIGNhbiBiZSBvYnRhaW5lZCBmcm9tIHRoZSBJRVRGIG9uLWxpbmUgSVBSIHJlcG9zaXRvcnkg YXQgDQogICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLiANCg0KICAgICAgICBUaGUgSUVU RiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRvIGJyaW5nIHRvIGl0cyBhdHRlbnRpb24g YW55IA0KICAgICAgICBjb3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMs IG9yIG90aGVyIHByb3ByaWV0YXJ5IA0KICAgICAgICByaWdodHMgdGhhdCBtYXkgY292ZXIgdGVj aG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBsZW1lbnQgDQogICAgICAgIHRoaXMg c3RhbmRhcmQuICBQbGVhc2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhlIElFVEYgYXQg DQogICAgICAgIGlldGYtaXByQGlldGYub3JnIA0KDQogICAgIERpc2NsYWltZXIgb2YgVmFsaWRp dHkgDQoNCiAgICAgICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFuIA0KICAgICAgICAiQVMgSVMiIGJhc2lzIGFuZCBU SEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJT04gSEUvU0hFIFJFUFJFU0VOVFMgDQogICAg ICAgIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5E IFRIRSBJTlRFUk5FVCANCiAgICAgICAgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTSBB TEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVELCANCiAgICAgICAgSU5DTFVESU5HIEJV VCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRIRSANCiAgICAg ICAgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5Z IElNUExJRUQgDQogICAgICAgIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5F U1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiANCg0KICAgICBDb3B5cmlnaHQgU3RhdGVtZW50 IA0KDQogICAgICAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDYpLiAN Cg0KICAgICAgICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gdGhlIHJpZ2h0cywgbGljZW5z ZXMgYW5kIHJlc3RyaWN0aW9ucyANCiAgICAgICAgY29udGFpbmVkIGluIEJDUCA3OCwgYW5kIGV4 Y2VwdCBhcyBzZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1dGhvcnMgDQogICAgICAgIHJldGFpbiBh bGwgdGhlaXIgcmlnaHRzLiANCg0KICAgICBBY2tub3dsZWRnbWVudCAgICAgDQoNCiAgICAgICAg VGhhbmtzIHRvIFBldGVyIEFyYmVyZywgSm9zZWYgRnJvZWhsZXIsIERlcmVrIEhhcmtuZXNzLCBL aW0gDQogICAgICAgIEh5bGRnYWFyZCwgU2FuZHkgTmcsIFJvYmVydCBQZXNjaGksIGFuZCBNaWNo ZWwgUGxhdG5pYyBmb3IgdGhlaXIgDQogICAgICAgIGlucHV0IHRvIHRoaXMgZG9jdW1lbnQuICAN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQogICAgICANCiAgICAgIA0KICAgICBXYWRod2EgZXQuYWwg ICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjgsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDM2 XSANCiAgICAgICAgIA0KDA== --_004_48C276B536524E478C659685995F6AA539DBBBE577RBSJXadredbac_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --_004_48C276B536524E478C659685995F6AA539DBBBE577RBSJXadredbac_--