ANCP Versioning

+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+
Derek=20 Harkness
Juniper Networks
Nymphenburger Strasse 13-15
80335=20 Munich
Germany
Tel: +49 89 5529 4916
Mobile: +49 172 843 = 6621
Email:=20 DHarkness@juniper.net

+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+=20

From: = Robert.Peschi@alcatel-lucent.be=20 [mailto:Robert.Peschi@alcatel-lucent.be]
Sent: 22 January = 2007=20 14:23
To: ancp@ietf.org
Subject: [ANCP] Reporting = "Training"=20 state

Hi All, =

In the current ANCP IETF draft, =
http://www.ietf.org/internet-drafts/draft-wadhwa-gsmp-l2control-= configuration-02.txt=20

One reads that DSL "Training" = state,=20

1) should be reported = upon OAM=20 requests,
Cf section = 5.4.4:=20
0x500 : = Specified access=20 line does not exist.
=20 0x501 : Loopback test timed out.
0x502 : Reserved
0x503 : DSL line status showtime. =
0x504 : DSL line status = idle.=20
= 0x505 : DSL line=20 status silent.
=20 0x506 : DSL line status training.
0x507 : DSL line = integrity error.=20
= 0x508 : DSLAM=20 resource not available.
=20 0x509 : Invalid test parameter.

2) but not in "Toplogy Discovery" messages,=20
Cf section 5.4.2:=20
Type (DSL = line state =3D=20 0x8F)
= (...)=20
{ SHOWTIME =3D 0x01, = IDLE =3D 0x02,=20 SILENT =3D 0x03 }

Question: is=20 this intentional or is "training" state just forgotten in "Topology = Discovery"=20 messages ?

Thanks for=20 clarifications,
Kind = regards,=20
Robert Peschi ------_=_NextPart_001_01C73E32.6AA152A4-- --===============1608705168== 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 --===============1608705168==-- From ancp-bounces@ietf.org Mon Jan 22 09:43:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H90Od-0004x3-5A; Mon, 22 Jan 2007 09:43:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H90Oc-0004wu-5K for ancp@ietf.org; Mon, 22 Jan 2007 09:43:42 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H90OW-0008AA-Bl for ancp@ietf.org; Mon, 22 Jan 2007 09:43:41 -0500 Received: from bemail01.netfr.alcatel.fr ([155.132.251.32]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l0MEhev9009876; Mon, 22 Jan 2007 15:43:41 +0100 In-Reply-To: To: "Derek Harkness" Subject: RE: [ANCP] Reporting "Training" state MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Robert.Peschi@alcatel-lucent.be Date: Mon, 22 Jan 2007 15:43:30 +0100 X-MIMETrack: Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 01/22/2007 15:43:35, Serialize complete at 01/22/2007 15:43:35 X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.3 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a 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="===============0636404599==" Errors-To: ancp-bounces@ietf.org This is a multipart message in MIME format. --===============0636404599== Content-Type: multipart/alternative; boundary="=_alternative 0050E445C125726B_=" This is a multipart message in MIME format. --=_alternative 0050E445C125726B_= Content-Type: text/plain; charset="US-ASCII" Hello Derek, I also think that this is the most sensible way to go. Thanks, Robert "Derek Harkness" 01/22/2007 03:34 PM To: Robert PESCHI/BE/ALCATEL@ALCATEL, cc: Subject: RE: [ANCP] Reporting "Training" state My understanding would be that the topology discovery message is sent when the line reaches a steady state ( one of the 3 listed ) and when it is training the line state is in some form transition between 2 of these states D +=============================+ Derek Harkness Juniper Networks Nymphenburger Strasse 13-15 80335 Munich Germany Tel: +49 89 5529 4916 Mobile: +49 172 843 6621 Email: DHarkness@juniper.net +=============================+ From: Robert.Peschi@alcatel-lucent.be [mailto:Robert.Peschi@alcatel-lucent.be] Sent: 22 January 2007 14:23 To: ancp@ietf.org Subject: [ANCP] Reporting "Training" state Hi All, In the current ANCP IETF draft, http://www.ietf.org/internet-drafts/draft-wadhwa-gsmp-l2control-configuration-02.txt One reads that DSL "Training" state, 1) should be reported upon OAM requests, Cf section 5.4.4: 0x500 : Specified access line does not exist. 0x501 : Loopback test timed out. 0x502 : Reserved 0x503 : DSL line status showtime. 0x504 : DSL line status idle. 0x505 : DSL line status silent. 0x506 : DSL line status training. 0x507 : DSL line integrity error. 0x508 : DSLAM resource not available. 0x509 : Invalid test parameter. 2) but not in "Toplogy Discovery" messages, Cf section 5.4.2: Type (DSL line state = 0x8F) (...) { SHOWTIME = 0x01, IDLE = 0x02, SILENT = 0x03 } Question: is this intentional or is "training" state just forgotten in "Topology Discovery" messages ? Thanks for clarifications, Kind regards, Robert Peschi_______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --=_alternative 0050E445C125726B_= Content-Type: text/html; charset="US-ASCII"
Hello Derek,

I also think that this is the most sensible way to go.

Thanks,
Robert

"Derek Harkness" <dharkness@juniper.net>

01/22/2007 03:34 PM

To: Robert PESCHI/BE/ALCATEL@ALCATEL, <ancp@ietf.org>
cc:
Subject: RE: [ANCP] Reporting "Training" state

My understanding would be that the topology discovery message is sent when the line reaches a steady state ( one of the 3 listed ) and when it is training the line state is in some form transition between 2 of these states

D

+=============================+
Derek Harkness
Juniper Networks
Nymphenburger Strasse 13-15
80335 Munich
Germany
Tel: +49 89 5529 4916
Mobile: +49 172 843 6621
Email: DHarkness@juniper.net
+=============================+

From: Robert.Peschi@alcatel-lucent.be [mailto:Robert.Peschi@alcatel-lucent.be]
Sent: 22 January 2007 14:23
To: ancp@ietf.org
Subject: [ANCP] Reporting "Training" state

Hi All,

In the current ANCP IETF draft,
http://www.ietf.org/internet-drafts/draft-wadhwa-gsmp-l2control-configuration-02.txt

One reads that DSL "Training" state,

1) should be reported upon OAM requests,
Cf section 5.4.4:
0x500 : Specified access line does not exist.
0x501 : Loopback test timed out.
0x502 : Reserved
0x503 : DSL line status showtime.
0x504 : DSL line status idle.
0x505 : DSL line status silent.
0x506 : DSL line status training.
0x507 : DSL line integrity error.
0x508 : DSLAM resource not available.
0x509 : Invalid test parameter.

2) but not in "Toplogy Discovery" messages,
Cf section 5.4.2:
Type (DSL line state = 0x8F)
(...)
{ SHOWTIME = 0x01, IDLE = 0x02, SILENT = 0x03 }

Question: is this intentional or is "training" state just forgotten in "Topology Discovery" messages ?

Thanks for clarifications,
Kind regards,
Robert Peschi_______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp
--=_alternative 0050E445C125726B_=-- --===============0636404599== 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 --===============0636404599==-- From ancp-bounces@ietf.org Tue Jan 23 04:18:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Hmy-0000z8-9P; Tue, 23 Jan 2007 04:18:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H95je-00068q-Ri for ancp@ietf.org; Mon, 22 Jan 2007 15:25:46 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H95jd-000375-Ev for ancp@ietf.org; Mon, 22 Jan 2007 15:25:46 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id D7C7FB91F4B for ; Mon, 22 Jan 2007 12:25:39 -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 18654-04 for ; Mon, 22 Jan 2007 12:25:39 -0800 (PST) Received: from [127.0.0.1] (login-1-300.redback.com [155.53.12.153]) by prattle.redback.com (Postfix) with ESMTP id BE76FB91F45 for ; Mon, 22 Jan 2007 12:25:39 -0800 (PST) Message-ID: <45B51DC3.10406@redback.com> Date: Mon, 22 Jan 2007 12:25:39 -0800 From: Jakob Heitz User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: ancp@ietf.org Subject: Re: [ANCP] Reporting "Training" state References: In-Reply-To: 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: d185fa790257f526fedfd5d01ed9c976 X-Mailman-Approved-At: Tue, 23 Jan 2007 04:17:59 -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 The "DSL line state" TLV is mandatory in PORT DOWN messages and optional in PORT UP messages. When the DSLAM establishes an ANCP connection, it will send a topology discovery message for EVERY port: either PORT UP or PORT DOWN. What should this TLV contain if a DSL line is in the "training" state at this time? Kind Regards, Jakob Heitz. Derek Harkness wrote: > My understanding would be that the topology discovery message is sent > when the line reaches a steady state ( one of the 3 listed ) and when > it is training the line state is in some form transition between 2 of > these states > > D > > +=============================+ > Derek Harkness > Juniper Networks > Nymphenburger Strasse 13-15 > 80335 Munich > Germany > Tel: +49 89 5529 4916 > Mobile: +49 172 843 6621 > Email: DHarkness@juniper.net > +=============================+ > > > ------------------------------------------------------------------------ > *From:* Robert.Peschi@alcatel-lucent.be > [mailto:Robert.Peschi@alcatel-lucent.be] > *Sent:* 22 January 2007 14:23 > *To:* ancp@ietf.org > *Subject:* [ANCP] Reporting "Training" state > > > Hi All, > > In the current ANCP IETF draft, > http://www.ietf.org/internet-drafts/draft-wadhwa-gsmp-l2control-configuration-02.txt > > > One reads that DSL "Training" state, > > 1) should be reported upon OAM requests, > Cf section 5.4.4: > / 0x500 : Specified access line does not exist. / > / 0x501 : Loopback test timed out. / > / 0x502 : Reserved / > / 0x503 : DSL line status showtime. / > / 0x504 : DSL line status idle. / > / 0x505 : DSL line status silent. / > / 0x506 : DSL line status *training*//. / > / 0x507 : DSL line integrity error. / > / 0x508 : DSLAM resource not available. / > / 0x509 : Invalid test parameter. / > > > 2) but not in "Toplogy Discovery" messages, > Cf section 5.4.2:/ / > Type (DSL line state = 0x8F) > / (...)/ > / { SHOWTIME = 0x01, IDLE = 0x02, SILENT = 0x03 } / > > > Question: is this intentional or is "training" state just forgotten in > "Topology Discovery" messages ? > > Thanks for clarifications, > Kind regards, > Robert Peschi > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Tue Jan 23 05:46:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9JAL-0001SO-3c; Tue, 23 Jan 2007 05:46:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9JAK-0001S7-0X for ancp@ietf.org; Tue, 23 Jan 2007 05:46:12 -0500 Received: from smail2.alcatel.fr ([64.208.49.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9JAI-00072a-6o for ancp@ietf.org; Tue, 23 Jan 2007 05:46:11 -0500 Received: from bemail01.netfr.alcatel.fr (bemail01.netfr.alcatel.fr [155.132.251.32]) by smail2.alcatel.fr (ALCANET/NETFR) with ESMTP id l0NAjGh9024341; Tue, 23 Jan 2007 11:45:56 +0100 In-Reply-To: <45B51DC3.10406@redback.com> To: Jakob Heitz Subject: Re: [ANCP] Reporting "Training" state MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Robert.Peschi@alcatel-lucent.be Date: Tue, 23 Jan 2007 11:45:51 +0100 X-MIMETrack: Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 01/23/2007 11:45:55, Serialize complete at 01/23/2007 11:45:55 X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.2 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 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="===============1252999860==" Errors-To: ancp-bounces@ietf.org This is a multipart message in MIME format. --===============1252999860== Content-Type: multipart/alternative; boundary="=_alternative 003B22C6C125726C_=" This is a multipart message in MIME format. --=_alternative 003B22C6C125726C_= Content-Type: text/plain; charset="US-ASCII" Hello Jakob and All, My take: 1) Training means that the DSLAM is establishing DSL connectivity so DSLAM is certainly "willing" to establish connectivity with CPE so DSLAM is certainly NOT idle which would mean "unwilling" 2) Training also means that the DSL connectivity is not yet OK so it is certainly NOT showtime which would mean "traffic able to flow" So, for what topology discovery is used for, the most sensible looks to be: "Send port DOWN with line state = silent" Kind regards, Robert Jakob Heitz 01/22/2007 09:25 PM To: ancp@ietf.org cc: Subject: Re: [ANCP] Reporting "Training" state The "DSL line state" TLV is mandatory in PORT DOWN messages and optional in PORT UP messages. When the DSLAM establishes an ANCP connection, it will send a topology discovery message for EVERY port: either PORT UP or PORT DOWN. What should this TLV contain if a DSL line is in the "training" state at this time? Kind Regards, Jakob Heitz. Derek Harkness wrote: > My understanding would be that the topology discovery message is sent > when the line reaches a steady state ( one of the 3 listed ) and when > it is training the line state is in some form transition between 2 of > these states > > D > > +=============================+ > Derek Harkness > Juniper Networks > Nymphenburger Strasse 13-15 > 80335 Munich > Germany > Tel: +49 89 5529 4916 > Mobile: +49 172 843 6621 > Email: DHarkness@juniper.net > +=============================+ > > > ------------------------------------------------------------------------ > *From:* Robert.Peschi@alcatel-lucent.be > [mailto:Robert.Peschi@alcatel-lucent.be] > *Sent:* 22 January 2007 14:23 > *To:* ancp@ietf.org > *Subject:* [ANCP] Reporting "Training" state > > > Hi All, > > In the current ANCP IETF draft, > http://www.ietf.org/internet-drafts/draft-wadhwa-gsmp-l2control-configuration-02.txt > > > One reads that DSL "Training" state, > > 1) should be reported upon OAM requests, > Cf section 5.4.4: > / 0x500 : Specified access line does not exist. / > / 0x501 : Loopback test timed out. / > / 0x502 : Reserved / > / 0x503 : DSL line status showtime. / > / 0x504 : DSL line status idle. / > / 0x505 : DSL line status silent. / > / 0x506 : DSL line status *training*//. / > / 0x507 : DSL line integrity error. / > / 0x508 : DSLAM resource not available. / > / 0x509 : Invalid test parameter. / > > > 2) but not in "Toplogy Discovery" messages, > Cf section 5.4.2:/ / > Type (DSL line state = 0x8F) > / (...)/ > / { SHOWTIME = 0x01, IDLE = 0x02, SILENT = 0x03 } / > > > Question: is this intentional or is "training" state just forgotten in > "Topology Discovery" messages ? > > Thanks for clarifications, > Kind regards, > Robert Peschi > ------------------------------------------------------------------------ > > _______________________________________________ > 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 --=_alternative 003B22C6C125726C_= Content-Type: text/html; charset="US-ASCII"
Hello Jakob and All,

My take:

1) Training means that the DSLAM is establishing DSL connectivity
so DSLAM is certainly "willing" to establish connectivity with CPE
so DSLAM is certainly NOT idle which would mean "unwilling"

2) Training also means that the DSL connectivity is not yet OK
so it is certainly NOT showtime which would mean "traffic able to flow"

So, for what topology discovery is used for, the most sensible looks to be:

"Send port DOWN with line state = silent"

Kind regards,
Robert

Jakob Heitz <jheitz+121406@redback.com>

01/22/2007 09:25 PM

To: ancp@ietf.org
cc:
Subject: Re: [ANCP] Reporting "Training" state

The "DSL line state" TLV is mandatory in PORT DOWN messages and optional in PORT UP messages. When the DSLAM establishes an ANCP connection, it will send a topology discovery message for EVERY port: either PORT UP or PORT DOWN. What should this TLV contain if a DSL line is in the "training" state at this time? Kind Regards, Jakob Heitz. Derek Harkness wrote: > My understanding would be that the topology discovery message is sent > when the line reaches a steady state ( one of the 3 listed ) and when > it is training the line state is in some form transition between 2 of > these states > > D > > +=============================+ > Derek Harkness > Juniper Networks > Nymphenburger Strasse 13-15 > 80335 Munich > Germany > Tel: +49 89 5529 4916 > Mobile: +49 172 843 6621 > Email: DHarkness@juniper.net <mailto:DHarkness@juniper.net> > +=============================+ > > > ------------------------------------------------------------------------ > *From:* Robert.Peschi@alcatel-lucent.be > [mailto:Robert.Peschi@alcatel-lucent.be] > *Sent:* 22 January 2007 14:23 > *To:* ancp@ietf.org > *Subject:* [ANCP] Reporting "Training" state > > > Hi All, > > In the current ANCP IETF draft, > http://www.ietf.org/internet-drafts/draft-wadhwa-gsmp-l2control-configuration-02.txt > > > One reads that DSL "Training" state, > > 1) should be reported upon OAM requests, > Cf section 5.4.4: > / 0x500 : Specified access line does not exist. / > / 0x501 : Loopback test timed out. / > / 0x502 : Reserved / > / 0x503 : DSL line status showtime. / > / 0x504 : DSL line status idle. / > / 0x505 : DSL line status silent. / > / 0x506 : DSL line status *training*//. / > / 0x507 : DSL line integrity error. / > / 0x508 : DSLAM resource not available. / > / 0x509 : Invalid test parameter. / > > > 2) but not in "Toplogy Discovery" messages, > Cf section 5.4.2:/ / > Type (DSL line state = 0x8F) > / (...)/ > / { SHOWTIME = 0x01, IDLE = 0x02, SILENT = 0x03 } / > > > Question: is this intentional or is "training" state just forgotten in > "Topology Discovery" messages ? > > Thanks for clarifications, > Kind regards, > Robert Peschi > ------------------------------------------------------------------------ > > _______________________________________________ > 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
--=_alternative 003B22C6C125726C_=-- --===============1252999860== 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 --===============1252999860==-- From ancp-bounces@ietf.org Tue Jan 23 12:45:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9PiP-00076J-EN; Tue, 23 Jan 2007 12:45:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9PiO-00075R-E4 for ancp@ietf.org; Tue, 23 Jan 2007 12:45:48 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9PiM-0000do-Da for ancp@ietf.org; Tue, 23 Jan 2007 12:45:48 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 23 Jan 2007 18:45:46 +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 l0NHjj9f016421 for ; Tue, 23 Jan 2007 18:45:45 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0NHjfC8002377 for ; Tue, 23 Jan 2007 18:45:45 +0100 (MET) Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jan 2007 18:45:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 23 Jan 2007 18:45:28 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANCP Versioning Thread-Index: Acc+3SswI9tPSfwzSO+w3Vxx2R5dRAAOHMZw From: "Wojciech Dec \(wdec\)" To: X-OriginalArrivalTime: 23 Jan 2007 17:45:40.0978 (UTC) FILETIME=[4C917520:01C73F16] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=15217; t=1169574345; x=1170438345; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20\(wdec\)=22=20 |Subject:=20ANCP=20Versioning |Sender:=20; bh=p3zxifBZEsLUzDMWhPeXyx4YoyjwATfQUYYlNnDREHw=; b=fZS0W/Rrl/R4Y8FMUwI40bEK7dBk2QQbrQfrAl/DZrwcuI2J09uZrzSF4ktw1q2Pkz5Be3+t nLiJk7TelJ46vMo7oRPnNXqPri2g5lNdzqD8LlN9otqjzwPhFMShEHuw; 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: 4bb0e9e1ca9d18125bc841b2d8d77e24 Subject: [ANCP] ANCP Versioning 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="===============0543489904==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0543489904== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73F16.4C7D5005" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73F16.4C7D5005 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > 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 >=20 > A brief summary of the problems. > ------------------------------------------------ > * 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 > * Going forward, it is likely that the protocol will introduce > modifications to the base protocol, which may render backward > compatibility difficult. > * 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. > * 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 >=20 > ANCP Versioning strategy. > ---------------------------------------- >=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. >=20 > 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* > ii) a conflicting TLV or sub-TLVs > iii) incompatibilities arising from implementations of pre-RFC drafts. > 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. >=20 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. > 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 > 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 > TLV 0x90 conclusion and TLV work for the WG > ------------------------------------------------------------- >=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 > 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. >=20 > Kind Regards, > Woj. >=20 ------_=_NextPart_001_01C73F16.4C7D5005 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ANCP Versioning

Dear All,

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.
------------------------------------------------

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.
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.
Going forward, it is likely that the = protocol will introduce modifications to the base protocol, which may = render backward compatibility difficult.
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.
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.

ANCP Versioning strategy.
----------------------------------------

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.

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*
ii) a conflicting TLV or = sub-TLVs
iii) incompatibilities arising from = implementations of pre-RFC drafts.
iv) new negotiable protocol = capabilities (eg Bulk message capability)**

* 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.

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.

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.

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

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:

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.

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,
Woj.

------_=_NextPart_001_01C73F16.4C7D5005-- --===============0543489904== 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 --===============0543489904==-- From ancp-bounces@ietf.org Wed Jan 24 00:30:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9aiK-0007Pd-3V; Wed, 24 Jan 2007 00:30:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9aiJ-0007PX-NZ for ancp@ietf.org; Wed, 24 Jan 2007 00:30:27 -0500 Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9aiH-0000gh-TO for ancp@ietf.org; Wed, 24 Jan 2007 00:30:27 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id C93EA205DF for ; Wed, 24 Jan 2007 10:52:53 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id AF99B205DB for ; Wed, 24 Jan 2007 10:52:53 +0530 (IST) Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 11:00:13 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 24 Jan 2007 11:00:12 +0530 Message-ID: <0140B5C49461E34686783F667D9E4A53C40623@blr-k1-msg.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on "draft-ietf-ancp-framework-00.txt" Thread-Index: Acc/eLg1ZbU2akE6SeC7wI4AyjOjtw== From: To: X-OriginalArrivalTime: 24 Jan 2007 05:30:13.0340 (UTC) FILETIME=[B8DC01C0:01C73F78] X-Spam-Score: 0.2 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Subject: [ANCP] comments on "draft-ietf-ancp-framework-00.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: , Content-Type: multipart/mixed; boundary="===============1550069384==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1550069384== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73F78.B8B186F8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73F78.B8B186F8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Can somebody throw more light on following?: =20 1. In case Access Node is connected to multiple NAS devices (which is basically a multi-edge architecture), current ANCP framework states that Access Node be partitioned into multiple logical partition based on DSL ports. =20 Consider a case, where a subscriber connected to a single DSL Port is subscribed to Internet, VoIP and Video services. In a multi-edge architecture (where Access Node in this case is connected to 3 different NAS devices, one for VoIP, one for Video and one for Internet), are we expecting that the Access Node in this case will establish=20 ANCP session with all 3 NAS devices, for one DSL port? =20 2. I beleve we can reuse In-band management IP address of Access Node (if its supported) for ANCP session between Access Node and NAS (over TCP/UDP)? This should be ok, since the draft proposes to have separate VLAN for this session between Access Node and NAS, we should be able to segregate the traffic based on the VLAN. Any comments? =20 3. As more and more pizza-box type Access Nodes are getting deployed at remote locations (for better reach to the subscribers), is maintaining one session for each access node is scalable in NAS? (specifically for low-port density Access Nodes). Probably when Authors present a ANCP use case on subtending access node to NAS will=20 throw more light on understanding complexities in this case. =20 Regards, Sathiya =20 =20 ------_=_NextPart_001_01C73F78.B8B186F8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

=20 Can somebody throw more light on following?:

1. = In case Access=20 Node is connected to multiple NAS devices (which is basically a = multi-edge=20 architecture), current

=20 ANCP framework states that Access Node be partitioned into multiple = logical=20 partition based on DSL ports.

=20 Consider a case, where a subscriber connected to a single DSL Port is = subscribed=20 to Internet, VoIP and Video

=20 services. In a multi-edge architecture (where Access Node in this case = is=20 connected to 3 different NAS devices,

=20 one for VoIP, one for Video and one for Internet), are we expecting that = the=20 Access Node in this case will establish

=20 ANCP session with all 3 NAS devices, for one DSL = port?

2. I = beleve we can=20 reuse In-band management IP address of Access Node (if its = supported) for=20 ANCP session

=20 between Access Node and NAS (over TCP/UDP)? This should be = ok, since the=20 draft proposes to have separate

=20 VLAN for this session between Access Node and NAS, we should be=20 able to segregate the traffic based on the

=20 VLAN. Any comments?

3. = As more and=20 more pizza-box type Access Nodes are getting deployed at remote = locations (for=20 better reach to

=20 the subscribers), is maintaining one session for each access node is = scalable in=20 NAS? (specifically for low-port

=20 density Access Nodes). Probably when Authors present a ANCP use case on=20 subtending access node to NAS will

=20 throw more light on understanding complexities in this = case.

Regards,
Sathiya

=20

------_=_NextPart_001_01C73F78.B8B186F8-- --===============1550069384== 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 --===============1550069384==-- From ancp-bounces@ietf.org Wed Jan 24 12:14:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9lhI-0003tK-QF; Wed, 24 Jan 2007 12:14:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9lhG-0003tB-NP for ancp@ietf.org; Wed, 24 Jan 2007 12:14:06 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9lhE-0006Tv-6p for ancp@ietf.org; Wed, 24 Jan 2007 12:14:06 -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 l0OHE9Px028226; Wed, 24 Jan 2007 18:14:09 +0100 Received: from [172.17.252.32] ([172.17.252.32]) by bemail01.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163) with ESMTP id 2007012418135587:11094 ; Wed, 24 Jan 2007 18:13:55 +0100 Message-ID: <45B793D3.1000103@alcatel-lucent.be> Date: Wed, 24 Jan 2007 18:13:55 +0100 From: Sven.Ooghe@alcatel-lucent.be Organization: Alcatel-Lucent User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: sathiya.narayanan@wipro.com, ancp@ietf.org Subject: Re: [ANCP] comments on "draft-ietf-ancp-framework-00.txt" References: <0140B5C49461E34686783F667D9E4A53C40623@blr-k1-msg.wipro.com> In-Reply-To: <0140B5C49461E34686783F667D9E4A53C40623@blr-k1-msg.wipro.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL01/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 01/24/2007 18:13:56, Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 01/24/2007 18:14:02, Serialize complete at 01/24/2007 18:14:02 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: c3a18ef96977fc9bcc21a621cbf1174b 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 Sathiya, see my answers inline. Regards, Sven sathiya.narayanan@wipro.com wrote: > Hi, > > Can somebody throw more light on following?: > > 1. In case Access Node is connected to multiple NAS devices (which is > basically a multi-edge architecture), current > ANCP framework states that Access Node be partitioned into multiple > logical partition based on DSL ports. > > Consider a case, where a subscriber connected to a single DSL Port > is subscribed to Internet, VoIP and Video > services. In a multi-edge architecture (where Access Node in this > case is connected to 3 different NAS devices, > one for VoIP, one for Video and one for Internet), are we expecting > that the Access Node in this case will establish > ANCP session with all 3 NAS devices, for one DSL port? > Currently the framework assumes that one access port is associated with one access node partition, and that this partition is associated with one BNG, covering all services. The framework currently does not address partitioning per service. Note that aside from this, the framework does allow for redundant BNGs. Also note that there has been some discussion (in the DSL Forum) on allowing functional partitioning by means of some sort of "ANCP proxy" mechanism between the Access Node and the BNG. > 2. I beleve we can reuse In-band management IP address of Access Node > (if its supported) for ANCP session > between Access Node and NAS (over TCP/UDP)? This should be ok, since > the draft proposes to have separate > VLAN for this session between Access Node and NAS, we should be > able to segregate the traffic based on the > VLAN. Any comments? > It may indeed be possible to reuse this IP address, or you could separate IP address. I don't think that the framework should specify which approach to take. It is also possible that different VLANs are used for network management and for ANCP interactions, and that different IP addresses are required for each of them (e.g. because these functions are handled by different entities). BTW we plan to provide some more details on this in an updated version (stay tuned). > 3. As more and more pizza-box type Access Nodes are getting deployed at > remote locations (for better reach to > the subscribers), is maintaining one session for each access node is > scalable in NAS? (specifically for low-port > density Access Nodes). Probably when Authors present a ANCP use case > on subtending access node to NAS will > throw more light on understanding complexities in this case. > Good point. The number of access nodes can get pretty high. In that sense, we plan to include in an update the exact scalability requirements of the protocol. Also note that the notion of "ANCP proxy" was brought up in this context. Regards, Sven > Regards, > Sathiya > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Jan 25 08:52:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA51Y-0007Sw-87; Thu, 25 Jan 2007 08:52:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA51X-0007Sh-4N for ancp@ietf.org; Thu, 25 Jan 2007 08:52:19 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA51V-0007SH-3q for ancp@ietf.org; Thu, 25 Jan 2007 08:52:19 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP for ancp@ietf.org; Thu, 25 Jan 2007 14:52:15 +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, 25 Jan 2007 14:52:15 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: Re: [ANCP] Reporting "Training" state Date: Thu, 25 Jan 2007 14:52:15 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2C45881@S4DE8PSAAFQ.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [ANCP] Reporting "Training" state Thread-Index: Acc+29NTq6fXI8g4S6mh8i+qFR0HJQAyS90QACtCy/AADW08AA== From: "Busser, M" To: X-OriginalArrivalTime: 25 Jan 2007 13:52:15.0797 (UTC) FILETIME=[05A7EE50:01C74088] X-Spam-Score: 0.2 (/) X-Scan-Signature: 34a12386bc31e4adf7d931eae58f5833 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="===============0795535035==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0795535035== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C74088.0563C324" This is a multi-part message in MIME format. ------_=_NextPart_001_01C74088.0563C324 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all =20 I agree with Robert. =20 OAM-Ping is intended to request the actual state of a line.=20 Therefor, if a line is in training mode, we should report "training = mode". =20 The PortUp/Down Event messages are intend to give the BRAS the actual = state of each port. The "training state" can only be entered from the silent state, but it = is not a steady state. As long as a line is not in showtime, no traffic can flow. For that = reason, sending Port Down=20 with line state =3D "silent" seems to be appropriate.=20 =20 Kind regards Michael =20 =20 -----Urspr=FCngliche Nachricht----- Von: Robert.Peschi@alcatel-lucent.be = [mailto:Robert.Peschi@alcatel-lucent.be]=20 Gesendet: Dienstag, 23. Januar 2007 11:46 An: Jakob Heitz Cc: ancp@ietf.org Betreff: Re: [ANCP] Reporting "Training" state =09 Hello Jakob and All,=20 =09 My take:=20 =09 1) Training means that the DSLAM is establishing DSL connectivity=20 so DSLAM is certainly "willing" to establish connectivity with = CPE=20 so DSLAM is certainly NOT idle which would mean "unwilling"=20 =09 2) Training also means that the DSL connectivity is not yet OK=20 so it is certainly NOT showtime which would mean "traffic able to = flow"=20 =09 So, for what topology discovery is used for, the most sensible looks = to be:=20 =09 "Send port DOWN with line state =3D silent"=20 =09 Kind regards,=20 Robert=20 =09 =09 =09 =20 Jakob Heitz =20 01/22/2007 09:25 PM=20 =20 To: ancp@ietf.org=20 cc: =20 Subject: Re: [ANCP] Reporting "Training" state =09 =09 =09 The "DSL line state" TLV is mandatory in PORT DOWN messages and optional in PORT UP messages. When the DSLAM establishes an ANCP connection, it will send a topology discovery message for EVERY port: either PORT UP or PORT DOWN. =09 What should this TLV contain if a DSL line is in the "training" state at this time? =09 Kind Regards, Jakob Heitz. =09 Derek Harkness wrote: > My understanding would be that the topology discovery message is sent = > when the line reaches a steady state ( one of the 3 listed ) and when = > it is training the line state is in some form transition between 2 of = > these states > =20 > D > =20 > = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D+ > Derek Harkness > Juniper Networks > Nymphenburger Strasse 13-15 > 80335 Munich > Germany > Tel: +49 89 5529 4916 > Mobile: +49 172 843 6621 > Email: DHarkness@juniper.net > = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D+ > =20 > > = ------------------------------------------------------------------------ > *From:* Robert.Peschi@alcatel-lucent.be=20 > [mailto:Robert.Peschi@alcatel-lucent.be] > *Sent:* 22 January 2007 14:23 > *To:* ancp@ietf.org > *Subject:* [ANCP] Reporting "Training" state > > > Hi All, > > In the current ANCP IETF draft, > = http://www.ietf.org/internet-drafts/draft-wadhwa-gsmp-l2control-configura= tion-02.txt=20 > > > One reads that DSL "Training" state, > > 1) should be reported upon OAM requests, > Cf section 5.4.4: > / 0x500 : Specified access line does not exist. / > / 0x501 : Loopback test timed out. / > / 0x502 : Reserved / > / 0x503 : DSL line status showtime. / > / 0x504 : DSL line status idle. / > / 0x505 : DSL line status silent. / > / 0x506 : DSL line status *training*//. / > / 0x507 : DSL line integrity error. / > / 0x508 : DSLAM resource not available. / > / 0x509 : Invalid test parameter. / > > > 2) but not in "Toplogy Discovery" messages, > Cf section 5.4.2:/ / > Type (DSL line state =3D 0x8F) > / (...)/ > / { SHOWTIME =3D 0x01, IDLE =3D 0x02, SILENT =3D 0x03 } / > > > Question: is this intentional or is "training" state just forgotten = in=20 > "Topology Discovery" messages ? > > Thanks for clarifications, > Kind regards, > Robert Peschi > = ------------------------------------------------------------------------ > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp > =20 =09 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp ------_=_NextPart_001_01C74088.0563C324 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nachricht</TITL= E> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2900.3020" name=3DGENERATOR><o:SmartTagType name=3D"PersonName"=20 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT= ype> <STYLE>@font-face { font-family: Tahoma; } @font-face { font-family: sans-serif; } @page Section1 {size: 595.3pt 841.9pt; margin: 70.85pt 70.85pt 2.0cm = 70.85pt; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline } A:visited { COLOR: purple; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline } P { FONT-SIZE: 12pt; MARGIN-LEFT: 0cm; MARGIN-RIGHT: 0cm; FONT-FAMILY: = "Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto } TT { FONT-FAMILY: "Courier New" } SPAN.E-MailFormatvorlage19 { COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply } DIV.Section1 { page: Section1 } </STYLE> </HEAD> <BODY lang=3DDE vLink=3Dpurple link=3Dblue> <DIV><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi=20 all<o:p></o:p></DIV> <DIV class=3DSection1> <DIV> <SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></DIV> <DIV> <SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">I agree with=20 Robert.<o:p></o:p></DIV> <DIV> <SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></DIV> <DIV> <DIV> <SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">OAM-Ping is = intended to=20 request the actual state of a line. <o:p></o:p></DIV> <DIV> <SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Therefor, if = a line is=20 in training mode, we should report "training=20 mode".<o:p></o:p></DIV> <DIV> <SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Arial"> <o:p></o:p></DIV> <DIV> <SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">The = PortUp/Down Event=20 messages are intend to give the BRAS the actual state of each=20 port.<o:p></o:p></DIV> <DIV> <SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">The "training = state"=20 can only be entered from the silent state, but it is not a steady=20 state.<o:p></o:p></DIV> <DIV> <SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">As long as a = line is=20 not in showtime, no traffic can flow. For that reason, sending Port Down = <o:p></o:p></DIV> <DIV> <SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">with line = state =3D=20 "silent" seems to be appropriate. <o:p></o:p></DIV> <DIV> <SPAN=20 style=3D"FONT-SIZE: = 12pt"> <o:p></o:p></DIV></DIV> <DIV> <SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Kind=20 regards<o:p></o:p></DIV> <DIV> <SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Arial">Michael<o:p></o:p></DIV> <DIV> <SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></DIV> <DIV> <SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></DIV> <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt; MARGIN-RIGHT: = 0cm"> <SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">-----Urspr=FCngliche=20 Nachricht----- Von: = Robert.Peschi@alcatel-lucent.be = [mailto:Robert.Peschi@alcatel-lucent.be]=20 Gesendet: = Dienstag, 23.=20 Januar 2007 11:46 An: Jakob=20 Heitz Cc:=20 ancp@ietf.org Betreff: Re:=20 [ANCP] Reporting "Training" state<o:p></o:p> Hello Jakob and=20 All, <SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: sans-serif">My = take:=20 <SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: sans-serif">1) Training means = that the=20 DSLAM is establishing DSL connectivity =20 so DSLAM is certainly "willing" to establish connectivity = with=20 CPE <SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: sans-serif"> = =20 so DSLAM is certainly NOT idle which would mean=20 "unwilling" <SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: sans-serif">2) Training also = means that=20 the DSL connectivity is not yet OK so=20 it is certainly NOT showtime which would mean "traffic able to=20 flow" <SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: sans-serif">So, for what = topology=20 discovery is used for, the most sensible looks to be:=20 <SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: sans-serif">"Send port DOWN = with line=20 state =3D silent" <SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: sans-serif">Kind = regards,=20 <SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = sans-serif">Robert=20 <o:p></o:p> <TABLE class=3DMsoNormalTable style=3D"WIDTH: 100%" cellPadding=3D0 = width=3D"100%"=20 border=3D0> <TBODY> <TR> <TD=20 style=3D"PADDING-RIGHT: 0.75pt; PADDING-LEFT: 0.75pt; = PADDING-BOTTOM: 0.75pt; PADDING-TOP: 0.75pt"=20 vAlign=3Dtop> <SPAN=20 style=3D"FONT-SIZE: = 12pt"><o:p> </o:p></TD> <TD=20 style=3D"PADDING-RIGHT: 0.75pt; PADDING-LEFT: 0.75pt; = PADDING-BOTTOM: 0.75pt; PADDING-TOP: 0.75pt"=20 vAlign=3Dtop> <SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 7.5pt; FONT-FAMILY: = sans-serif">Jakob=20 Heitz <jheitz+121406@redback.com>=20 <o:p></o:p> <SPAN=20 style=3D"FONT-SIZE: 7.5pt; FONT-FAMILY: sans-serif">01/22/2007 = 09:25=20 PM <o:p></o:p></TD> <TD=20 style=3D"PADDING-RIGHT: 0.75pt; PADDING-LEFT: 0.75pt; = PADDING-BOTTOM: 0.75pt; PADDING-TOP: 0.75pt"=20 vAlign=3Dtop> <SPAN=20 style=3D"FONT-SIZE: 7.5pt; FONT-FAMILY: Arial"> = =20 <SPAN=20 style=3D"FONT-SIZE: 7.5pt; FONT-FAMILY: sans-serif"> = =20 To: = ancp@ietf.org=20 <SPAN=20 style=3D"FONT-SIZE: 7.5pt; FONT-FAMILY: sans-serif"> = =20 cc: <FONT=20 face=3Dsans-serif size=3D1><SPAN=20 style=3D"FONT-SIZE: 7.5pt; FONT-FAMILY: sans-serif"> = =20 Subject: Re: [ANCP] Reporting=20 "Training" = state<o:p></o:p></TD></TR></TBODY></TABLE> <TT><FONT=20 face=3D"Courier New" size=3D2>The "DSL = line state"=20 TLV is mandatory in PORT DOWN messages</TT><FONT=20 face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"> <TT><FONT=20 face=3D"Courier New">and optional in PORT UP messages. When the DSLAM=20 establishes</TT> <TT>an ANCP = connection, it=20 will send a topology discovery message</TT> <TT><FONT=20 face=3D"Courier New">for EVERY port: either PORT UP or PORT=20 DOWN.</TT> <TT>What should = this TLV=20 contain if a DSL line is in the "training"</TT> <TT><FONT=20 face=3D"Courier New">state at this time?</TT> <TT><FONT=20 face=3D"Courier New">Kind Regards,</TT> <TT><FONT=20 face=3D"Courier New">Jakob Heitz.</TT> <TT><FONT=20 face=3D"Courier New">Derek Harkness wrote:</TT> <TT><FONT=20 face=3D"Courier New">> My understanding would be that the topology = discovery=20 message is sent </TT> <TT>> = when the=20 line reaches a steady state ( one of the 3 listed ) and when=20 </TT> <TT>> it is training the = line=20 state is in some form transition between 2 of = </TT> <TT><FONT=20 face=3D"Courier New">> these states</TT> <TT><FONT=20 face=3D"Courier New">> </TT> <TT><FONT=20 face=3D"Courier New">> D</TT> <TT>>=20 </TT> <TT>>=20 = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D+</TT> <TT><FONT=20 face=3D"Courier New">> Derek Harkness</TT> <TT><FONT=20 face=3D"Courier New">> Juniper Networks</TT> <TT><FONT=20 face=3D"Courier New">> Nymphenburger Strasse = 13-15</TT> <TT><FONT=20 face=3D"Courier New">> 80335 Munich</TT> <TT><FONT=20 face=3D"Courier New">> Germany</TT> <TT><FONT=20 face=3D"Courier New">> Tel: +49 89 5529 = 4916</TT> <TT><FONT=20 face=3D"Courier New">> Mobile: +49 172 843 = 6621</TT> <TT><FONT=20 face=3D"Courier New">> Email: DHarkness@juniper.net=20 <mailto:DHarkness@juniper.net></TT> <TT><FONT=20 face=3D"Courier New">>=20 = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D+</TT> <TT><FONT=20 face=3D"Courier New">> </TT> <TT><FONT=20 face=3D"Courier New">></TT> <TT>>=20 = ------------------------------------------------------------------------<= /FONT></TT> <TT><FONT=20 face=3D"Courier New">> *From:* Robert.Peschi@alcatel-lucent.be=20 </TT> <TT>>=20 [mailto:Robert.Peschi@alcatel-lucent.be]</TT> <TT><FONT=20 face=3D"Courier New">> *Sent:* 22 January 2007 = 14:23</TT> <TT><FONT=20 face=3D"Courier New">> *To:* ancp@ietf.org</TT> <TT>> *Subject:* [ANCP] Reporting "Training"=20 state</TT> <TT><FONT=20 face=3D"Courier New">></TT> <TT><FONT=20 face=3D"Courier New">></TT> <TT>> Hi=20 All,</TT> <TT>></TT> <TT><FONT=20 face=3D"Courier New">> In the current ANCP IETF=20 draft,</TT> <TT>>=20 = http://www.ietf.org/internet-drafts/draft-wadhwa-gsmp-l2control-configura= tion-02.txt=20 </TT> <TT>></TT> <TT><FONT=20 face=3D"Courier New">></TT> <TT>> One=20 reads that DSL "Training" state,</TT> <TT><FONT=20 face=3D"Courier New">></TT> <TT>> 1)=20 should be reported upon OAM requests,</TT> <TT><FONT=20 face=3D"Courier New">> Cf section = 5.4.4:</TT> <TT><FONT=20 face=3D"Courier New">> / 0x500 : Specified access line = does not=20 exist. /</TT> <TT>> / = 0x501=20 : Loopback test timed out. /</TT> <TT>>=20 / 0x502 : Reserved /</TT> <TT><FONT=20 face=3D"Courier New">> / 0x503 : DSL line status = showtime.=20 /</TT> <TT>> / = 0x504 : DSL=20 line status idle. /</TT> <TT>> = / =20 0x505 : DSL line status silent. /</TT> <TT><FONT=20 face=3D"Courier New">> / 0x506 : DSL line status = *training*//.=20 /</TT> <TT>> / = 0x507 : DSL=20 line integrity error. /</TT> <TT>> /=20 0x508 : DSLAM resource not available. = /</TT> <TT><FONT=20 face=3D"Courier New">> / 0x509 : Invalid test = parameter.=20 /</TT> <TT>></TT> <TT><FONT=20 face=3D"Courier New">></TT> <TT>> 2)=20 but not in "Toplogy Discovery" messages,</TT> <TT><FONT=20 face=3D"Courier New">> Cf section 5.4.2:/ = /</TT> <TT><FONT=20 face=3D"Courier New">> Type (DSL line state =3D=20 0x8F)</TT> <TT>> / =20 (...)/</TT> <TT>> / = {=20 SHOWTIME =3D 0x01, IDLE =3D 0x02, SILENT =3D 0x03 } = /</TT> <TT><FONT=20 face=3D"Courier New">></TT> <TT><FONT=20 face=3D"Courier New">></TT> <TT>>=20 Question: is this intentional or is "training" state just forgotten in = </TT> <TT>> "Topology = Discovery"=20 messages ?</TT> <TT><FONT=20 face=3D"Courier New">></TT> <TT>>=20 Thanks for clarifications,</TT> <TT>>=20 Kind regards,</TT> <TT>> = Robert=20 Peschi</TT> <TT>>=20 = ------------------------------------------------------------------------<= /FONT></TT> <TT><FONT=20 face=3D"Courier New">></TT> <TT>>=20 = _______________________________________________</TT> <TT>> ANCP mailing list</TT> <TT><FONT=20 face=3D"Courier New">> ANCP@ietf.org</TT> <TT><FONT=20 face=3D"Courier New">>=20 https://www1.ietf.org/mailman/listinfo/ancp</TT> <TT><FONT=20 face=3D"Courier New">> </TT> <TT><FONT=20 face=3D"Courier = New">_______________________________________________</TT> <TT><= FONT=20 face=3D"Courier New">ANCP mailing list</TT> <TT><FONT=20 face=3D"Courier New">ANCP@ietf.org</TT> <TT><FONT=20 face=3D"Courier = New">https://www1.ietf.org/mailman/listinfo/ancp</TT></FONT= ><o:p></o:p></BLOCKQUOTE></DIV></BODY></HTML> ------_=_NextPart_001_01C74088.0563C324-- --===============0795535035== 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 --===============0795535035==--