From ancp-bounces@ietf.org Thu Feb 01 05:34:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCZH7-0008Bq-DB; Thu, 01 Feb 2007 05:34:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCYyY-0000MB-Jz for ancp@ietf.org; Thu, 01 Feb 2007 05:15:30 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCYyX-0001Xn-Bj for ancp@ietf.org; Thu, 01 Feb 2007 05:15:30 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Thu, 1 Feb 2007 11:15:25 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 11:15:25 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: WG: [ANCP] ANCP Versioning Date: Thu, 1 Feb 2007 11:15:24 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2C45895@S4DE8PSAAFQ.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP Versioning thread-index: Acc+3SswI9tPSfwzSO+w3Vxx2R5dRAAOHMZwABzs2EAAMTLqwAFip+SgAAQ2mDA= From: "Busser, M" To: X-OriginalArrivalTime: 01 Feb 2007 10:15:25.0442 (UTC) FILETIME=[E3C58E20:01C745E9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 708bdb947b83e88c58fd603ed07f3c7a Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 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="===============0974051596==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0974051596== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C745E9.E34601F7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C745E9.E34601F7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Wojciech =20 Please see inline. =20 Best regards =20 Thomas & Michael =20 =09 ________________________________ Von: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Gesendet: Dienstag, 23. Januar 2007 18:45 An: ancp@ietf.org Betreff: [ANCP] ANCP Versioning =20 =20 Dear All,=20 Recently the WG has seen a fair bit of discussion regarding ANCP protocol versioning including several calls for a change in the version number. Following consultations with our IETF directorate and technical advisors we now feel ready to present to you the ANCP versioning strategy that we're proposing for adoption A brief summary of the problems.=20 ------------------------------------------------=20 * During work on the protocol spec draft-wadhwa-gsmp-l2control-configuration, that has now been approved as a WG ID, a couple of changes have been made with respect to TLV and sub-TLV numbering.. These changes resulted in the possibility that ANCP implementations based on previous versions of the draft could misinterpret information sent by implementations based on the latest draft. The problem has been spotted and a relatively simple fix is available, at least for one of the problems, which prevents currently deployed implementations from falling foul of this problem. =20 * The current ANCP implementations and WG protocol spec follow GSMP's draft-ietf-gsmp-v3-base-spec-06 and later revisions. This base-spec draft actually introduced a change to the basic GSMP Message's version field format in comparison to the one defined in GSMPv3 (rfc3292): The base-spec takes the version field to be composed out of two nibbles, version & sub version, being set to 3 and 1 respectively. RFC 3292 defines the version field as a single byte value, and in section 11.1 sets it to 3. =20 =20 * Going forward, it is likely that the protocol will introduce modifications to the base protocol, which may render backward compatibility difficult. =20 =20 * ANCP is currently not compatible with GSMPv3 and it does not appear that there is the desire to make a device implementing ANCP be able to form an adjacency with a device running an RFC3292 compliant version of GSMPv3. =20 =20 * ANCP currently uses GSMP's TCP port number 6068 and this may change given potential work on a new transport protocol, and/or a shift from GSMP.=20 =20 ANCP Versioning strategy.=20 ----------------------------------------=20 The conclusion that we reached is that any protocol version or sub-version change are to be done primarily to address substantial protocol changes that will render previous versions incompatible - this is best practice, besides common sense that is used throughout the IETF community. It will be for the WG group, backed by technical advice when required, to decide when this stage is actually reached.=20 In view of our WG's chartered work, such a stage may actually come towards the end of the protocol specification where we could, for example decide to use a modified protocol state-machine, protocol transport, and/or transport port. The following list is deemed to not qualify as substantial protocol changes, and thus will not be considered as sufficient ground for changing/revising the ANCP version, or sub-version number: i) a new revision of the protocol spec*=20 ii) a conflicting TLV or sub-TLVs=20 iii) incompatibilities arising from implementations of pre-RFC drafts.=20 iv) new negotiable protocol capabilities (eg Bulk message capability)**=20 * Unless the revised draft diverges so far in protocol compatibility from its origin as to render it incompatible, for example a new protocol RFC ** The current capabilities negotiation mechanism leaves a few things to be desired - this will be discussed in a follow on mail. If and when the WG agrees that substantial changes have been made to the protocol, a new protocol version will require an IANA version registry change.=20 With respect to protocol version negotiation, it is not seen as a desirable feature of the protocol due to its complexity and potential for introducing several more problems than it actually would solve - the capabilities negotiation feature is intended precisely to remove the need for such a feature, and thus a version negotiation capability is not required.=20 Taking this into account, from my perspective: - we in fact already have an ANCP protocol version number (located in the GSMP-Header, being set to 3.1) - we might change this number, if the draft becomes a RFC With all this said, the above points do reflect real world problems that the WG will need to deal with. Thus, to resolve the current TLV/sub-TLV issue, and potential future ones, we would like to propose that whenever a conflict arising out of different draft versions is noted, the TLVs in question will be set as being depreciated/reserved and a new set assigned - all done though rough consensus in the WG naturally. Only when absolutely necessary would an appendix be introduced to the protocol spec to shed some light on the deprecated values.=20 Declaring a TLV as depricated and assigning a new set of TLV-numbers will solve the interworking problem only, if the depricated TLV's will still be supported. Nevertheless "old" depreciated TLVs have to be supported for all future version to keep interability. Otherwise we will end up with the same problems again and again, don't we? =20 TLV 0x90 conclusion and TLV work for the WG=20 -------------------------------------------------------------=20 With the above strategy outlined we can arrive at some conclusions with respect to the recent WG "Protocol version nummer for ANCP" thread: - The problem identified does not warrant a protocol version revision, or the introduction of a version negotiation capability. - The following is a list of TLVs that are of have been affected by conflicts and are thus candidates for depreciation:=20 1. PORT-UP TLV Type 0x02. Should have a new TLV for (Access-Loop-Remote-Id) which is currently using 0x02. A new TLV 0x06 has already been assigned for (Access-Aggregation-Circuit-ID-Binary) that was conflicting 2. PORT-UP TLV 0x04 sub-TLV 0x90. Should have a new sub-TLV for (Access Loop Encapsulation) which is currently set to 0x90. An new TLV 0x91 already been assigned for (DSL-Type) that was conflicting.=20 Just leaving the DSL-Type at 0x90 and moving the Access-Loop-Encapsulation to 0x91 will solve the problem without the need of marking something as depricated. Is there any reason not to do so? =20 Given the above, let's now please commence the discussion on depreciating the above two, admittedly important TLVs, and introducing new ones. Exiting implementations are known to be able to handle the conflict so far, thus the changes will not immediately produce problems, however implementers and early adopters should make plans towards moving to any agreed new values. Kind Regards,=20 Woj.=20 ------_=_NextPart_001_01C745E9.E34601F7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nachricht

Hi=20 Wojciech

 

Please see=20 inline.

 

Best=20 regards

 

Thomas & = Michael

 

Von:=20 Wojciech Dec (wdec) [mailto:wdec@cisco.com]
Gesendet: Dienstag, 23. Januar = 2007=20 18:45
An:=20 ancp@ietf.org
Betreff: [ANCP]=20 ANCP Versioning

 

 

Dear All,=20

Recently the WG has seen = a fair=20 bit of discussion regarding ANCP protocol versioning = including=20 several calls for a change in the version number. Following consultations with our IETF = directorate and=20 technical advisors we now feel ready to present to you the ANCP = versioning=20 strategy that we're proposing for=20 adoption

A brief summary of the=20 problems.
------------------------------------------------=20

  • During=20 work on the protocol spec draft-wadhwa-gsmp-l2control-configuration,=20 that has now been approved as a WG ID, a couple of changes have been = made=20 with respect to TLV and sub-TLV numbering.. These changes resulted = in the=20 possibility that ANCP implementations based on previous versions of = the=20 draft could misinterpret information sent by implementations based = on the=20 latest draft. The problem has been spotted and a relatively simple = fix is=20 available, at least for one of the problems, which prevents = currently=20 deployed implementations from falling foul of this=20 problem.   =20
  • The=20 current ANCP implementations and WG protocol spec follow GSMP's=20 draft-ietf-gsmp-v3-base-spec-06 and later revisions. This base-spec = draft=20 actually introduced a change to the basic GSMP Message's version = field=20 format in comparison to the one defined in GSMPv3 (rfc3292): The = base-spec=20 takes the version field to be composed out of two nibbles, version = & sub=20 version, being set to 3 and 1 respectively. RFC 3292 defines the = version=20 field as a single byte value, and in section 11.1 sets it to = 3.  
          =
  • Going=20 forward, it is likely that the protocol will introduce modifications = to the=20 base protocol, which may render backward compatibility=20 difficult.  
         =20
  • ANCP is=20 currently not compatible with GSMPv3 and it does not appear that = there is=20 the desire to make a device implementing ANCP be able to form an = adjacency=20 with a device running an RFC3292 compliant version of=20 GSMPv3.  
         =20
  • ANCP=20 currently uses GSMP's TCP port number 6068 and this may change given = potential work on a new transport protocol, and/or a shift = from=20 GSMP.

 

ANCP Versioning=20 strategy.
----------------------------------------=20

The conclusion that we = reached is=20 that any protocol version or sub-version change are to be done = primarily to=20 address substantial protocol changes that will render previous = versions=20 incompatible - this is best practice, besides common sense that is = used=20 throughout the IETF community. It will be for the WG group, backed by=20 technical advice when required, to decide when this stage is actually = reached.=20

In view of our WG's = chartered=20 work, such a stage may actually come towards the end of the protocol=20 specification where we could, for example decide to use a modified = protocol=20 state-machine, protocol transport, and/or transport=20 port.

The following list is = deemed to=20 not qualify as substantial protocol changes, and thus will not be = considered=20 as sufficient ground for changing/revising the ANCP version, or = sub-version=20 number:

i) a new revision of the = protocol=20 spec*
ii) a conflicting TLV or = sub-TLVs
iii) incompatibilities = arising=20 from implementations of pre-RFC drafts.
iv) new = negotiable=20 protocol capabilities (eg Bulk message capability)**=20

*=20 Unless the revised = draft diverges=20 so far in protocol compatibility from its origin as to render it = incompatible,=20 for example a new protocol = RFC

** The current = capabilities=20 negotiation mechanism leaves a few things to be desired - this will be = discussed in a follow on mail.

If and = when the WG=20 agrees that substantial changes have been made to the protocol, a new = protocol=20 version will require an IANA version registry = change. 

With respect to protocol = version=20 negotiation, it is not seen as a desirable feature of the protocol due = to its=20 complexity and potential for introducing several more problems than it = actually would solve - the capabilities negotiation feature is = intended=20 precisely to remove the need for such a feature, and thus a version=20 negotiation capability is not required. 

Taking this=20 into account, from my perspective:
 - we = in fact=20 already have an ANCP protocol version number (located in the=20 GSMP-Header, being set to 3.1)
 - we might change this number, if the = draft=20 becomes a RFC

With all this said, the = above=20 points do reflect real world problems that the WG will need to deal = with.=20 Thus, to resolve the current TLV/sub-TLV issue, and potential future = ones, we=20 would like to propose that whenever a conflict arising out of = different draft=20 versions is noted, the TLVs in question will be set as being=20 depreciated/reserved and a new set assigned - all done though rough = consensus=20 in the WG naturally. Only when absolutely necessary  would = an=20 appendix be introduced to the protocol spec to shed some light on the=20 deprecated values. 

Declaring a=20 TLV as depricated and assigning a new set of TLV-numbers will = solve the=20 interworking problem only, if   the  depricated TLV's=20 will still be supported. = Nevertheless=20 “old” depreciated TLVs have to be supported for all future = version to keep=20 interability.
Otherwise=20 we will end up with the same problems = again and=20 again, don’t we?

 

TLV 0x90 conclusion and = TLV work=20 for the WG
-------------------------------------------------------------=20

With the above strategy = outlined=20 we can arrive at some conclusions with respect to the recent WG = "Protocol=20 version nummer for ANCP" thread:

-=20 The problem identified does not warrant a protocol version revision, = or the=20 introduction of a version negotiation = capability.

-=20 The following is a list of TLVs that are of have been affected by = conflicts=20 and are thus candidates for depreciation: =

1. PORT-UP TLV Type 0x02. Should = have a new=20 TLV for (Access-Loop-Remote-Id) which is currently using 0x02. A new = TLV 0x06=20 has already been assigned for (Access-Aggregation-Circuit-ID-Binary) = that was=20 conflicting

2. PORT-UP TLV=20 0x04 sub-TLV 0x90. Should have a new = sub-TLV for=20 (Access Loop Encapsulation) which is currently set to 0x90. An new TLV = 0x91=20 already been assigned for (DSL-Type) that was=20 conflicting. 

Just = leaving the=20 DSL-Type at 0x90 and moving the Access-Loop-Encapsulation to = 0x91 will=20 solve the problem without the need of marking something as = depricated.
Is=20 there any reason not to do so?  

Given the above, let's = now please=20 commence the discussion on depreciating the above two, admittedly important=20 TLVs, and introducing new ones. Exiting implementations are known to = be able=20 to handle the conflict so far, thus the changes will not immediately = produce=20 problems, however implementers and early adopters should make plans = towards=20 moving to any agreed=20 new=20 values.

Kind = Regards,=20
Woj.=20

------_=_NextPart_001_01C745E9.E34601F7-- --===============0974051596== 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://www1.ietf.org/mailman/listinfo/ancp --===============0974051596==-- From ancp-bounces@ietf.org Thu Feb 01 07:21:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCawB-0000Vc-J7; Thu, 01 Feb 2007 07:21:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCawB-0000VS-3B for ancp@ietf.org; Thu, 01 Feb 2007 07:21:11 -0500 Received: from 103.12.152.198.in-addr.arpa ([198.152.12.103] helo=nj300815-ier2.net.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCaw8-0006Z7-O9 for ancp@ietf.org; Thu, 01 Feb 2007 07:21:11 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l11CL3RJ018623 for ; Thu, 1 Feb 2007 07:21:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] ANCP Versioning Date: Thu, 1 Feb 2007 14:21:02 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP Versioning Thread-Index: Acc+3SswI9tPSfwzSO+w3Vxx2R5dRAAOHMZwABzs2EAAMTLqwAFip+SgAAQ2mDAAA+lqAA== References: <6439282641581441A36F7F6F83ED2ED2C45895@S4DE8PSAAFQ.mitte.t-com.de> From: "Romascanu, Dan \(Dan\)" To: "Busser, M" , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.1 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 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="===============1976266853==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1976266853== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C745FB.703330DA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C745FB.703330DA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 =20 =20 _____ =20 From: Busser, M [mailto:Michael.Busser@t-systems.com]=20 =09 With all this said, the above points do reflect real world problems that the WG will need to deal with. Thus, to resolve the current TLV/sub-TLV issue, and potential future ones, we would like to propose that whenever a conflict arising out of different draft versions is noted, the TLVs in question will be set as being depreciated/reserved and a new set assigned - all done though rough consensus in the WG naturally. Only when absolutely necessary would an appendix be introduced to the protocol spec to shed some light on the deprecated values.=20 Declaring a TLV as depricated and assigning a new set of TLV-numbers will solve the interworking problem only, if the depricated TLV's will still be supported. Nevertheless "old" depreciated TLVs have to be supported for all future version to keep interability. Otherwise we will end up with the same problems again and again, don't we? =20 =09 [DR] Not really IMO. Interoperability of a specific function is tested at the level of a given version. The problem is to avoid conflicting TLVs for the same function. Although continuing for a while to support deprecated TLVs is a good migration tactics, I do not believe that this is required from an interoperability point of view.=20 =20 Dan =20 ------_=_NextPart_001_01C745FB.703330DA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nachricht
 
 
 
 

From: Busser, M=20 [mailto:Michael.Busser@t-systems.com]

With all this said, = the above=20 points do reflect real world problems that the WG will need to deal = with.=20 Thus, to resolve the current TLV/sub-TLV issue, and potential future = ones,=20 we would like to propose that whenever a conflict arising out of = different=20 draft versions is noted, the TLVs in question will be set as being=20 depreciated/reserved and a new set assigned - all done though rough=20 consensus in the WG naturally. Only when absolutely = necessary =20 would an appendix be introduced to the protocol spec to shed some = light on=20 the deprecated values. 

Declaring a=20 TLV as depricated and assigning a new set of TLV-numbers will = solve the=20 interworking problem only, if   the  depricated=20 TLV's will still be supported.=20 Nevertheless “old” depreciated TLVs have to be supported = for all future=20 version to keep interability.
Otherwise=20 we will end up with the same problems = again and=20 again, don’t we?

 


[DR] Not really IMO. Interoperability of a = specific=20 function is tested at the level of a given version. The problem is = to avoid=20 conflicting TLVs for the same function. Although continuing for a = while to=20 support deprecated TLVs is a good migration tactics, I do not = believe that=20 this is required from an interoperability point of view.=20

 

Dan

 

------_=_NextPart_001_01C745FB.703330DA-- --===============1976266853== 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://www1.ietf.org/mailman/listinfo/ancp --===============1976266853==-- From ancp-bounces@ietf.org Fri Feb 02 09:21:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCzHw-0003Ug-GP; Fri, 02 Feb 2007 09:21:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCzHv-0003Ub-Qs for ancp@ietf.org; Fri, 02 Feb 2007 09:21:15 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCzHt-0002lK-De for ancp@ietf.org; Fri, 02 Feb 2007 09:21:15 -0500 Received: from gbmail02.netfr.alcatel.fr (gbmail02.netfr.alcatel.fr [155.132.251.26]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l12ELFDJ030421 for ; Fri, 2 Feb 2007 15:21:16 +0100 To: ancp@ietf.org X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Matthew.Bocci@alcatel-lucent.co.uk Date: Fri, 2 Feb 2007 14:21:05 +0000 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 02/02/2007 14:21:09 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [ANCP] Updates for ANCP milestones X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Folks, Following the introduction of the ANCP security threats analysis, and given the progress made so far in the working group, we will be updating the goals and milestones as follows: Done Accept WG I-D for ANCP Framework and Requirements Done Accept WG ID for Security Threats analysis Done Accept WG I-D for Access Node Control Protocol (ANCP) Mar 2007 Framework and Requirements last call Mar 2007 Accept WG I-D for ANCP MIB June 2007 Security Threats Analysis last call August 2007 Access Node Control Protocol (ANCP) Last Call August 2007 ANCP MIB Last Call Nov 2007 Re-charter or conclude Working Group Please send any comments to the list. regards, Matthew _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Feb 07 19:54:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HExYk-0005M1-W7; Wed, 07 Feb 2007 19:54:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HExYi-0005Lw-OV for ancp@ietf.org; Wed, 07 Feb 2007 19:54:44 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HExYh-0006MM-GX for ancp@ietf.org; Wed, 07 Feb 2007 19:54:44 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 04423B67081 for ; Wed, 7 Feb 2007 16:54:41 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24194-10 for ; Wed, 7 Feb 2007 16:54:40 -0800 (PST) Received: from [127.0.0.1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id DF92BB6707F for ; Wed, 7 Feb 2007 16:54:40 -0800 (PST) Message-ID: <45CA74D0.5030100@redback.com> Date: Wed, 07 Feb 2007 16:54:40 -0800 From: Jakob Heitz User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: ancp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.5 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [ANCP] OAM-Loopback-Test-Parameters X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org In draft-wadhwa-gsmp-l2control-configuration-02, for OAM-Loopback-Test-Parameters = 0x07, it says: Length: 4 bytes Value : two 1 byte numbers (listed in order of most to least significant) also: The Length field in each TLV contains the actual number of bytes in the TLV (not including the padding if present). So, how is the length of "two 1 byte numbers" equal to "4 bytes" ? Where are the two one byte numbers in the field of 4? What are the other two bytes to make the total of 4? Are they padding? Suppose the count is 5 and the timeout is 3. Is the hex representation like this ? 00 07 00 04 05 03 00 00 or like this? 00 07 00 04 00 00 05 03 or should it be like this? 00 07 00 02 05 03 00 00 or is it something else? _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Feb 08 08:01:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF8uH-000888-Ni; Thu, 08 Feb 2007 08:01:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF8sr-0007Jy-Bk for ancp@ietf.org; Thu, 08 Feb 2007 08:00:17 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF8lb-000617-FX for ancp@ietf.org; Thu, 08 Feb 2007 07:52:56 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DE33C20589; Thu, 8 Feb 2007 13:52:42 +0100 (CET) X-AuditID: c1b4fb3c-ae7c5bb0000007de-87-45cb1d1a0094 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CEA1C20470; Thu, 8 Feb 2007 13:52:42 +0100 (CET) Received: from esealmw104.eemea.ericsson.se ([153.88.200.67]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Feb 2007 13:52:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ANCP] OAM-Loopback-Test-Parameters Date: Thu, 8 Feb 2007 13:52:39 +0100 Message-ID: <2DEB3E4E9BC3774B8EEF2EF2BE9F745BFEE402@esealmw104.eemea.ericsson.se> In-Reply-To: <45CA74D0.5030100@redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] OAM-Loopback-Test-Parameters Thread-Index: AcdLG9qxR/L4wh6tQwG8PhnoNqsn6QAXUTOw From: "Kim Hyldgaard \(ST/LMD\)" To: "Jakob Heitz" , X-OriginalArrivalTime: 08 Feb 2007 12:52:42.0560 (UTC) FILETIME=[059FBC00:01C74B80] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Jakob, This is how I interpret it: 00 07 00 04 05 03 00 00 The value itself is defined as 4 bytes, so there's no padding, eventhough only 1+1 bytes are in use. One could argue that the specification is a bit vague in the description of this parameter... :-) Kim =20 -----Original Message----- From: Jakob Heitz [mailto:jheitz+121406@redback.com]=20 Sent: 8. februar 2007 01:55 To: ancp@ietf.org Subject: [ANCP] OAM-Loopback-Test-Parameters In draft-wadhwa-gsmp-l2control-configuration-02, for OAM-Loopback-Test-Parameters =3D 0x07, it says: Length: 4 bytes Value : two 1 byte numbers (listed in order of most to least significant)=20 also: The Length field in each TLV contains the actual number of bytes in the TLV (not including the padding if present). So, how is the length of "two 1 byte numbers" equal to "4 bytes" ? Where are the two one byte numbers in the field of 4? What are the other two bytes to make the total of 4? Are they padding? Suppose the count is 5 and the timeout is 3. Is the hex representation like this ? 00 07 00 04 05 03 00 00 or like this? 00 07 00 04 00 00 05 03 or should it be like this? 00 07 00 02 05 03 00 00 or is it something else? _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Fri Feb 09 03:45:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFRO6-0005wt-ID; Fri, 09 Feb 2007 03:45:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFRO5-0005wj-Hr for ancp@ietf.org; Fri, 09 Feb 2007 03:45:45 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFRO2-0006Ui-SL for ancp@ietf.org; Fri, 09 Feb 2007 03:45:44 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Fri, 9 Feb 2007 09:45:41 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 09:45:41 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [ANCP] OAM-Loopback-Test-Parameters Date: Fri, 9 Feb 2007 09:45:40 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2C458B2@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <2DEB3E4E9BC3774B8EEF2EF2BE9F745BFEE402@esealmw104.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] OAM-Loopback-Test-Parameters Thread-Index: AcdLG9qxR/L4wh6tQwG8PhnoNqsn6QAXUTOwACsYn+A= From: "Busser, M" To: , , X-OriginalArrivalTime: 09 Feb 2007 08:45:41.0372 (UTC) FILETIME=[ADEBABC0:01C74C26] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: "Haag, T" X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Kim, Jakob This is also what i found in different traces. If TLV Length is set to 4 (according to = draft-wadhwa-gsmp-l2control-configuration-02) i found: 00 07 00 04 05 03 00 00 Michael -----Urspr=FCngliche Nachricht----- Von: Kim Hyldgaard (ST/LMD) [mailto:kim.hyldgaard@ericsson.com]=20 Gesendet: Donnerstag, 8. Februar 2007 13:53 An: Jakob Heitz; ancp@ietf.org Betreff: RE: [ANCP] OAM-Loopback-Test-Parameters Hi Jakob, This is how I interpret it: 00 07 00 04 05 03 00 00 The value itself is defined as 4 bytes, so there's no padding, = eventhough only 1+1 bytes are in use. One could argue that the specification is a bit vague in the description = of this parameter... :-) Kim =20 -----Original Message----- From: Jakob Heitz [mailto:jheitz+121406@redback.com]=20 Sent: 8. februar 2007 01:55 To: ancp@ietf.org Subject: [ANCP] OAM-Loopback-Test-Parameters In draft-wadhwa-gsmp-l2control-configuration-02, for OAM-Loopback-Test-Parameters =3D 0x07, it says: Length: 4 bytes Value : two 1 byte numbers (listed in order of most to least significant)=20 also: The Length field in each TLV contains the actual number of bytes in the TLV (not including the padding = if present). So, how is the length of "two 1 byte numbers" equal to "4 bytes" ? Where = are the two one byte numbers in the field of 4? What are the other two = bytes to make the total of 4? Are they padding? Suppose the count is 5 and the timeout is 3. Is the hex representation like this ? 00 07 00 04 05 03 00 00 or like this? 00 07 00 04 00 00 05 03 or should it be like this? 00 07 00 02 05 03 00 00 or is it something else? _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Sat Feb 10 08:20:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFs8n-0002gA-Bs; Sat, 10 Feb 2007 08:19:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF4Cq-0008C8-I6 for ancp@ietf.org; Thu, 08 Feb 2007 03:00:36 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF4Cp-0006J6-1d for ancp@ietf.org; Thu, 08 Feb 2007 03:00:36 -0500 Received: from bemail03.netfr.alcatel.fr (bemail03.netfr.alcatel.fr [155.132.251.37]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l1880esv001503; Thu, 8 Feb 2007 09:00:41 +0100 Received: from [172.31.156.90] ([172.31.156.90]) by bemail03.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163) with ESMTP id 2007020809003223:1872 ; Thu, 8 Feb 2007 09:00:32 +0100 Message-ID: <45CAD8A3.8010702@alcatel.be> Date: Thu, 08 Feb 2007 09:00:35 +0100 From: filip.martin@alcatel-lucent.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jakob Heitz Subject: Re: [ANCP] OAM-Loopback-Test-Parameters References: <45CA74D0.5030100@redback.com> In-Reply-To: <45CA74D0.5030100@redback.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL03/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 02/08/2007 09:00:32, Serialize by Router on BEMAIL03/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 02/08/2007 09:00:33, Serialize complete at 02/08/2007 09:00:33 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-Mailman-Approved-At: Sat, 10 Feb 2007 08:19:44 -0500 Cc: ancp@ietf.org, filip X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi, Jakob Heitz wrote: > In draft-wadhwa-gsmp-l2control-configuration-02, > for OAM-Loopback-Test-Parameters = 0x07, it says: > > Length: 4 bytes > > Value : two 1 byte numbers (listed in order of most to > least significant) > also: > > The Length field in each TLV contains > the actual number of bytes in the TLV (not including the > padding if > present). > > So, how is the length of "two 1 byte numbers" equal to "4 bytes" ? > Where are the two one byte numbers in the field of 4? > What are the other two bytes to make the total of 4? Are they padding? > > Suppose the count is 5 and the timeout is 3. > Is the hex representation like this ? > > 00 07 00 04 05 03 00 00 We support this format. We also support the "December draft 2005" format where length=8 Regards, Filip > > or like this? > > 00 07 00 04 00 00 05 03 > > or should it be like this? > > 00 07 00 02 05 03 00 00 > > or is it something else? > > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Sat Feb 10 08:20:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFs8n-0002gA-Bs; Sat, 10 Feb 2007 08:19:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF4Cq-0008C8-I6 for ancp@ietf.org; Thu, 08 Feb 2007 03:00:36 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF4Cp-0006J6-1d for ancp@ietf.org; Thu, 08 Feb 2007 03:00:36 -0500 Received: from bemail03.netfr.alcatel.fr (bemail03.netfr.alcatel.fr [155.132.251.37]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l1880esv001503; Thu, 8 Feb 2007 09:00:41 +0100 Received: from [172.31.156.90] ([172.31.156.90]) by bemail03.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163) with ESMTP id 2007020809003223:1872 ; Thu, 8 Feb 2007 09:00:32 +0100 Message-ID: <45CAD8A3.8010702@alcatel.be> Date: Thu, 08 Feb 2007 09:00:35 +0100 From: filip.martin@alcatel-lucent.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jakob Heitz Subject: Re: [ANCP] OAM-Loopback-Test-Parameters References: <45CA74D0.5030100@redback.com> In-Reply-To: <45CA74D0.5030100@redback.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL03/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 02/08/2007 09:00:32, Serialize by Router on BEMAIL03/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 02/08/2007 09:00:33, Serialize complete at 02/08/2007 09:00:33 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-Mailman-Approved-At: Sat, 10 Feb 2007 08:19:44 -0500 Cc: ancp@ietf.org, filip X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi, Jakob Heitz wrote: > In draft-wadhwa-gsmp-l2control-configuration-02, > for OAM-Loopback-Test-Parameters = 0x07, it says: > > Length: 4 bytes > > Value : two 1 byte numbers (listed in order of most to > least significant) > also: > > The Length field in each TLV contains > the actual number of bytes in the TLV (not including the > padding if > present). > > So, how is the length of "two 1 byte numbers" equal to "4 bytes" ? > Where are the two one byte numbers in the field of 4? > What are the other two bytes to make the total of 4? Are they padding? > > Suppose the count is 5 and the timeout is 3. > Is the hex representation like this ? > > 00 07 00 04 05 03 00 00 We support this format. We also support the "December draft 2005" format where length=8 Regards, Filip > > or like this? > > 00 07 00 04 00 00 05 03 > > or should it be like this? > > 00 07 00 02 05 03 00 00 > > or is it something else? > > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Sat Feb 10 08:20:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFs8n-0002gJ-Kq; Sat, 10 Feb 2007 08:19:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFDRX-0002EF-Im for ancp@ietf.From ancp-bounces@ietf.org Sat Feb 10 08:20:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFs8n-0002gJ-Kq; Sat, 10 Feb 2007 08:19:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFDRX-0002EF-Im for ancp@ietf.org; Thu, 08 Feb 2007 12:52:23 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFDRT-00083V-5b for ancp@ietf.org; Thu, 08 Feb 2007 12:52:23 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 9C6A238F0 for ; Thu, 8 Feb 2007 09:52:18 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24776-08 for ; Thu, 8 Feb 2007 09:52:18 -0800 (PST) Received: from [127.0.0.1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 77A4838EF for ; Thu, 8 Feb 2007 09:52:18 -0800 (PST) Message-ID: <45CB6352.2020905@redback.com> Date: Thu, 08 Feb 2007 09:52:18 -0800 From: Jakob Heitz User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: ancp@ietf.org Subject: Re: [ANCP] OAM-Loopback-Test-Parameters References: <2DEB3E4E9BC3774B8EEF2EF2BE9F745BFEE402@esealmw104.eemea.ericsson.se> <45CB5D71.5010209@redback.com> In-Reply-To: <45CB5D71.5010209@redback.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.5 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 X-Mailman-Approved-At: Sat, 10 Feb 2007 08:19:45 -0500 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Oops, no. This will change the length byte from 4 to 2. I change my proposal. I propose to change this: Value : two 1 byte numbers (listed in order of most to least significant) to this Value : 4 bytes comprising 1 byte Count, followed by one byte Timeout, followed by two bytes of zero. Jakob Heitz wrote: > In order to make the words less vague and to conform > to our interpretation of them, > I propose to change it to 2 bytes and to change > "listed in order of most to least significant" > to > "listed in the order transmitted" > > ie, this: > o Type (OAM-Loopback-Test-Parameters = 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. > Length: 4 bytes > > Value : two 1 byte numbers (listed in order of most to > least significant) > to this: > o Type (OAM-Loopback-Test-Parameters = 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. > Length: 2 bytes > > Value : two 1 byte numbers (listed in the order transmitted) > > The last two zero bytes are there due to the padding rule stated > elsewhere in the document. > > Kim Hyldgaard (ST/LMD) wrote: >> Hi Jakob, >> >> This is how I interpret it: >> >> 00 07 00 04 05 03 00 00 >> >> The value itself is defined as 4 bytes, so there's no padding, >> eventhough only 1+1 bytes are in use. >> >> One couldFrom ancp-bounces@ietf.org Sat Feb 10 08:20:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFs8n-0002gA-Bs; Sat, 10 Feb 2007 08:19:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF4Cq-0008C8-I6 for ancp@ietf.org; Thu, 08 Feb 2007 03:00:36 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF4Cp-0006J6-1d for ancp@ietf.org; Thu, 08 Feb 2007 03:00:36 -0500 Received: from bemail03.netfr.alcatel.fr (bemail03.netfr.alcatel.fr [155.132.251.37]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l1880esv001503; Thu, 8 Feb 2007 09:00:41 +0100 Received: from [172.31.156.90] ([172.31.156.90]) by bemail03.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163) with ESMTP id 2007020809003223:1872 ; Thu, 8 Feb 2007 09:00:32 +0100 Message-ID: <45CAD8A3.8010702@alcatel.be> Date: Thu, 08 Feb 2007 09:00:35 +0100 From: filip.martin@alcatel-lucent.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jakob Heitz Subject: Re: [ANCP] OAM-Loopback-Test-Parameters References: <45CA74D0.5030100@redback.com> In-Reply-To: <45CA74D0.5030100@redback.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL03/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 02/08/2007 09:00:32, Serialize by Router on BEMAIL03/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 02/08/2007 09:00:33, Serialize complete at 02/08/2007 09:00:33 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-Mailman-Approved-At: Sat, 10 Feb 2007 08:19:44 -0500 Cc: ancp@ietf.org, filip X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi, Jakob Heitz wrote: > In draft-wadhwa-gsmp-l2control-configuration-02, > for OAM-Loopback-Test-Parameters = 0x07, it says: > > Length: 4 bytes > > Value : two 1 byte numbers (listed in order of most to > least significant) > also: > > The Length field in each TLV contains > the actual number of bytes in the TLV (not including the > padding if > present). > > So, how is the length of "two 1 byte numbers" equal to "4 bytes" ? > Where are the two one byte numbers in the field of 4? > What are the other two bytes to make the total of 4? Are they padding? > > Suppose the count is 5 and the timeout is 3. > Is the hex representation like this ? > > 00 07 00 04 05 03 00 00 We support this format. We also support the "December draft 2005" format where length=8 Regards, Filip > > or like this? > > 00 07 00 04 00 00 05 03 > > or should it be like this? > > 00 07 00 02 05 03 00 00 > > or is it something else? > > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Sat Feb 10 08:20:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFs8n-0002gJ-Kq; Sat, 10 Feb 2007 08:19:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFDRX-0002EF-Im for ancp@ietf.org; Thu, 08 Feb 2007 12:52:23 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFDRT-00083V-5b for ancp@ietf.org; Thu, 08 Feb 2007 12:52:23 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 9C6A238F0 for ; Thu, 8 Feb 2007 09:52:18 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24776-08 for ; Thu, 8 Feb 2007 09:52:18 -0800 (PST) Received: from [127.0.0.1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 77A4838EF for ; Thu, 8 Feb 2007 09:52:18 -0800 (PST) Message-ID: <45CB6352.2020905@redback.com> Date: Thu, 08 Feb 2007 09:52:18 -0800 From: Jakob Heitz User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: ancp@ietf.org Subject: Re: [ANCP] OAM-Loopback-Test-Parameters References: <2DEB3E4E9BC3774B8EEF2EF2BE9F745BFEE402@esealmw104.eemea.ericsson.se> <45CB5D71.5010209@redback.com> In-Reply-To: <45CB5D71.5010209@redback.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.5 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 X-Mailman-Approved-At: Sat, 10 Feb 2007 08:19:45 -0500 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Oops, no. This will change the length byte from 4 to 2. I change my proposal. I propose to change this: Value : two 1 byte numbers (listed in order of most to least significant) to this Value : 4 bytes comprising 1 byte Count, followed by one byte Timeout, followed by two bytes of zero. Jakob Heitz wrote: > In order to make the words less vague and to conform > to our interpretation of them, > I propose to change it to 2 bytes and to change > "listed in order of most to least significant" > to > "listed in the order transmitted" > > ie, this: > o Type (OAM-Loopback-Test-Parameters = 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. > Length: 4 bytes > > Value : two 1 byte numbers (listed in order of most to > least significant) > to this: > o Type (OAM-Loopback-Test-Parameters = 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. > Length: 2 bytes > > Value : two 1 byte numbers (listed in the order transmitted) > > The last two zero bytes are there due to the padding rule stated > elsewhere in the document. > > Kim Hyldgaard (ST/LMD) wrote: >> Hi Jakob, >> >> This is how I interpret it: >> >> 00 07 00 04 05 03 00 00 >> >> The value itself is defined as 4 bytes, so there's no padding, >> eventhough only 1+1 bytes are in use. >> >> One could argue that the specification is a bit vague in the >> description of this parameter... :-) >> >> Kim >> >> >> -----Original Message----- >> From: Jakob Heitz [mailto:jheitz+121406@redback.com] Sent: 8. februar >> 2007 01:55 >> To: ancp@ietf.org >> Subject: [ANCP] OAM-Loopback-Test-Parameters >> >> In draft-wadhwa-gsmp-l2control-configuratioorg; Thu, 08 Feb 2007 12:52:23 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFDRT-00083V-5b for ancp@ietf.org; Thu, 08 Feb 2007 12:52:23 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 9C6A238F0 for ; Thu, 8 Feb 2007 09:52:18 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24776-08 for ; Thu, 8 Feb 2007 09:52:18 -0800 (PST) Received: from [127.0.0.1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 77A4838EF for ; Thu, 8 Feb 2007 09:52:18 -0800 (PST) Message-ID: <45CB6352.2020905@redback.com> Date: Thu, 08 Feb 2007 09:52:18 -0800 From: Jakob Heitz User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: ancp@ietf.org Subject: Re: [ANCP] OAM-Loopback-Test-Parameters References: <2DEB3E4E9BC3774B8EEF2EF2BE9F745BFEE402@esealmw104.eemea.ericsson.se> <45CB5D71.5010209@redback.com> In-Reply-To: <45CB5D71.5010209@redback.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.5 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 X-Mailman-Approved-At: Sat, 10 Feb 2007 08:19:45 -0500 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Oops, no. This will change the length byte from 4 to 2. I change my proposal. I propose to change this: Value : two 1 byte numbers (listed in order of most to least significant) to this Value : 4 bytes comprising 1 byte Count, followed by one byte Timeout, followed by two bytes of zero. Jakob Heitz wrote: > In order to make the words less vague and to conform > to our interpretation of them, > I propose to change it to 2 bytes and to change > "listed in order of most to least significant" > to > "listed in the order transmitted" > > ie, this: > o Type (OAM-Loopback-Test-Parameters = 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. > Length: 4 bytes > > Value : two 1 byte numbers (listed in order of most to > least significant) > to this: > o Type (OAM-Loopback-Test-Parameters = 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. > Length: 2 bytes > > Value : two 1 byte numbers (listed in the order transmitted) > > The last two zero bytes are there due to the padding rule stated > elsewhere in the document. > > Kim Hyldgaard (ST/LMD) wrote: >> Hi Jakob, >> >> This is how I interpret it: >> >> 00 07 00 04 05 03 00 00 >> >> The value itself is defined as 4 bytes, so there's no padding, >> eventhough only 1+1 bytes are in use. >> >> One could argue that the specification is a bit vague in the >> description of this parameter... :-) >> >> Kim >> >> >> -----Original Message----- >> From: Jakob Heitz [mailto:jheitz+121406@redback.com] Sent: 8. februar >> 2007 01:55 >> To: ancp@ietf.org >> Subject: [ANCP] OAM-Loopback-Test-Parameters >> >> In draft-wadhwa-gsmp-l2control-configuratio argue that the specification is a bit vague in the >> description of this parameter... :-) >> >> Kim >> >> >> -----Original Message----- >> From: Jakob Heitz [mailto:jheitz+121406@redback.com] Sent: 8. februar >> 2007 01:55 >> To: ancp@ietf.org >> Subject: [ANCP] OAM-Loopback-Test-Parameters >> >> In draft-wadhwa-gsmp-l2control-configuration-02, >> for OAM-Loopback-Test-Parameters = 0x07, it says: >> >> Length: 4 bytes >> >> Value : two 1 byte numbers (listed in order of most to least >> >> significant) >> also: >> >> The Length field in each TLV contains >> the actual number of bytes in the TLV (not including the >> padding if >> present). >> >> So, how is the length of "two 1 byte numbers" equal to "4 bytes" ? >> Where are the two one byte numbers in the field of 4? >> What are the other two bytes to make the total of 4? Are they padding? >> >> Suppose the count is 5 and the timeout is 3. >> Is the hex representation like this ? >> >> 00 07 00 04 05 03 00 00 >> >> or like this? >> >> 00 07 00 04 00 00 05 03 >> >> or should it be like this? >> >> 00 07 00 02 05 03 00 00 >> >> or is it something else? >> > -- Jakob Heitz. x5475. 510-566-2901 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Sat Feb 10 08:20:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFs8n-0002gE-Fq; Sat, 10 Feb 2007 08:19:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFD3H-0004g1-Ku for ancp@ietf.org; Thu, 08 Feb 2007 12:27:19 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFD3B-0002s2-Ma for ancp@ietf.org; Thu, 08 Feb 2007 12:27:19 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 1B5E3B3BDBC for ; Thu, 8 Feb 2007 09:27:13 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21567-09 for ; Thu, 8 Feb 2007 09:27:13 -0800 (PST) Received: from [127.0.0.1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id EEC88B3BDB8 for ; Thu, 8 Feb 2007 09:27:12 -0800 (PST) Message-ID: <45CB5D71.5010209@redback.com> Date: Thu, 08 Feb 2007 09:27:13 -0800 From: Jakob Heitz User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: ancp@ietf.org Subject: Re: [ANCP] OAM-Loopback-Test-Parameters References: <2DEB3E4E9BC3774B8EEF2EF2BE9F745BFEE402@esealmw104.eemea.ericsson.se> In-Reply-To: <2DEB3E4E9BC3774B8EEF2EF2BE9F745BFEE402@esealmw104.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 X-Mailman-Approved-At: Sat, 10 Feb 2007 08:19:45 -0500 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org In order to make the words less vague and to conform to our interpretation of them, I propose to change it to 2 bytes and to change "listed in order of most to least significant" to "listed in the order transmitted" ie, this: o Type (OAM-Loopback-Test-Parameters = 0x07): Parameters related to loopback test. This is an optional TLV. If this TLV is not present n-02, >> for OAM-Loopback-Test-Parameters = 0x07, it says: >> >> Length: 4 bytes >> >> Value : two 1 byte numbers (listed in order of most to least >> >> significant) >> also: >> >> The Length field in each TLV contains >> the actual number of bytes in the TLV (not including the >> padding if >> present). >> >> So, how is the length of "two 1 byte numbers" equal to "4 bytes" ? >> Where are the two one byte numbers in the field of 4? >> What are the other two bytes to make the total of 4? Are they padding? >> >> Suppose the count is 5 and the timeout is 3. >> Is the hex representation like this ? >> >> 00 07 00 04 05 03 00 00 >> >> or like this? >> >> 00 07 00 04 00 00 05 03 >> >> or should it be like this? >> >> 00 07 00 02 05 03 00 00 >> >> or is it something else? >> > -- Jakob Heitz. x5475. 510-566-2901 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Sat Feb 10 08:20:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFs8n-0002gE-Fq; Sat, 10 Feb 2007 08:19:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFD3H-0004g1-Ku for ancp@ietf.org; Thu, 08 Feb 2007 12:27:19 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFD3B-0002s2-Ma for ancp@ietf.org; Thu, 08 Feb 2007 12:27:19 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 1B5E3B3BDBC for ; Thu, 8 Feb 2007 09:27:13 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21567-09 for ; Thu, 8 Feb 2007 09:27:13 -0800 (PST) Received: from [127.0.0.1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id EEC88B3BDB8 for ; Thu, 8 Feb 2007 09:27:12 -0800 (PST) Message-ID: <45CB5D71.5010209@redback.com> Date: Thu, 08 Feb 2007 09:27:13 -0800 From: Jakob Heitz User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: ancp@ietf.org Subject: Re: [ANCP] OAM-Loopback-Test-Parameters References: <2DEB3E4E9BC3774B8EEF2EF2BE9F745BFEE402@esealmw104.eemea.ericsson.se> In-Reply-To: <2DEB3E4E9BC3774B8EEF2EF2BE9F745BFEE402@esealmw104.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 X-Mailman-Approved-At: Sat, 10 Feb 2007 08:19:45 -0500 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org In order to make the words less vague and to conform to our interpretation of them, I propose to change it to 2 bytes and to change "listed in order of most to least significant" to "listed in the order transmitted" ie, this: o Type (OAM-Loopback-Test-Parameters = 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. Length: 4 bytes Value : two 1 byte numbers (listed in order of most to least significant) to this: o Type (OAM-Loopback-Test-Parameters = 0x07): Parameters related to n-02, >> for OAM-Loopback-Test-Parameters = 0x07, it says: >> >> Length: 4 bytes >> >> Value : two 1 byte numbers (listed in order of most to least >> >> significant) >> also: >> >> The Length field in each TLV contains >> the actual number of bytes in the TLV (not including the >> padding if >> present). >> >> So, how is the length of "two 1 byte numbers" equal to "4 bytes" ? >> Where are the two one byte numbers in the field of 4? >> What are the other two bytes to make the total of 4? Are they padding? >> >> Suppose the count is 5 and the timeout is 3. >> Is the hex representation like this ? >> >> 00 07 00 04 05 03 00 00 >> >> or like this? >> >> 00 07 00 04 00 00 05 03 >> >> or should it be like this? >> >> 00 07 00 02 05 03 00 00 >> >> or is it something else? >> > -- Jakob Heitz. x5475. 510-566-2901 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Sat Feb 10 08:20:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFs8n-0002gE-Fq; Sat, 10 Feb 2007 08:19:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFD3H-0004g1-Ku for ancp@ietf.org; Thu, 08 Feb 2007 12:27:19 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFD3B-0002s2-Ma for ancp@ietf.org; Thu, 08 Feb 2007 12:27:19 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 1B5E3B3BDBC for ; Thu, 8 Feb 2007 09:27:13 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21567-09 for ; Thu, 8 Feb 2007 09:27:13 -0800 (PST) Received: from [127.0.0.1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id EEC88B3BDB8 for ; Thu, 8 Feb 2007 09:27:12 -0800 (PST) Message-ID: <45CB5D71.5010209@redback.com> Date: Thu, 08 Feb 2007 09:27:13 -0800 From: Jakob Heitz User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: ancp@ietf.org Subject: Re: [ANCP] OAM-Loopback-Test-Parameters References: <2DEB3E4E9BC3774B8EEF2EF2BE9F745BFEE402@esealmw104.eemea.ericsson.se> In-Reply-To: <2DEB3E4E9BC3774B8EEF2EF2BE9F745BFEE402@esealmw104.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 X-Mailman-Approved-At: Sat, 10 Feb 2007 08:19:45 -0500 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org In order to make the words less vague and to conform to our interpretation of them, I propose to change it to 2 bytes and to change "listed in order of most to least significant" to "listed in the order transmitted" ie, this: o Type (OAM-Loopback-Test-Parameters = 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. Length: 4 bytes Value : two 1 byte numbers (listed in order of most to least significant) to this: o Type (OAM-Loopback-Test-Parameters = 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. Length: 2 bytes Value : two 1 byte numbers (listed in the order transmitted) The last two zero bytes are there due to the padding rule stated elsewhere in the document. Kim Hyldgaard (ST/LMD) wrote: > Hi Jakob, > > This is how I interpret it: > > 00 07 00 04 05 03 00 00 > > The value itself is defined as 4 bytes, so there's no padding, > eventhough only 1+1 bytes are in use. > > One could argue that the specification is a bit vague in the > description of this parameter... :-) > > Kim > > > -----Original Message----- > From: Jakob Heitz [mailto:jheitz+121406@redback.com] > Sent: 8. februar 2007 01:55 > To: ancp@ietf.org > Subject: [ANCP] OAM-Loopback-Test-Parameters > > In draft-wadhwa-gsmp-l2control-configuration-02, > for OAM-Loopback-Test-Parameters = 0x07, it says: > > Length: 4 bytes > > Value : two 1 byte numbers (listed in order of most to least > > significant) > > also: > > The Length field in each TLV contains > the actual number of bytes in the TLV (not including the padding if > present). > > So, how is the length of "two 1 byte numbers" equal to "4 bytes" ? > Where are the two one byte numbers in the field of 4? > What are the other two bytes to make the total of 4? Are they padding? > > Suppose the count is 5 and the timeout is 3. > Is the hex representation like this ? > > 00 07 00 04 05 03 00 00 > > or like this? > > 00 07 00 04 00 00 05 03 > > or should it be like this? > > 00 07 00 02 05 03 00 00 > > or is it something else? > -- Jakob Heitz. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp in the request message, the DSLAM SHOULD use locally determined default values for the test parameters. Length: 4 bytes Value : two 1 byte numbers (listed in order of most to least significant) to this: o Type (OAM-Loopback-Test-Parameters = 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. Length: 2 bytes Value : two 1 byte numbers (listed in the order transmitted) The last two zero bytes are there due to the padding rule stated elsewhere in the document. Kim Hyldgaard (ST/LMD) wrote: > Hi Jakob, > > This is how I interpret it: > > 00 07 00 04 05 03 00 00 > > The value itself is defined as 4 bytes, so there's no padding, > eventhough only 1+1 bytes are in use. > > One could argue that the specification is a bit vague in the > description of this parameter... :-) > > Kim > > > -----Original Message----- > From: Jakob Heitz [mailto:jheitz+121406@redback.com] > Sent: 8. februar 2007 01:55 > To: ancp@ietf.org > Subject: [ANCP] OAM-Loopback-Test-Parameters > > In draft-wadhwa-gsmp-l2control-configuration-02, > for OAM-Loopback-Test-Parameters = 0x07, it says: > > Length: 4 bytes > > Value : two 1 byte numbers (listed in order of most to least > > significant) > > also: > > The Length field in each TLV contains > the actual number of bytes in the TLV (not including the padding if > present). > > So, how is the length of "two 1 byte numbers" equal to "4 bytes" ? > Where are the two one byte numbers in the field of 4? > What are the other two bytes to make the total of 4? Are they padding? > > Suppose the count is 5 and the timeout is 3. > Is the hex representation like this ? > > 00 07 00 04 05 03 00 00 > > or like this? > > 00 07 00 04 00 00 05 03 > > or should it be like this? > > 00 07 00 02 05 03 00 00 > > or is it something else? > -- Jakob Heitz. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp 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. Length: 2 bytes Value : two 1 byte numbers (listed in the order transmitted) The last two zero bytes are there due to the padding rule stated elsewhere in the document. Kim Hyldgaard (ST/LMD) wrote: > Hi Jakob, > > This is how I interpret it: > > 00 07 00 04 05 03 00 00 > > The value itself is defined as 4 bytes, so there's no padding, > eventhough only 1+1 bytes are in use. > > One could argue that the specification is a bit vague in the > description of this parameter... :-) > > Kim > > > -----Original Message----- > From: Jakob Heitz [mailto:jheitz+121406@redback.com] > Sent: 8. februar 2007 01:55 > To: ancp@ietf.org > Subject: [ANCP] OAM-Loopback-Test-Parameters > > In draft-wadhwa-gsmp-l2control-configuration-02, > for OAM-Loopback-Test-Parameters = 0x07, it says: > > Length: 4 bytes > > Value : two 1 byte numbers (listed in order of most to least > > significant) > > also: > > The Length field in each TLV contains > the actual number of bytes in the TLV (not including the padding if > present). > > So, how is the length of "two 1 byte numbers" equal to "4 bytes" ? > Where are the two one byte numbers in the field of 4? > What are the other two bytes to make the total of 4? Are they padding? > > Suppose the count is 5 and the timeout is 3. > Is the hex representation like this ? > > 00 07 00 04 05 03 00 00 > > or like this? > > 00 07 00 04 00 00 05 03 > > or should it be like this? > > 00 07 00 02 05 03 00 00 > > or is it something else? > -- Jakob Heitz. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Sun Feb 11 16:11:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGLyi-0004g0-CO; Sun, 11 Feb 2007 16:11:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGLyh-0004fv-TC for ancp@ietf.org; Sun, 11 Feb 2007 16:11:19 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGLya-0008Cv-4O for ancp@ietf.org; Sun, 11 Feb 2007 16:11:19 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3726220210; Sun, 11 Feb 2007 22:11:01 +0100 (CET) X-AuditID: c1b4fb3e-b06d4bb0000007e1-74-45cf8664821c Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EA1AA20084; Sun, 11 Feb 2007 22:11:00 +0100 (CET) Received: from esealmw104.eemea.ericsson.se ([153.88.200.67]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Feb 2007 22:11:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ANCP] OAM-Loopback-Test-Parameters Date: Sun, 11 Feb 2007 22:10:58 +0100 Message-ID: <2DEB3E4E9BC3774B8EEF2EF2BE9F745B0101D462@esealmw104.eemea.ericsson.se> In-Reply-To: <45CB6352.2020905@redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] OAM-Loopback-Test-Parameters Thread-Index: AcdNFkuXrsDaXjynTfWnrSLeWsgL5wBCriwA From: "Kim Hyldgaard \(ST/LMD\)" To: "Jakob Heitz" , X-OriginalArrivalTime: 11 Feb 2007 21:11:00.0015 (UTC) FILETIME=[212293F0:01C74E21] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Jakob, This will clearify things a great deal - I think it's a good suggestion. Br Kim=20 -----Original Message----- From: Jakob Heitz [mailto:jheitz+020707@redback.com]=20 Sent: 8. februar 2007 18:52 To: ancp@ietf.org Subject: Re: [ANCP] OAM-Loopback-Test-Parameters Oops, no. This will change the length byte from 4 to 2. I change my proposal. I propose to change this: Value : two 1 byte numbers (listed in order of most to least significant)=20 to this Value : 4 bytes comprising 1 byte Count, followed by one byte Timeout, followed by two bytes of zero. Jakob Heitz wrote: > In order to make the words less vague and to conform to our=20 > interpretation of them, I propose to change it to 2 bytes and to=20 > change "listed in order of most to least significant" > to > "listed in the order transmitted" > > ie, this: > o Type (OAM-Loopback-Test-Parameters =3D 0x07): Parameters=20 > related to loopback test. This is an optional TLV. If this=20 > TLV is not present > in the request message, the DSLAM SHOULD use locally determined > default values for the test parameters. > Length: 4 bytes > > Value : two 1 byte numbers (listed in order of most to=20 > least significant) > to this: > o Type (OAM-Loopback-Test-Parameters =3D 0x07): Parameters=20 > related to loopback test. This is an optional TLV. If this=20 > TLV is not present > in the request message, the DSLAM SHOULD use locally determined > default values for the test parameters. > Length: 2 bytes > > Value : two 1 byte numbers (listed in the order=20 > transmitted) > > The last two zero bytes are there due to the padding rule stated=20 > elsewhere in the document. > > Kim Hyldgaard (ST/LMD) wrote: >> Hi Jakob, >> >> This is how I interpret it: >> >> 00 07 00 04 05 03 00 00 >> >> The value itself is defined as 4 bytes, so there's no padding,=20 >> eventhough only 1+1 bytes are in use. >> >> One could argue that the specification is a bit vague in the=20 >> description of this parameter... :-) >> >> Kim >> =20 >> >> -----Original Message----- >> From: Jakob Heitz [mailto:jheitz+121406@redback.com] Sent: 8. februar >> 2007 01:55 >> To: ancp@ietf.org >> Subject: [ANCP] OAM-Loopback-Test-Parameters >> >> In draft-wadhwa-gsmp-l2control-configuration-02, >> for OAM-Loopback-Test-Parameters =3D 0x07, it says: >> >> Length: 4 bytes >> >> Value : two 1 byte numbers (listed in order of most to=20 >> least >> >> significant) >> also: >> >> The Length field in each TLV contains >> the actual number of bytes in the TLV (not including the=20 >> padding if >> present). >> >> So, how is the length of "two 1 byte numbers" equal to "4 bytes" ? >> Where are the two one byte numbers in the field of 4? >> What are the other two bytes to make the total of 4? Are they padding? >> >> Suppose the count is 5 and the timeout is 3. >> Is the hex representation like this ? >> >> 00 07 00 04 05 03 00 00 >> >> or like this? >> >> 00 07 00 04 00 00 05 03 >> >> or should it be like this? >> >> 00 07 00 02 05 03 00 00 >> >> or is it something else? >> =20 > -- Jakob Heitz. x5475. 510-566-2901 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Feb 15 02:28:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHb2Y-0000Yh-Bq; Thu, 15 Feb 2007 02:28:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHR5F-0006Py-Sh; Wed, 14 Feb 2007 15:50:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HHR5F-0008Na-EO; Wed, 14 Feb 2007 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id BFE7B17610; Wed, 14 Feb 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HHR4j-0004Ja-Vv; Wed, 14 Feb 2007 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 14 Feb 2007 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 X-Mailman-Approved-At: Thu, 15 Feb 2007 02:28:25 -0500 Cc: ancp@ietf.org Subject: [ANCP] I-D ACTION:draft-ietf-ancp-framework-01.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 : Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks Author(s) : S. Ooghe, et al. Filename : draft-ietf-ancp-framework-01.txt Pages : 34 Date : 2007-2-14 The purpose of this document is to define a framework for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform QoS-related, service-related and Subscriber-related operations. The Access Node Control Mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather using a direct device-device communication. This allows for performing access link related operations within those network elements, while avoiding impact on the existing OSS systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-framework-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ancp-framework-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ancp-framework-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-14123227.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ancp-framework-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ancp-framework-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-14123227.I-D@ietf.org> --OtherAccess-- --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://www1.ietf.org/mailman/listinfo/ancp --NextPart-- From ancp-bounces@ietf.org Mon Feb 19 11:55:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJBnB-00065o-H8; Mon, 19 Feb 2007 11:55:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJBnA-00065h-P3 for ancp@ietf.org; Mon, 19 Feb 2007 11:55:08 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJBn9-0005ep-0i for ancp@ietf.org; Mon, 19 Feb 2007 11:55:08 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 19 Feb 2007 17:55:06 +0100 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 l1JGt6KT016321 for ; Mon, 19 Feb 2007 17:55:06 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1JGstCC016183 for ; Mon, 19 Feb 2007 17:55:06 +0100 (MET) 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, 19 Feb 2007 17:54:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Feb 2007 17:54:49 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Access topology discovery Thread-Index: AcdUQFk/441N/KbxQfGbkqW6hB7wIA== From: "Wojciech Dec \(wdec\)" To: X-OriginalArrivalTime: 19 Feb 2007 16:54:55.0638 (UTC) FILETIME=[AE8EB360:01C75446] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8427; t=1171904106; x=1172768106; 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:=20Access=20topology=20discovery |Sender:=20; bh=cqv4midRJIwBb43AH+T/rZVLAzmcBP0p9VUfZAur7as=; b=QpsTCts7Kw8zMRIXSIEhh2Oeb14JIdFcDAhUQNpFPAglD35LUCT0WGbZULWEF7+AU26zTyAT CzLVb6H2gBUyCtWVVesyyQNrrFgFDyjpDCGmdFNfirsQC7yg7HIsKv4y; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Subject: [ANCP] Access topology discovery X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 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="===============0652867878==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0652867878== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75446.AE87DF9B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C75446.AE87DF9B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, First off, thanks to the editor for posting the latest version of the draft. I would like to propose some modifications to Section 3.1 of the latest draft-ancp-framework-01 text to better deal with the nature of the problem of hierarchical scheduling and access-loop discovery.=20 Section 3.1 - Dynamic Access Loop Attributes The section describes the role of the Hierarchical Scheduling in the context of access loop and aggregation uplink discovery, and correctly states that in order to build a 3 level HS information about the access-loop and access-node uplink is useful. With this in mind, I would like to propose to change the title of this section back to "Access topology discovery" (Admittedly not too far off from the title this section had in the past...) The section proceeds to list a number of attributes for the access loop that are desirable to be sent. However it does not provide a similar attribute list for the access-node uplink, and I would like to propose that the following be included as an initial set: - The unique identification (interface-id) of the uplink. - The type of the access-node uplink (eg Ethernet, ATM, PON, ...) - The encaps of the access-node uplink (eg n/a, 802.1Q, 802.1ad, ...) - The up-speed of the access-node uplink - The down-speed of the access-node uplink - The state of the access-node uplink Furthermore, for the purpose of deriving an accurate HS in the presence of uplink bundling (eg 802.3ad), it would be useful for the access-node to report information about the such bundling being active. This would minimally require that for each uplink that is configured and active in a link bundle the protocol conveys information about the link's bundle membership, eg - Member of link-bundle-id. Since some types of access-nodes can have multiple uplinks, including a mix of ATM and Ethernet, I think it would make sense to also be able to convey info from the access-node about the active mapping of access-loop to access-node uplink, eg DSL port 1/1 maps to uplink 1, DSL port 2/1 maps to uplink 2. For this it would probably make sense to introduce an additional information element in both the access-loop and uplink characteristics, which can be used to tie the two together. A simple proposal one could make is to add the uplink's id as a characteristic of the access-loop, i.e. - "Access-node uplink id" added to the access-loop attribute lists. This however has the downside that should the uplink for a particular access-loop change, eg due to the activation of a standby up-link mechanism commonly found on access-nodes, all access-loops would need to be re-signalled. Thus, it would appear to be better to introduce a parameter that would avoid such re-signalling, and I would like to propose the following: 1) including in the access-loop the uplink VLAN or VP/VC to which that access-loop is currently mapped to,=20 2) include in the uplink's description a list of currently active and forwarding VLANs or VP/VCs. If an access-node uplink should fail, eg a standby link become activated, all that would be required to be communicated would be an update of the uplink status. Looking forward to the discussion and/or inclusion of these additions in the ANCP framework draft. Regards, Woj. ------_=_NextPart_001_01C75446.AE87DF9B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Access topology discovery

Hi All,

First off, thanks to the editor for = posting the latest version of the draft.

I would like to propose some = modifications to Section 3.1 of the latest draft-ancp-framework-01 text = to better deal with the nature of the problem of hierarchical scheduling = and access-loop discovery.

Section 3.1 - Dynamic Access Loop = Attributes
The section describes the role of the = Hierarchical Scheduling in the context of access loop and aggregation = uplink discovery, and correctly states that in order to build a 3 level = HS information about the access-loop and access-node uplink is useful. = With this in mind, I would like to propose to change the title of this = section back to "Access topology discovery" (Admittedly not = too far off from the title this section had in the past...)

The section proceeds to list a number = of attributes for the access loop that are desirable to be sent. However = it does not provide a similar attribute list for the access-node uplink, = and I would like to propose that the following be included as an initial = set:

- The unique identification = (interface-id) of the uplink.
- The type of the access-node uplink = (eg Ethernet, ATM, PON, …)
- The encaps of the access-node uplink = (eg n/a, 802.1Q, 802.1ad, ...)
- The up-speed of the access-node = uplink
- The down-speed of the access-node = uplink
- The state of the access-node = uplink

Furthermore, for the purpose of = deriving an accurate HS in the presence of uplink bundling  (eg = 802.3ad), it would be useful for the access-node to report information = about the such bundling being active. This would minimally require that = for each uplink that is configured and active in a link bundle the = protocol conveys information about the link's bundle membership, eg - = Member of link-bundle-id.

Since some types of access-nodes can = have multiple uplinks, including a mix of ATM and Ethernet, I think it = would make sense to also be able to convey info from the access-node = about the active mapping of access-loop to access-node uplink, eg DSL = port 1/1 maps to uplink 1, DSL port 2/1 maps to uplink 2. For this it = would probably make sense to introduce an additional information element = in both the access-loop and uplink characteristics, which can be used to = tie the two together. A simple proposal one could make is to add the = uplink's id as a characteristic of the access-loop, i.e. - = "Access-node uplink id" added to the access-loop attribute = lists.

This however has the downside that = should the uplink for a particular access-loop change, eg due to the = activation of a standby up-link mechanism commonly found on = access-nodes, all access-loops would need to be re-signalled. Thus, it = would appear to be better to introduce a parameter that would avoid such = re-signalling, and I would like to propose the following:

1) including in the access-loop the = uplink VLAN or VP/VC to which that access-loop is currently mapped to, =
2) include in the uplink's description = a list of currently active and forwarding VLANs or VP/VCs.

If an access-node uplink should fail, = eg a standby link become activated, all that would be required to be = communicated would be an update of the uplink status.

Looking forward to the discussion = and/or inclusion of these additions in the ANCP framework draft.

Regards,
Woj.





------_=_NextPart_001_01C75446.AE87DF9B-- --===============0652867878== 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://www1.ietf.org/mailman/listinfo/ancp --===============0652867878==-- From ancp-bounces@ietf.org Tue Feb 20 05:21:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJS7D-0000jh-5A; Tue, 20 Feb 2007 05:20:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJS7C-0000jb-DY for ancp@ietf.org; Tue, 20 Feb 2007 05:20:54 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJS79-0002Sl-Tn for ancp@ietf.org; Tue, 20 Feb 2007 05:20:54 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Tue, 20 Feb 2007 11:20:50 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 11:20:50 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [ANCP] OAM-Loopback-Test-Parameters Date: Tue, 20 Feb 2007 11:20:49 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2C458D2@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <2DEB3E4E9BC3774B8EEF2EF2BE9F745B0101D462@esealmw104.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] OAM-Loopback-Test-Parameters Thread-Index: AcdNFkuXrsDaXjynTfWnrSLeWsgL5wBCriwAAa3htXA= From: "Busser, M" To: X-OriginalArrivalTime: 20 Feb 2007 10:20:50.0480 (UTC) FILETIME=[CB5BAB00:01C754D8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi all. I also think, that this is a good suggestion.=20 Best Regards; Freundliche Gr=FC=DFe=20 Michael Busser T-Systems Enterprise Services GmbH -----Urspr=FCngliche Nachricht----- Von: Kim Hyldgaard (ST/LMD) [mailto:kim.hyldgaard@ericsson.com]=20 Gesendet: Sonntag, 11. Februar 2007 22:11 An: Jakob Heitz; ancp@ietf.org Betreff: RE: [ANCP] OAM-Loopback-Test-Parameters Hi Jakob, This will clearify things a great deal - I think it's a good suggestion. Br Kim=20 -----Original Message----- From: Jakob Heitz [mailto:jheitz+020707@redback.com]=20 Sent: 8. februar 2007 18:52 To: ancp@ietf.org Subject: Re: [ANCP] OAM-Loopback-Test-Parameters Oops, no. This will change the length byte from 4 to 2. I change my proposal. I propose to change this: Value : two 1 byte numbers (listed in order of most to least significant)=20 to this Value : 4 bytes comprising 1 byte Count, followed by one byte Timeout, followed by two bytes of zero. Jakob Heitz wrote: > In order to make the words less vague and to conform to our > interpretation of them, I propose to change it to 2 bytes and to=20 > change "listed in order of most to least significant" > to > "listed in the order transmitted" > > ie, this: > o Type (OAM-Loopback-Test-Parameters =3D 0x07): Parameters=20 > related to loopback test. This is an optional TLV. If this=20 > TLV is not present > in the request message, the DSLAM SHOULD use locally determined > default values for the test parameters. > Length: 4 bytes > > Value : two 1 byte numbers (listed in order of most to=20 > least significant) > to this: > o Type (OAM-Loopback-Test-Parameters =3D 0x07): Parameters=20 > related to loopback test. This is an optional TLV. If this=20 > TLV is not present > in the request message, the DSLAM SHOULD use locally determined > default values for the test parameters. > Length: 2 bytes > > Value : two 1 byte numbers (listed in the order > transmitted) > > The last two zero bytes are there due to the padding rule stated > elsewhere in the document. > > Kim Hyldgaard (ST/LMD) wrote: >> Hi Jakob, >> >> This is how I interpret it: >> >> 00 07 00 04 05 03 00 00 >> >> The value itself is defined as 4 bytes, so there's no padding, >> eventhough only 1+1 bytes are in use. >> >> One could argue that the specification is a bit vague in the >> description of this parameter... :-) >> >> Kim >> =20 >> >> -----Original Message----- >> From: Jakob Heitz [mailto:jheitz+121406@redback.com] Sent: 8. februar = >> 2007 01:55 >> To: ancp@ietf.org >> Subject: [ANCP] OAM-Loopback-Test-Parameters >> >> In draft-wadhwa-gsmp-l2control-configuration-02, >> for OAM-Loopback-Test-Parameters =3D 0x07, it says: >> >> Length: 4 bytes >> >> Value : two 1 byte numbers (listed in order of most to >> least >> >> significant) >> also: >> >> The Length field in each TLV contains >> the actual number of bytes in the TLV (not including the >> padding if >> present). >> >> So, how is the length of "two 1 byte numbers" equal to "4 bytes" ?=20 >> Where are the two one byte numbers in the field of 4? What are the=20 >> other two bytes to make the total of 4? Are they padding? >> >> Suppose the count is 5 and the timeout is 3. >> Is the hex representation like this ? >> >> 00 07 00 04 05 03 00 00 >> >> or like this? >> >> 00 07 00 04 00 00 05 03 >> >> or should it be like this? >> >> 00 07 00 02 05 03 00 00 >> >> or is it something else? >> =20 > -- Jakob Heitz. x5475. 510-566-2901 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Feb 22 19:55:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKOiR-0003rV-MY; Thu, 22 Feb 2007 19:55:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKOiQ-0003lp-Lu for ancp@ietf.org; Thu, 22 Feb 2007 19:55:14 -0500 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKOiP-0005Am-Sa for ancp@ietf.org; Thu, 22 Feb 2007 19:55:14 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 22 Feb 2007 16:55:13 -0800 X-IronPort-AV: i="4.14,207,1170662400"; d="scan'208,217"; a="679884778:sNHT100670212" X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] Access topology discovery Date: Thu, 22 Feb 2007 19:55:10 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280764326F@proton.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Access topology discovery Thread-index: AcdUQFk/441N/KbxQfGbkqW6hB7wIACoR/5Q From: "Sanjay Wadhwa" To: "Wojciech Dec \(wdec\)" , X-Spam-Score: 1.1 (+) X-Scan-Signature: 17589c7043b24a47064a4b7516f59671 Cc: X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 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="===============1476741944==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1476741944== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C756E5.45C3EB9F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C756E5.45C3EB9F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Woj I am ok with uplink attributes in ANCP. The protocol draft alludes to it when describing certain TLVs. However, I am not convinced LAG membership info belongs in ANCP. H-QOS in case of LAG (possibly spanning different line modules on a chassis) can be aided by two ends of a LAG agreeing upon a common mapping of a subscriber (or access-loop) to a link in a LAG. However, the LAG can be between DSLAM and BSR (in a direct-connect model), between DSLAM and aggregation elements, between aggregation elements themselves, and between aggregation elements and BSR. ANCP doesn't apply to all the cases. I consider LACP (with suitable extensions) to be more generally applicable. =20 Regards -Sanjay =20 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: Monday, February 19, 2007 11:55 AM To: ancp@ietf.org Subject: [ANCP] Access topology discovery =20 Hi All,=20 First off, thanks to the editor for posting the latest version of the draft.=20 I would like to propose some modifications to Section 3.1 of the latest draft-ancp-framework-01 text to better deal with the nature of the problem of hierarchical scheduling and access-loop discovery.=20 Section 3.1 - Dynamic Access Loop Attributes=20 The section describes the role of the Hierarchical Scheduling in the context of access loop and aggregation uplink discovery, and correctly states that in order to build a 3 level HS information about the access-loop and access-node uplink is useful. With this in mind, I would like to propose to change the title of this section back to "Access topology discovery" (Admittedly not too far off from the title this section had in the past...) The section proceeds to list a number of attributes for the access loop that are desirable to be sent. However it does not provide a similar attribute list for the access-node uplink, and I would like to propose that the following be included as an initial set: - The unique identification (interface-id) of the uplink.=20 - The type of the access-node uplink (eg Ethernet, ATM, PON, ...)=20 - The encaps of the access-node uplink (eg n/a, 802.1Q, 802.1ad, ...)=20 - The up-speed of the access-node uplink=20 - The down-speed of the access-node uplink=20 - The state of the access-node uplink=20 Furthermore, for the purpose of deriving an accurate HS in the presence of uplink bundling (eg 802.3ad), it would be useful for the access-node to report information about the such bundling being active. This would minimally require that for each uplink that is configured and active in a link bundle the protocol conveys information about the link's bundle membership, eg - Member of link-bundle-id. Since some types of access-nodes can have multiple uplinks, including a mix of ATM and Ethernet, I think it would make sense to also be able to convey info from the access-node about the active mapping of access-loop to access-node uplink, eg DSL port 1/1 maps to uplink 1, DSL port 2/1 maps to uplink 2. For this it would probably make sense to introduce an additional information element in both the access-loop and uplink characteristics, which can be used to tie the two together. A simple proposal one could make is to add the uplink's id as a characteristic of the access-loop, i.e. - "Access-node uplink id" added to the access-loop attribute lists. This however has the downside that should the uplink for a particular access-loop change, eg due to the activation of a standby up-link mechanism commonly found on access-nodes, all access-loops would need to be re-signalled. Thus, it would appear to be better to introduce a parameter that would avoid such re-signalling, and I would like to propose the following: 1) including in the access-loop the uplink VLAN or VP/VC to which that access-loop is currently mapped to,=20 2) include in the uplink's description a list of currently active and forwarding VLANs or VP/VCs.=20 If an access-node uplink should fail, eg a standby link become activated, all that would be required to be communicated would be an update of the uplink status. Looking forward to the discussion and/or inclusion of these additions in the ANCP framework draft.=20 Regards,=20 Woj.=20 ------_=_NextPart_001_01C756E5.45C3EB9F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Access topology discovery

Hi Woj

   I am ok with uplink attributes in ANCP. The protocol draft alludes to it when describing = certain TLVs. However, I am not convinced LAG membership info belongs in ANCP. = H-QOS in case of LAG (possibly = spanning different line modules on a chassis) can be aided by two ends of a LAG = agreeing upon a common mapping of a subscriber (or access-loop) to a link in a = LAG. However, the LAG can be between DSLAM and BSR (in a direct-connect model), = between DSLAM and aggregation elements, between aggregation elements = themselves, and between aggregation elements = and BSR.  ANCP doesn’t apply to all the cases. I consider LACP (with suitable extensions) to be more generally = applicable.

 

Regards

=

-Sanjay

=

 

From: = Wojciech Dec (wdec) [mailto:wdec@cisco.com]
Sent: Monday, February = 19, 2007 11:55 AM
To: ancp@ietf.org
Subject: [ANCP] Access = topology discovery

 

Hi All,

First off, thanks to the editor for posting the latest version of the = draft.

I would like to propose some modifications to Section 3.1 of the latest draft-ancp-framework-01 text = to better deal with the nature of the problem of hierarchical scheduling = and access-loop discovery.

Section 3.1 - Dynamic Access Loop Attributes
The section describes the role of the = Hierarchical Scheduling in the context of access loop and aggregation uplink = discovery, and correctly states that in order to build a 3 level HS information about = the access-loop and access-node uplink is useful. With this in mind, I would like to propose to change the title of this section back to "Access topology discovery" (Admittedly not too far = off from the title this section had = in the past...)

The section proceeds to list a = number of attributes for the access loop that are desirable to be sent. However it does not provide a similar attribute list for the access-node uplink, and I would like to propose that the following be included as an initial set:

- The unique identification (interface-id) of the uplink. =
- The type of the access-node uplink (eg Ethernet, ATM, PON, = …)
- The encaps of the access-node uplink (eg n/a, 802.1Q, 802.1ad, = ...)
- The up-speed of the access-node uplink
- The down-speed of the access-node uplink
- The state of the access-node uplink

Furthermore, for the purpose of deriving = an accurate HS in the presence = of uplink bundling  (eg 802.3ad), it would be useful for the access-node to report information about the such bundling being = active. This would minimally require that for each uplink that is configured and = active in a link bundle the protocol conveys information about the link's = bundle membership, eg - Member of link-bundle-id.

Since some types of access-nodes can have multiple uplinks, including a mix of = ATM and Ethernet, I think it would make sense to also be able to convey info from the access-node about the active mapping of access-loop to access-node = uplink, eg DSL port 1/1 maps to uplink 1, DSL port 2/1 maps to uplink 2. For this = it would probably make sense to introduce an additional information = element in both the access-loop and uplink characteristics, which can be = used to tie the two together. A simple = proposal one could make is to add the uplink's id as a characteristic of the = access-loop, i.e. - "Access-node uplink id" added to the access-loop = attribute lists.

This however has the downside that should the uplink for a particular = access-loop change, eg due to the activation of a standby up-link mechanism commonly = found on access-nodes, all access-loops would need to be re-signalled. Thus, = it would appear to be better to introduce a parameter that would avoid such re-signalling, and I would like to propose the following:

1) including in the access-loop the uplink VLAN or VP/VC to which that = access-loop is currently mapped to,
2) include in the uplink's description a list of currently active and = forwarding VLANs or VP/VCs.

If an access-node uplink should fail, eg a standby link become activated, = all that would be required to be communicated would be an update of the uplink = status.

Looking forward to the discussion and/or inclusion of these additions in the ANCP framework draft.

Regards,
Woj.




------_=_NextPart_001_01C756E5.45C3EB9F-- --===============1476741944== 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://www1.ietf.org/mailman/listinfo/ancp --===============1476741944==-- From ancp-bounces@ietf.org Fri Feb 23 03:35:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKVu3-0001qp-HU; Fri, 23 Feb 2007 03:35:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKVu1-0001qT-Na for ancp@ietf.org; Fri, 23 Feb 2007 03:35:41 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKVtx-0002WP-8D for ancp@ietf.org; Fri, 23 Feb 2007 03:35:41 -0500 Received: from gbmail02.netfr.alcatel.fr (gbmail02.netfr.alcatel.fr [155.132.251.26]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l1N8ZabH021215 for ; Fri, 23 Feb 2007 09:35:37 +0100 To: ancp@ietf.org X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Matthew.Bocci@alcatel-lucent.co.uk Date: Fri, 23 Feb 2007 08:35:26 +0000 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 02/23/2007 08:35:29 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [ANCP] Prague meeting slots X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Folks, We have a 2 hour session for ANCP, tentatively scheduled for 13:00 on Tuesday 20th March. Please can you let me know if you would like a slot to present during the meeting, by 6th March. As usual, please include a brief summary of what you want to talk about, a pointer to the draft (if any), and the time. Best regards, Matthew _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Feb 26 15:40:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmdt-0000st-Ak; Mon, 26 Feb 2007 15:40:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmds-0000sE-GT for ancp@ietf.org; Mon, 26 Feb 2007 15:40:16 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLmdq-0004Es-Of for ancp@ietf.org; Mon, 26 Feb 2007 15:40:16 -0500 Received: from bemail01.netfr.alcatel.fr (bemail01.netfr.alcatel.fr [155.132.251.32]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l1QKeHaE029701; Mon, 26 Feb 2007 21:40:17 +0100 Received: from [172.17.241.150] ([172.17.241.150]) by bemail01.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163) with ESMTP id 2007022621400870:11821 ; Mon, 26 Feb 2007 21:40:08 +0100 Message-ID: <45E345A9.7040002@alcatel-lucent.be> Date: Mon, 26 Feb 2007 21:40:09 +0100 From: Sven.Ooghe@alcatel-lucent.be Organization: Alcatel-Lucent User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Wojciech Dec (wdec)" Subject: Re: [ANCP] Access topology discovery References: <9BD5D7887235424FA97DFC223CAE3C280764326F@proton.jnpr.net> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C280764326F@proton.jnpr.net> X-MIMETrack: Itemize by SMTP Server on BEMAIL01/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 02/26/2007 21:40:08, Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 02/26/2007 21:40:11 X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.3 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 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="===============1408355435==" Errors-To: ancp-bounces@ietf.org --===============1408355435== Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: base64 SGkgV29qLA0KDQpVcGRhdGluZyB0aGUgdG9wb2xneSBkaXNjb3ZlcnkgZGlzY3Vzc2lvbiBpbiB0 aGUgQU5DUCBmcmFtZXdvcmsgd291bGQNCmluZGVlZCBtYWtlIGl0IGluIGxpbmUgd2l0aCB0aGUg cHJvdG9jb2wgZHJhZnQuDQoNCkkgc3VwcG9ydCBTYW5qYXkncyBzdGF0ZW1lbnQgYmVsb3c6IExB RyBtZW1iZXJzaGlwIHNob3VsZCBub3QgYmUgcGFydCBvZiANCkFOQ1AgLSB0aGUgdXNlIG9mIGxp bmsgYWdncmVnYXRpb24gc2hvdWxkIGJlIHNoaWVsZGVkIGZyb20gdGhlIEFOQ1AgDQpwcm90b2Nv bCBvcGVyYXRpb24uIFRoaXMgZWFzZXMgdGhlIG9wZXJhdGlvbmFsIG1vZGVsLg0KDQpBYm91dCBt dWx0aXBsZSBBY2Nlc3MgTm9kZSB1cGxpbmtzOiBJJ20gYSBiaXQgY29uZnVzZWQgYWJvdXQgd2h5 IHdlIHdhbnQgDQp0byBpbnRyb2R1Y2UgbmV3IGluZm8gaW4gdGhlIEFOQ1AgbWVzc2FnZXMgdGhh dCBhbGxvd3MgbGlua2luZyBhIHBvcnQgdG8gDQphbiBBY2Nlc3MgTm9kZSB1cGxpbmsuIEhlcmUg YXJlIHRoZSBzY2VuYXJpb3MgSSBoYXZlIGluIG1pbmQ6DQoNCjEpIG11bHRpcGxlIHVwbGlua3Mg Z28gdG8gZGlmZmVyZW50IE5BUy4gQWNjZXNzIHBvcnRzIGFyZSBhc3NvY2lhdGVkIA0Kd2l0aCBh IHBhcnRpY3VsYXIgQVRNIFZQIG9yIEV0aGVybmV0IFZMQU4gb24gYSBzcGVjaWZpYyB1cGxpbmsg dG8gYSANCnNwZWNpZmljIE5BUy4gSW4gdGhpcyBjYXNlLCBJIGFzc3VtZSB0aGUgQWNjZXNzIE5v ZGUgZXN0YWJsaXNoZXMgYW4gQU5DUCANCkFkamFjZW5jeSB3aXRoIGVhY2ggTkFTLCBhbmQgdXNl cyBzZXBhcmF0ZSBBTkNQIHNpZ25hbGluZyB0byBlYWNoIE5BUy4NCg0KQXMgYSBzcGVjaWFsIGNh c2Ugb2YgMSkgdGhlcmUncyB0aGUgdXNlIG9mIGFuIEFUTSBhbmQgYW4gRXRoZXJuZXQgdXBsaW5r DQoNCjIpIG11bHRpcGxlIHVwbGlua3MgZ28gdG8gdGhlIHNhbWUgTkFTLg0KDQoyYV0gQm90aCB1 cGxpbmsgcG9ydHMgb24gdGhlIEFjY2VzcyBOb2RlIGJlbG9uZyB0byB0aGUgc2FtZSBFdGhlcm5l dCANClZMQU4uIEluIHRoaXMgY2FzZSwgdGhlIFNwYW5uaW5nIFRyZWUgUHJvdG9jb2wgd2lsbCBt b3N0IGxpa2VseSBwdXQgb25lIA0Kb2YgYm90aCBsaW5rcyBpbnRvIGEgYmxvY2tpbmcgc3RhdGUg dG8gYXZvaWQgbG9vcHMuIFRoYXQgbWVhbnMgdGhhdCBhbGwgDQp0cmFmZmljIHdpbGwgYmUgc2Vu dCB0byB0aGUgTkFTIHVzaW5nIHRoZSAiYWN0aXZlIiBBY2Nlc3MgTm9kZSB1cGxpbmsuIA0KVXBv biBmYWlsdXJlIG9mIHRoZSBhY3RpdmUgbGluaywgdGhlIG90aGVyIGxpbmsgd2lsbCBiZSBwdXQg b3V0IG9mIHRoZSANCmJsb2NraW5nIHN0YXRlIGFuZCB0cmFmZmljIHdpbGwgYmUgZGlyZWN0ZWQg dG8gdGhlIE5BUyB1c2luZyB0aGUgbmV3IGxpbmsuDQoNCkluIHRoaXMgc2NlbmFyaW8sIHRoZSBO QVMgc2hvdWxkIG9ubHkgY2FyZSBhYm91dCBkaWZmZXJlbmNlcyBpbiANCmJhbmR3aWR0aCBiZXR3 ZWVuIGJvdGggdXBsaW5rcy4gQnV0IHRoZXJlJ3Mgbm8gbmVlZCB0byBwcm92aWRlIGluZm8gDQpz YXlpbmcgInBvcnQgeC95IGlzIG5vdyBhc3NvY2lhdGVkIHdpdGggdXBsaW5rIGEiDQoNCjJiXSBC b3RoIHVwbGluayBwb3J0cyBvbiB0aGUgQWNjZXNzIE5vZGUgYmVsb25nIHRvIGRpZmZlcmVudCBW TEFOcy4gSW4gDQp0aGlzIGNhc2UsIGVhY2ggYWNjZXNzIHBvcnQgb24gdGhlIEFjY2VzcyBOb2Rl IHdpbGwgYmUgYXNzb2NpYXRlZCB3aXRoIGEgDQpzcGVjaWZpYyB1cGxpbmsgYnkgY29uZmlndXJh dGlvbi4gVXBvbiBmYWlsdXJlIG9mIGFuIHVwbGluaywgDQpjb25uZWN0aXZpdHkgdG8vZnJvbSBh bGwgYWNjZXNzIHBvcnRzIGFzc29jaWF0ZWQgd2l0aCB0aGF0IGxpbmsgaXMgbG9zdC4NCg0KSW4g dGhpcyBzY2VuYXJpbywgb25lIGNhbiB1c2UgYSBkaWZmZXJlbnQgQU5DUCBBZGphY2VuY3kgZm9y IGVhY2ggDQp1cGxpbmsuIFRoaXMgaXMgbGlrZSBBY2Nlc3MgTm9kZSBwYXJ0aXRpb25pbmcgYnV0 IGJvdGggcGFydGl0aW9ucyBhcmUgDQphc3NvY2lhdGVkIHdpdGggdGhlIHNhbWUgTkFTLiBBTkNQ IHRvcG9sb2d5IGRpc2NvdmVyeSBtZXNzYWdlcyBhcmUgc2VudCANCm9uIHRoZSBjb3JyZWN0IEFk amFjZW5jeS4NCg0KSXMgdGhlcmUgYSBzY2VuYXJpbyB3aXRoIG11bHRpcGxlIEFjY2VzcyBOb2Rl IHVwbGlua3MsIHdoaWNoIHJlcXVpcmVzIA0KZnVydGhlciBhZGRpdGlvbnMgdG8gdGhlIEFOQ1Ag dG9wb2xvZ3kgZGlzY292ZXJ5IG1lc3NhZ2luZz8NCg0KUmVnYXJkcywNClN2ZW4NCg0KU2FuamF5 IFdhZGh3YSB3cm90ZToNCj4gSGkgV29qDQo+IA0KPiAgICBJIGFtIG9rIHdpdGggdXBsaW5rIGF0 dHJpYnV0ZXMgaW4gQU5DUC4gVGhlIHByb3RvY29sIGRyYWZ0IGFsbHVkZXMgdG8gDQo+IGl0IHdo ZW4gZGVzY3JpYmluZyBjZXJ0YWluIFRMVnMuIEhvd2V2ZXIsIEkgYW0gbm90IGNvbnZpbmNlZCBM QUcgDQo+IG1lbWJlcnNoaXAgaW5mbyBiZWxvbmdzIGluIEFOQ1AuIEgtUU9TIGluIGNhc2Ugb2Yg TEFHIChwb3NzaWJseSBzcGFubmluZyANCj4gZGlmZmVyZW50IGxpbmUgbW9kdWxlcyBvbiBhIGNo YXNzaXMpIGNhbiBiZSBhaWRlZCBieSB0d28gZW5kcyBvZiBhIExBRyANCj4gYWdyZWVpbmcgdXBv biBhIGNvbW1vbiBtYXBwaW5nIG9mIGEgc3Vic2NyaWJlciAob3IgYWNjZXNzLWxvb3ApIHRvIGEg DQo+IGxpbmsgaW4gYSBMQUcuIEhvd2V2ZXIsIHRoZSBMQUcgY2FuIGJlIGJldHdlZW4gRFNMQU0g YW5kIEJTUiAoaW4gYSANCj4gZGlyZWN0LWNvbm5lY3QgbW9kZWwpLCBiZXR3ZWVuIERTTEFNIGFu ZCBhZ2dyZWdhdGlvbiBlbGVtZW50cywgYmV0d2VlbiANCj4gYWdncmVnYXRpb24gZWxlbWVudHMg dGhlbXNlbHZlcywgYW5kIGJldHdlZW4gYWdncmVnYXRpb24gZWxlbWVudHMgYW5kIA0KPiBCU1Iu ICBBTkNQIGRvZXNuknQgYXBwbHkgdG8gYWxsIHRoZSBjYXNlcy4gSSBjb25zaWRlciBMQUNQICh3 aXRoIA0KPiBzdWl0YWJsZSBleHRlbnNpb25zKSB0byBiZSBtb3JlIGdlbmVyYWxseSBhcHBsaWNh YmxlLg0KPiANCj4gIA0KPiANCj4gUmVnYXJkcw0KPiANCj4gLVNhbmpheQ0KPiANCj4gIA0KPiAN Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiAqRnJvbToqIFdvamNpZWNoIERlYyAod2RlYykgW21h aWx0bzp3ZGVjQGNpc2NvLmNvbV0NCj4gKlNlbnQ6KiBNb25kYXksIEZlYnJ1YXJ5IDE5LCAyMDA3 IDExOjU1IEFNDQo+ICpUbzoqIGFuY3BAaWV0Zi5vcmcNCj4gKlN1YmplY3Q6KiBbQU5DUF0gQWNj ZXNzIHRvcG9sb2d5IGRpc2NvdmVyeQ0KPiANCj4gIA0KPiANCj4gSGkgQWxsLA0KPiANCj4gRmly c3Qgb2ZmLCB0aGFua3MgdG8gdGhlIGVkaXRvciBmb3IgcG9zdGluZyB0aGUgbGF0ZXN0IHZlcnNp b24gb2YgdGhlIA0KPiBkcmFmdC4NCj4gDQo+IEkgd291bGQgbGlrZSB0byBwcm9wb3NlIHNvbWUg bW9kaWZpY2F0aW9ucyB0byBTZWN0aW9uIDMuMSBvZiB0aGUgbGF0ZXN0IA0KPiBkcmFmdC1hbmNw LWZyYW1ld29yay0wMSB0ZXh0IHRvIGJldHRlciBkZWFsIHdpdGggdGhlIG5hdHVyZSBvZiB0aGUg DQo+IHByb2JsZW0gb2YgaGllcmFyY2hpY2FsIHNjaGVkdWxpbmcgYW5kIGFjY2Vzcy1sb29wIGRp c2NvdmVyeS4NCj4gDQo+IFNlY3Rpb24gMy4xIC0gRHluYW1pYyBBY2Nlc3MgTG9vcCBBdHRyaWJ1 dGVzDQo+IFRoZSBzZWN0aW9uIGRlc2NyaWJlcyB0aGUgcm9sZSBvZiB0aGUgSGllcmFyY2hpY2Fs IFNjaGVkdWxpbmcgaW4gdGhlIA0KPiBjb250ZXh0IG9mIGFjY2VzcyBsb29wIGFuZCBhZ2dyZWdh dGlvbiB1cGxpbmsgZGlzY292ZXJ5LCBhbmQgY29ycmVjdGx5IA0KPiBzdGF0ZXMgdGhhdCBpbiBv cmRlciB0byBidWlsZCBhIDMgbGV2ZWwgSFMgaW5mb3JtYXRpb24gYWJvdXQgdGhlIA0KPiBhY2Nl c3MtbG9vcCBhbmQgYWNjZXNzLW5vZGUgdXBsaW5rIGlzIHVzZWZ1bC4gV2l0aCB0aGlzIGluIG1p bmQsIEkgd291bGQgDQo+IGxpa2UgdG8gcHJvcG9zZSB0byBjaGFuZ2UgdGhlIHRpdGxlIG9mIHRo aXMgc2VjdGlvbiBiYWNrIHRvICJBY2Nlc3MgDQo+IHRvcG9sb2d5IGRpc2NvdmVyeSIgKEFkbWl0 dGVkbHkgbm90IHRvbyBmYXIgb2ZmIGZyb20gdGhlIHRpdGxlIHRoaXMgDQo+IHNlY3Rpb24gaGFk IGluIHRoZSBwYXN0Li4uKQ0KPiANCj4gVGhlIHNlY3Rpb24gcHJvY2VlZHMgdG8gbGlzdCBhIG51 bWJlciBvZiBhdHRyaWJ1dGVzIGZvciB0aGUgYWNjZXNzIGxvb3AgDQo+IHRoYXQgYXJlIGRlc2ly YWJsZSB0byBiZSBzZW50LiBIb3dldmVyIGl0IGRvZXMgbm90IHByb3ZpZGUgYSBzaW1pbGFyIA0K PiBhdHRyaWJ1dGUgbGlzdCBmb3IgdGhlIGFjY2Vzcy1ub2RlIHVwbGluaywgYW5kIEkgd291bGQg bGlrZSB0byBwcm9wb3NlIA0KPiB0aGF0IHRoZSBmb2xsb3dpbmcgYmUgaW5jbHVkZWQgYXMgYW4g aW5pdGlhbCBzZXQ6DQo+IA0KPiAtIFRoZSB1bmlxdWUgaWRlbnRpZmljYXRpb24gKGludGVyZmFj ZS1pZCkgb2YgdGhlIHVwbGluay4NCj4gLSBUaGUgdHlwZSBvZiB0aGUgYWNjZXNzLW5vZGUgdXBs aW5rIChlZyBFdGhlcm5ldCwgQVRNLCBQT04sIIUpDQo+IC0gVGhlIGVuY2FwcyBvZiB0aGUgYWNj ZXNzLW5vZGUgdXBsaW5rIChlZyBuL2EsIDgwMi4xUSwgODAyLjFhZCwgLi4uKQ0KPiAtIFRoZSB1 cC1zcGVlZCBvZiB0aGUgYWNjZXNzLW5vZGUgdXBsaW5rDQo+IC0gVGhlIGRvd24tc3BlZWQgb2Yg dGhlIGFjY2Vzcy1ub2RlIHVwbGluaw0KPiAtIFRoZSBzdGF0ZSBvZiB0aGUgYWNjZXNzLW5vZGUg dXBsaW5rDQo+IA0KPiBGdXJ0aGVybW9yZSwgZm9yIHRoZSBwdXJwb3NlIG9mIGRlcml2aW5nIGFu IGFjY3VyYXRlIEhTIGluIHRoZSBwcmVzZW5jZSANCj4gb2YgdXBsaW5rIGJ1bmRsaW5nICAoZWcg ODAyLjNhZCksIGl0IHdvdWxkIGJlIHVzZWZ1bCBmb3IgdGhlIGFjY2Vzcy1ub2RlIA0KPiB0byBy ZXBvcnQgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHN1Y2ggYnVuZGxpbmcgYmVpbmcgYWN0aXZlLiBU aGlzIHdvdWxkIA0KPiBtaW5pbWFsbHkgcmVxdWlyZSB0aGF0IGZvciBlYWNoIHVwbGluayB0aGF0 IGlzIGNvbmZpZ3VyZWQgYW5kIGFjdGl2ZSBpbiANCj4gYSBsaW5rIGJ1bmRsZSB0aGUgcHJvdG9j b2wgY29udmV5cyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgbGluaydzIGJ1bmRsZSANCj4gbWVtYmVy c2hpcCwgZWcgLSBNZW1iZXIgb2YgbGluay1idW5kbGUtaWQuDQo+IA0KPiBTaW5jZSBzb21lIHR5 cGVzIG9mIGFjY2Vzcy1ub2RlcyBjYW4gaGF2ZSBtdWx0aXBsZSB1cGxpbmtzLCBpbmNsdWRpbmcg YSANCj4gbWl4IG9mIEFUTSBhbmQgRXRoZXJuZXQsIEkgdGhpbmsgaXQgd291bGQgbWFrZSBzZW5z ZSB0byBhbHNvIGJlIGFibGUgdG8gDQo+IGNvbnZleSBpbmZvIGZyb20gdGhlIGFjY2Vzcy1ub2Rl IGFib3V0IHRoZSBhY3RpdmUgbWFwcGluZyBvZiBhY2Nlc3MtbG9vcCANCj4gdG8gYWNjZXNzLW5v ZGUgdXBsaW5rLCBlZyBEU0wgcG9ydCAxLzEgbWFwcyB0byB1cGxpbmsgMSwgRFNMIHBvcnQgMi8x IA0KPiBtYXBzIHRvIHVwbGluayAyLiBGb3IgdGhpcyBpdCB3b3VsZCBwcm9iYWJseSBtYWtlIHNl bnNlIHRvIGludHJvZHVjZSBhbiANCj4gYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBlbGVtZW50IGlu IGJvdGggdGhlIGFjY2Vzcy1sb29wIGFuZCB1cGxpbmsgDQo+IGNoYXJhY3RlcmlzdGljcywgd2hp Y2ggY2FuIGJlIHVzZWQgdG8gdGllIHRoZSB0d28gdG9nZXRoZXIuIEEgc2ltcGxlIA0KPiBwcm9w b3NhbCBvbmUgY291bGQgbWFrZSBpcyB0byBhZGQgdGhlIHVwbGluaydzIGlkIGFzIGEgY2hhcmFj dGVyaXN0aWMgb2YgDQo+IHRoZSBhY2Nlc3MtbG9vcCwgaS5lLiAtICJBY2Nlc3Mtbm9kZSB1cGxp bmsgaWQiIGFkZGVkIHRvIHRoZSBhY2Nlc3MtbG9vcCANCj4gYXR0cmlidXRlIGxpc3RzLg0KPiAN Cj4gVGhpcyBob3dldmVyIGhhcyB0aGUgZG93bnNpZGUgdGhhdCBzaG91bGQgdGhlIHVwbGluayBm b3IgYSBwYXJ0aWN1bGFyIA0KPiBhY2Nlc3MtbG9vcCBjaGFuZ2UsIGVnIGR1ZSB0byB0aGUgYWN0 aXZhdGlvbiBvZiBhIHN0YW5kYnkgdXAtbGluayANCj4gbWVjaGFuaXNtIGNvbW1vbmx5IGZvdW5k IG9uIGFjY2Vzcy1ub2RlcywgYWxsIGFjY2Vzcy1sb29wcyB3b3VsZCBuZWVkIHRvIA0KPiBiZSBy ZS1zaWduYWxsZWQuIFRodXMsIGl0IHdvdWxkIGFwcGVhciB0byBiZSBiZXR0ZXIgdG8gaW50cm9k dWNlIGEgDQo+IHBhcmFtZXRlciB0aGF0IHdvdWxkIGF2b2lkIHN1Y2ggcmUtc2lnbmFsbGluZywg YW5kIEkgd291bGQgbGlrZSB0byANCj4gcHJvcG9zZSB0aGUgZm9sbG93aW5nOg0KPiANCj4gMSkg aW5jbHVkaW5nIGluIHRoZSBhY2Nlc3MtbG9vcCB0aGUgdXBsaW5rIFZMQU4gb3IgVlAvVkMgdG8g d2hpY2ggdGhhdCANCj4gYWNjZXNzLWxvb3AgaXMgY3VycmVudGx5IG1hcHBlZCB0bywNCj4gMikg aW5jbHVkZSBpbiB0aGUgdXBsaW5rJ3MgZGVzY3JpcHRpb24gYSBsaXN0IG9mIGN1cnJlbnRseSBh Y3RpdmUgYW5kIA0KPiBmb3J3YXJkaW5nIFZMQU5zIG9yIFZQL1ZDcy4NCj4gDQo+IElmIGFuIGFj Y2Vzcy1ub2RlIHVwbGluayBzaG91bGQgZmFpbCwgZWcgYSBzdGFuZGJ5IGxpbmsgYmVjb21lIA0K PiBhY3RpdmF0ZWQsIGFsbCB0aGF0IHdvdWxkIGJlIHJlcXVpcmVkIHRvIGJlIGNvbW11bmljYXRl ZCB3b3VsZCBiZSBhbiANCj4gdXBkYXRlIG9mIHRoZSB1cGxpbmsgc3RhdHVzLg0KPiANCj4gTG9v a2luZyBmb3J3YXJkIHRvIHRoZSBkaXNjdXNzaW9uIGFuZC9vciBpbmNsdXNpb24gb2YgdGhlc2Ug YWRkaXRpb25zIGluIA0KPiB0aGUgQU5DUCBmcmFtZXdvcmsgZHJhZnQuDQo+IA0KPiBSZWdhcmRz LA0KPiBXb2ouDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBBTkNQIG1h aWxpbmcgbGlzdA0KPiBBTkNQQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2FuY3ANCg0K --===============1408355435== 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://www1.ietf.org/mailman/listinfo/ancp --===============1408355435==--