Access-Node Partitioning

From ancp-bounces@ietf.org Wed Aug 02 03:27:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8B87-0001k6-Ou; Wed, 02 Aug 2006 03:26:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8B86-0001k1-TP for ancp@ietf.org; Wed, 02 Aug 2006 03:26:58 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8B84-0006Vb-Gj for ancp@ietf.org; Wed, 02 Aug 2006 03:26:58 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP for ancp@ietf.org; Wed, 2 Aug 2006 09:26:55 +0200 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Aug 2006 09:26:55 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED2C456C4@S4DE8PSAAFQ.mitte.t-com.de> From: "Busser, M" To: ancp@ietf.org Date: Wed, 2 Aug 2006 09:26:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [ANCP] Graceful restart 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 Sanjay, Reviewing your document I have one question for clarification. Am I right if I say? We are talking about a "restarting node" and a "neighbor of a = restarting node". During capabillity negotiation, each node tells his = neighbor the time, he needs to restart (Restarting Time). So the = restarting time, wich A sends to B is refered to as the waiting time at = B. Please correct me if I'm wrong. Regards Michael Michael Busser ------------------------------------------------------------------------= T-Systems International Systems Integration Business Unit Technologiezentrum=20 Michael Busser Br=FCckes 2 - 8, 55545 Bad Kreuznach Tel: +49 671 8333-8911 Fax: +49 671 8333-8983 Mobil: (0151) 12 11 96 89 mailto:michael.busser@t-systems.com=20 Internet: http://www.t-systems.com/ _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Aug 02 06:02:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8DYm-0004qN-74; Wed, 02 Aug 2006 06:02:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8DYl-0004qH-E8 for ancp@ietf.org; Wed, 02 Aug 2006 06:02:39 -0400 Received: from ilsmtp01.ecitele.com ([147.234.1.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8DYi-00072d-Qr for ancp@ietf.org; Wed, 02 Aug 2006 06:02:39 -0400 To: swadhwa@juniper.net, jmoisand@juniper.net, ssubramanian@juniper.net, thomas.haag@t-systems.com, norbert.voigt@siemens.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.3 September 14, 2004 Message-ID: From: Menachem.Dodge@ecitele.com Date: Wed, 2 Aug 2006 13:02:32 +0300 X-MIMETrack: Serialize by Router on ILSMTP01/ECI Telecom(Release 6.5.3FP1 | December 22, 2004) at 08/02/2006 13:11:02, Serialize complete at 08/02/2006 13:11:02 X-Spam-Score: 0.3 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: ancp@ietf.org Subject: [ANCP] Layer 2 Parameters in the Protocol document 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="===============1571522927==" Errors-To: ancp-bounces@ietf.org This is a multipart message in MIME format. --===============1571522927== Content-Type: multipart/alternative; boundary="=_alternative 00372AC5C22571BE_=" This is a multipart message in MIME format. --=_alternative 00372AC5C22571BE_= Content-Type: text/plain; charset="US-ASCII" Hi, I sent this email over a week ago and have had no response. I would appreciate a reply on how the protocol handles: Multiple Vlans on a single encapsulation and also multiple encapsulations. Thank You Kindly. Best Regards, Menachem Dodge ======================================================================== Original Email: Regarding the document: "draft-wadhwa-gsmp-l2control-configuration" and following the questions I raised at the meeting in Montreal, I would like to request an explanation of how to handle: 1. Multiple Vlans in a single encapsulation. 2. Multiple Vlans and Multiple encapsulations. 1. Multiple Vlans in a single encapsulation. a. Should an Access-Loop-Circuit-Id be defined for each Vlan which means that this is a many-to-one relationship? b. Should there be more than one Access-Loop-Remote-Id's or is one sufficient? If more are needed, how are they associated with an Access-Loop-Circuit-Id? c. Should there be an Access-Aggregation-Circuit-Id-Binary and Access-Aggregation-Circuit-Id-ASCII for each Access-Loop-Circuit-Id defined? d. I assume there are only one set of "DSL Line Attributes" defined which are common to the physical line. 2. Multiple Vlans and Multiple encapsulations. a. If the Vlan's are related to different "Access Loop Encapsulations" how is this association between Vlan and encapsulation shown? Best Regards, Menachem --=_alternative 00372AC5C22571BE_= Content-Type: text/html; charset="US-ASCII"
Hi,

I sent this email over a week ago and have had no response. I would appreciate a reply on how the protocol handles: Multiple Vlans on a
single encapsulation and also multiple encapsulations.

Thank You Kindly.

Best Regards,
Menachem Dodge

========================================================================

Original Email:

Regarding the document: "draft-wadhwa-gsmp-l2control-configuration" and following the questions I raised at the meeting in Montreal,
I would like to request an explanation of how to handle:

1. Multiple Vlans in a single encapsulation.
2. Multiple Vlans and Multiple encapsulations.

1. Multiple Vlans in a single encapsulation.

a. Should an Access-Loop-Circuit-Id be defined for each Vlan which means that this is a many-to-one relationship?
b. Should there be more than one Access-Loop-Remote-Id's or is one sufficient? If more are needed, how are they associated with an
Access-Loop-Circuit-Id?
c. Should there be an Access-Aggregation-Circuit-Id-Binary and Access-Aggregation-Circuit-Id-ASCII for each
Access-Loop-Circuit-Id defined?
d. I assume there are only one set of "DSL Line Attributes" defined which are common to the physical line.

2. Multiple Vlans and Multiple encapsulations.
a. If the Vlan's are related to different "Access Loop Encapsulations" how is this association between Vlan and encapsulation shown?

Best Regards,
Menachem
--=_alternative 00372AC5C22571BE_=-- --===============1571522927== 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 --===============1571522927==-- From ancp-bounces@ietf.org Mon Aug 07 05:44:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA1f4-0005nm-6x; Mon, 07 Aug 2006 05:44:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA1f3-0005nS-9h for ancp@ietf.org; Mon, 07 Aug 2006 05:44:37 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GA1f1-0002ym-Qj for ancp@ietf.org; Mon, 07 Aug 2006 05:44:37 -0400 Received: from bemail06.netfr.alcatel.fr (bemail06.netfr.alcatel.fr [155.132.251.30]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k779iYnC029705 for ; Mon, 7 Aug 2006 11:44:34 +0200 Received: from [172.31.194.43] ([172.31.194.43]) by bemail06.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163) with ESMTP id 2006080711443229:1468 ; Mon, 7 Aug 2006 11:44:32 +0200 Message-ID: <44D70B7C.7060807@alcatel.be> Date: Mon, 07 Aug 2006 11:44:28 +0200 From: stefaan.de_cnodder@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ancp@ietf.org X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/07/2006 11:44:32, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/07/2006 11:44:33, Serialize complete at 08/07/2006 11:44:33 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [ANCP] graceful restart comments 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, some comments on the graceful restart draft: The draft does not make any distinction between planned and unplanned restarts. Would it not be better to focus on planned restarts to begin with? With the current solution, if for instance the uplink of the AN fails, then the NAS thinks that the AN is still forwarding packets. The NAS will only detect after "restarting time" that the forwarding plane is not up anymore and during this time, the NAS was always faulty assuming that the forwarding plane was up. Therefore it is better to focus first on planned restarts: just before the planned restart, the restarting device sends the Graceful restart TLV with the waiting time to the other side, then it restarts. For planned restarts, there is not much risk for the other side to faulty assuming that the forwarding plane is up while this is clearly not the case for unplanned restarts. This also means that the GR-TLV has to be sent just before the planned restart. When the GR-TLV is sent, is left vague in the draft but I understand that currently the draft assumes that it has to be sent after ANCP session establishement. Paragraph 3-4 of introduction: a failure of the AN uplink or a failure of an intermediate node will make the ANCP data invallid and not is not valid anymore as said in these paragraphs. Last paragraph of section 3: The restarting neighbor MUST (and not SHOULD) advertise the duration.... why is it not a MUST? The same section says that the ANCP neighbor has to wait for "restarting time" before setting up the adjancency again. Why is there a need for this? The neigbor should constantly retry to reestablish the session, and if it fails to reestablish the session, and to resyncronize the state within "restarting time" then the graceful restart procedure is ended. So there is no need to have a seperate "wait time". Just a "restart time" is sufficient but it has to be redefined. When the AN is restarting, then how should this work? It is always the AN that has to establish the session and not the NAS. Because of this a-symmetry in the protocol, it is better to make the graceful restart also asymmetric. When the wait time expires (section 4.1), the graceful restart procedure is aborted but it looks that aborting the procedure looks rather drastic: tearing down the session and start all over again. Why would you do this? Then we have the following sequence: the session breaks, comes up again, graceful restart procedure starts, timers expires, session down again, comes up again, and then to normal procedure. If the timer expires, I would say that this should be the same as receiving the "END-OF-STATE" message and all stale state is removed but the session stays up. First paragraph of section 4.2 uses a different definition of the "restart time" because the draft says that after "restarting time" the session re-establishement starts according to section 3. Section 4.2. is more in line with what I said above and "wait time" has to be removed. Editorial: remove first paragraph of the introduction, it does not belong here and is partially duplicate with the second paragraph. regards, Stefaan _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Aug 07 10:41:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA6Ig-0004l5-OZ; Mon, 07 Aug 2006 10:41:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA6Ie-0004l0-SL for ancp@ietf.org; Mon, 07 Aug 2006 10:41:48 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GA6Id-0004Ej-BP for ancp@ietf.org; Mon, 07 Aug 2006 10:41:48 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 07 Aug 2006 07:41:47 -0700 X-IronPort-AV: i="4.07,219,1151910000"; d="scan'208,217"; a="569512613:sNHT75476724" x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Aug 2006 10:41:57 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2803B75985@proton.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Layer 2 Parameters in the Protocol document Thread-Index: Aca2Gt5OOtCS3slCRQavpFzc+8LhawAPhFBw From: "Sanjay Wadhwa" To: , "Jerome Moisand" , "Swami Subramanian" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: ancp@ietf.org Subject: [ANCP] RE: Layer 2 Parameters in the Protocol document 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="===============0806911019==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0806911019== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6BA2F.A25361B7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6BA2F.A25361B7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Menachem The ACI sent in L2C has the same format as what is sent by the DSLAM in DHCP opt 82 or PPPoE-IA tag i.e. VLAN tag is part of the ACI. For each VLAN on a local-loop this translates to a unique ACI.=20 Access-loop-remote-id is an operator configured value for a given subscriber on the local-loop. The exact DSLAM behaviour is outside the scope of the draft. However, I would assume if there are multiple VLANs to the customer premise (one per subscriber), then the relay-agent should insert a different access-remote-id per subscriber. It is an optional TLV.. However, when present it will be unique to the subscriber. Access-Aggregation-IDs are optional TLVs. These can be used to define DSLAM uplink attributes if needed. =20 -Sanjay =20 Regarding the document: "draft-wadhwa-gsmp-l2control-configuration" and following the questions I raised at the meeting in Montreal,=20 I would like to request an explanation of how to handle:=20 1. Multiple Vlans in a single encapsulation.=20 2. Multiple Vlans and Multiple encapsulations.=20 1. Multiple Vlans in a single encapsulation.=20 a. Should an Access-Loop-Circuit-Id be defined for each Vlan which means that this is a many-to-one relationship?=20 b. Should there be more than one Access-Loop-Remote-Id's or is one sufficient? If more are needed, how are they associated with an=20 Access-Loop-Circuit-Id?=20 c. Should there be an Access-Aggregation-Circuit-Id-Binary and Access-Aggregation-Circuit-Id-ASCII for each=20 Access-Loop-Circuit-Id defined?=20 d. I assume there are only one set of "DSL Line Attributes" defined which are common to the physical line.=20 2. Multiple Vlans and Multiple encapsulations.=20 a. If the Vlan's are related to different "Access Loop Encapsulations" how is this association between Vlan and encapsulation shown?=20 =20 Best Regards,=20 Menachem ------_=_NextPart_001_01C6BA2F.A25361B7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi=20 Menachem

The ACI sent in L2C has the same = format as what=20 is sent by the DSLAM in DHCP opt 82 or PPPoE-IA tag i.e. VLAN tag = is part=20 of the ACI. For each VLAN on a local-loop this translates to a = unique ACI.=20

Access-loop-remote-id is an operator = configured=20 value for a given subscriber on the local-loop. The exact = DSLAM=20 behaviour is outside the scope of the draft. However, I would assume if = there=20 are multiple VLANs to the customer premise (one per=20 subscriber), then the relay-agent should insert a = different=20 access-remote-id per subscriber. It is an optional TLV.. However, when = present=20 it will be unique to the subscriber.

Access-Aggregation-IDs are optional TLVs. = These can be=20 used to define DSLAM uplink attributes if needed.

-Sanjay

Regarding the = document:=20 "draft-wadhwa-gsmp-l2control-configuration" and following the = questions I=20 raised at the meeting in Montreal,
I would like to request an explanation of how to = handle:=20

= 1.=20 Multiple Vlans in a single encapsulation.
2. = Multiple Vlans and=20 Multiple encapsulations.

1. Multiple Vlans in a single=20 encapsulation.

= =20 a. Should an=20 Access-Loop-Circuit-Id be defined for each Vlan which means that this = is a=20 many-to-one relationship?
=20 b. Should there = be more=20 than one Access-Loop-Remote-Id's or is one sufficient? If more are = needed, how=20 are they associated with an
=20 =20 Access-Loop-Circuit-Id?
=20 c. Should there = be an=20 Access-Aggregation-Circuit-Id-Binary and = Access-Aggregation-Circuit-Id-ASCII=20 for each
Access-Loop-Circuit-Id=20 defined?
= =20 d. I = assume=20 there are only one set of "DSL Line Attributes" defined which are = common to=20 the physical line.

=20 2. Multiple Vlans and = Multiple=20 encapsulations.
= =20 a. If the Vlan's are related = to=20 different "Access Loop Encapsulations" how is this association between = Vlan=20 and encapsulation shown?
=20

Best = Regards,=20
Menachem
------_=_NextPart_001_01C6BA2F.A25361B7-- --===============0806911019== 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 --===============0806911019==-- From ancp-bounces@ietf.org Mon Aug 07 11:54:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA7Qb-00064j-I0; Mon, 07 Aug 2006 11:54:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA7Qa-00060m-3I for ancp@ietf.org; Mon, 07 Aug 2006 11:54:04 -0400 Received: from ilsmtp01.ecitele.com ([147.234.1.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GA7QS-0005iq-JL for ancp@ietf.org; Mon, 07 Aug 2006 11:54:04 -0400 In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2803B75985@proton.jnpr.net> To: "Sanjay Wadhwa" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.3 September 14, 2004 Message-ID: From: Menachem.Dodge@ecitele.com Date: Mon, 7 Aug 2006 18:53:53 +0300 X-MIMETrack: Serialize by Router on ILSMTP01/ECI Telecom(Release 6.5.3FP1 | December 22, 2004) at 08/07/2006 19:02:23, Serialize complete at 08/07/2006 19:02:23 X-Spam-Score: 0.3 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 Cc: Swami Subramanian , ancp@ietf.org Subject: [ANCP] RE: Layer 2 Parameters in the Protocol document 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="===============0615833644==" Errors-To: ancp-bounces@ietf.org This is a multipart message in MIME format. --===============0615833644== Content-Type: multipart/alternative; boundary="=_alternative 00575461C22571C3_=" This is a multipart message in MIME format. --=_alternative 00575461C22571C3_= Content-Type: text/plain; charset="US-ASCII" Hello Sanjay, Thank you for your email. However, I understand from you, that there is an underlying assumption that there is only a single Vlan per subscriber. This is too limiting, it must be possible to allow several VLANs per subscriber. In this case for a single subscriber there would be: 1. Several Access-Loop-Circuit-IDs (one per local Vlan) 2. Only one Access-Loop-Remote-Id (one per subscriber) 3. Several Access-Aggregation-Circuit-Id-Binary (one per aggregation Vlan) 4. Several Access-Aggregation-Circuit-Id-ASCII (one per aggregation Vlan) 5. One set of DSL Line Attributes (one per local loop) - except for the Access Loop Encapsulation (one per Vlan). As you can see, some of the information needs to be provided: a. Per local loop / subscriber. b. Per Vlan. The current message format, as I understand it, does not allow for this. It would require sending a separate message per Vlan but this will mean some information must be repeated unnecessarily and increase the number of messages that need to be sent. It should be possible to: A. Separate the per subscriber information from the Per Vlan information. B. Bundle the per Vlan information into blocks so that for each Vlan there is an additional block of information relating to that Vlan. Best Regards, Menachem Dodge ECI Telecom Ltd. Broadband Access Division Tel: +972-3-9268421 Mobile: +972-54-5788421 Fax: +972-3-9287342 e-mail: menachem.dodge@ecitele.com www.ecitele.com "Sanjay Wadhwa" 07/08/2006 17:41 To , "Jerome Moisand" , "Swami Subramanian" , , cc Subject RE: Layer 2 Parameters in the Protocol document Hi Menachem The ACI sent in L2C has the same format as what is sent by the DSLAM in DHCP opt 82 or PPPoE-IA tag i.e. VLAN tag is part of the ACI. For each VLAN on a local-loop this translates to a unique ACI. Access-loop-remote-id is an operator configured value for a given subscriber on the local-loop. The exact DSLAM behaviour is outside the scope of the draft. However, I would assume if there are multiple VLANs to the customer premise (one per subscriber), then the relay-agent should insert a different access-remote-id per subscriber. It is an optional TLV.. However, when present it will be unique to the subscriber. Access-Aggregation-IDs are optional TLVs. These can be used to define DSLAM uplink attributes if needed. -Sanjay Regarding the document: "draft-wadhwa-gsmp-l2control-configuration" and following the questions I raised at the meeting in Montreal, I would like to request an explanation of how to handle: 1. Multiple Vlans in a single encapsulation. 2. Multiple Vlans and Multiple encapsulations. 1. Multiple Vlans in a single encapsulation. a. Should an Access-Loop-Circuit-Id be defined for each Vlan which means that this is a many-to-one relationship? b. Should there be more than one Access-Loop-Remote-Id's or is one sufficient? If more are needed, how are they associated with an Access-Loop-Circuit-Id? c. Should there be an Access-Aggregation-Circuit-Id-Binary and Access-Aggregation-Circuit-Id-ASCII for each Access-Loop-Circuit-Id defined? d. I assume there are only one set of "DSL Line Attributes" defined which are common to the physical line. 2. Multiple Vlans and Multiple encapsulations. a. If the Vlan's are related to different "Access Loop Encapsulations" how is this association between Vlan and encapsulation shown? Best Regards, Menachem --=_alternative 00575461C22571C3_= Content-Type: text/html; charset="US-ASCII"
Hello Sanjay,

Thank you for your email.

However, I understand from you, that there is an underlying assumption that there is only a single Vlan per subscriber.
This is too limiting, it must be possible to allow several VLANs per subscriber.

In this case for a single subscriber there would be:

1. Several Access-Loop-Circuit-IDs (one per local Vlan)
2. Only one Access-Loop-Remote-Id (one per subscriber)
3. Several Access-Aggregation-Circuit-Id-Binary (one per aggregation Vlan)
4. Several Access-Aggregation-Circuit-Id-ASCII (one per aggregation Vlan)
5. One set of DSL Line Attributes (one per local loop) - except for the Access Loop Encapsulation (one per Vlan).

As you can see, some of the information needs to be provided:
a. Per local loop / subscriber.
b. Per Vlan.

The current message format, as I understand it, does not allow for this. It would require sending a separate message per Vlan
but this will mean some information must be repeated unnecessarily and increase the number of messages that need to be sent. It should
be possible to:
A. Separate the per subscriber information from the Per Vlan information.
B. Bundle the per Vlan information into blocks so that for each Vlan there is an additional block of information relating to that Vlan.

Best Regards,
Menachem Dodge
ECI Telecom Ltd.
Broadband Access Division

Tel: +972-3-9268421
Mobile: +972-54-5788421
Fax: +972-3-9287342
e-mail: menachem.dodge@ecitele.com
www.ecitele.com

"Sanjay Wadhwa" <swadhwa@juniper.net>

07/08/2006 17:41

To	<Menachem.Dodge@ecitele.com>, "Jerome Moisand" <jmoisand@juniper.net>, "Swami Subramanian" <ssubramanian@juniper.net>, <thomas.haag@t-systems.com>, <norbert.voigt@siemens.com>
cc	<ancp@ietf.org>
Subject	RE: Layer 2 Parameters in the Protocol document

Hi Menachem
The ACI sent in L2C has the same format as what is sent by the DSLAM in DHCP opt 82 or PPPoE-IA tag i.e. VLAN tag is part of the ACI. For each VLAN on a local-loop this translates to a unique ACI.
Access-loop-remote-id is an operator configured value for a given subscriber on the local-loop. The exact DSLAM behaviour is outside the scope of the draft. However, I would assume if there are multiple VLANs to the customer premise (one per subscriber), then the relay-agent should insert a different access-remote-id per subscriber. It is an optional TLV.. However, when present it will be unique to the subscriber.
Access-Aggregation-IDs are optional TLVs. These can be used to define DSLAM uplink attributes if needed.

-Sanjay

Regarding the document: "draft-wadhwa-gsmp-l2control-configuration" and following the questions I raised at the meeting in Montreal,
I would like to request an explanation of how to handle:

1. Multiple Vlans in a single encapsulation.
2. Multiple Vlans and Multiple encapsulations.

1. Multiple Vlans in a single encapsulation.

a. Should an Access-Loop-Circuit-Id be defined for each Vlan which means that this is a many-to-one relationship?
b. Should there be more than one Access-Loop-Remote-Id's or is one sufficient? If more are needed, how are they associated with an
Access-Loop-Circuit-Id?
c. Should there be an Access-Aggregation-Circuit-Id-Binary and Access-Aggregation-Circuit-Id-ASCII for each
Access-Loop-Circuit-Id defined?
d. I assume there are only one set of "DSL Line Attributes" defined which are common to the physical line.

2. Multiple Vlans and Multiple encapsulations.
a. If the Vlan's are related to different "Access Loop Encapsulations" how is this association between Vlan and encapsulation shown?

Best Regards,
Menachem
--=_alternative 00575461C22571C3_=-- --===============0615833644== 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 --===============0615833644==-- From ancp-bounces@ietf.org Fri Aug 11 07:55:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBVcB-0004pe-Ql; Fri, 11 Aug 2006 07:55:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBVcA-0004o9-WD for ancp@ietf.org; Fri, 11 Aug 2006 07:55:47 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBVcA-0006VE-T6 for ancp@ietf.org; Fri, 11 Aug 2006 07:55:46 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GBVcA-0005Ng-9Q for ancp@ietf.org; Fri, 11 Aug 2006 07:55:46 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 11 Aug 2006 04:55:43 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,114,1154934000"; d="scan'208,217"; a="35658377:sNHT43211636" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7BBtgju011382; Fri, 11 Aug 2006 07:55:43 -0400 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 k7BBtg7e011643; Fri, 11 Aug 2006 13:55:42 +0200 (MEST) 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); Fri, 11 Aug 2006 13:55:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Aug 2006 13:55:31 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Access-Node Partitioning Thread-Index: Aca9PQuJrVahSX6gTl2dilcS7i6uTQ== From: "Wojciech Dec \(wdec\)" To: X-OriginalArrivalTime: 11 Aug 2006 11:55:42.0521 (UTC) FILETIME=[125A7290:01C6BD3D] DKIM-Signature: a=rsa-sha1; q=dns; l=7240; t=1155297343; x=1156161343; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=22Wojciech=20Dec=20\(wdec\)=22=20 |Subject:Access-Node=20Partitioning |To:; X=v=3Dcisco.com=3B=20h=3DU/9iKJvB2ZAYWVrdgIsKJkxkSAo=3D; b=oNwmI5b3Y2mSiKZL4KZ6udwYsFqEBIGDIyCdRT/IhWp7EMfO5E3s+RNJjXjpot1ReKnzA8Zv krCwFSWgwnnpV2caKqSu7//kXjFmHo5lNvB5RrNRvx9FKL5IduzxqRUi; Authentication-Results: rtp-dkim-1.cisco.com; header.From=wdec@cisco.com; dkim=pass ( 61 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: -2.5 (--) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: Subject: [ANCP] Access-Node Partitioning 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="===============0406871672==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0406871672== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6BD3D.12351CE3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6BD3D.12351CE3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, During our IETF 66 ANCP meeting we briefly discussed the issue of access-node partitioning and I took the action to attempt to commence a discussion on what is actually required. The outcome of this would go into the protocol requirements framework. Brief background. The GSMP protocol (citing RFC3292 here ) allows for a mode of operation whereby an access-node may be controlled by more than one controller by using the technique of partitioning. In effect the "physical" access-node can be partitioned into several virtual access-nodes that are referred to as partitions. The partitions of a physical access-node are isolated from each other by the implementation and the controller assumes that the resources allocated to a partition are at all times available to that partition. No controller redundancy mechanisms are described. In other words, as applied to our ANCP use, the GSMP base protocol allows for what may term a 1-1 control relationship between a particular access-ports in one partition and a controller, with other access-ports in other partitions having the same 1-1 relationship with their controller. For the sake of the discussion, I'll call this partitioning method "hard partitioning" Taking the partitioning concept above a step further, it is possible to imagine what one may term as "functional partitioning" scheme. In such a scheme, specific functions and/or data elements of a particular access-port would have a 1-1 relationship with a controller uniquely allowed to modify these functions or access data elements.=20 In terms of the ANCP use-cases, this could translate to a set-up whereby for a single access-port, say the access-port's modem train rate information would communicated to one controller (let's call it controller X), while the OAM function, or configuration parameters would be communicated with another controller (let's call it Y).=20 More elaborate combinations of such a scheme could also be possible, eg having the modem train rate be communicated to both X and Y, while retaining the OAM function's control only on controller Y. Given all of the above several questions appear to be appropriate for a start: - Is there interest in enabling ANCP with "hard partitioning"? - In case of "hard partitioning", is it expected that each controller will be a separate entity, or is there also a need to consider controller partitioning? (Two different partitions on the same access-node have an ANCP adjacency to the same controller) - Is there interest in enabling ANCP with "functional partitioning"? - In any partitioning scheme (hard of functional), is there a need to allow for controller redundancy? I hope that the above is sufficient to stimulate a discussion and make some progress on the issue of partitioning. Kind Regards, Woj. ------_=_NextPart_001_01C6BD3D.12351CE3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Access-Node Partitioning

Dear All,

During our IETF 66 ANCP meeting we = briefly discussed the issue of access-node partitioning and I took the = action to attempt to commence a discussion on what is actually required. = The outcome of this would go into the protocol requirements = framework.

Brief background.
The GSMP protocol (citing RFC3292 here = ) allows for a mode of operation whereby an access-node may be = controlled by more than one controller by using the technique of = partitioning. In effect the "physical" access-node can be = partitioned into several virtual access-nodes that are referred to as = partitions. The partitions of a physical access-node are isolated from = each other by the implementation and the controller assumes that the = resources allocated to a partition are at all times available to that = partition. No controller redundancy mechanisms are described.

In other words, as applied to our ANCP = use, the GSMP base protocol allows for what may term a 1-1 control = relationship between a particular access-ports in one partition and a = controller, with other access-ports in other partitions having the same = 1-1 relationship with their controller. For the sake of the discussion, = I'll call this partitioning method "hard = partitioning"

Taking the partitioning concept above a = step further, it is possible to imagine what one may term as = "functional partitioning" scheme. In such a scheme, specific = functions and/or data elements of a particular access-port would have a = 1-1 relationship with a controller uniquely allowed to modify these = functions or access data elements.

In terms of the ANCP use-cases, this = could translate to a set-up whereby for a single access-port, say the = access-port's modem train rate information would communicated to one = controller (let's call it controller X), while the OAM function, or = configuration parameters would be communicated with another controller = (let's call it Y).

More elaborate combinations of such a = scheme could also be possible, eg having the modem train rate be = communicated to both X and Y, while retaining the OAM function's control = only on controller Y.

Given all of the above several = questions appear to be appropriate for a start:
- Is there interest in enabling ANCP = with "hard partitioning"?
- In case of "hard = partitioning", is it expected that each controller will be a = separate entity, or is there also a need to consider controller = partitioning? (Two different partitions on the same access-node have an = ANCP adjacency to the same controller)

- Is there interest in enabling ANCP = with "functional partitioning"?
- In any partitioning scheme (hard of = functional), is there a need to allow for controller redundancy?

I hope that the above is sufficient to = stimulate a discussion and make some progress on the issue of = partitioning.

Kind Regards,
Woj.

------_=_NextPart_001_01C6BD3D.12351CE3-- --===============0406871672== 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 --===============0406871672==-- From ancp-bounces@ietf.org Mon Aug 14 08:34:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCbdn-00039w-4g; Mon, 14 Aug 2006 08:33:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCbdl-00035e-6b for ancp@ietf.org; Mon, 14 Aug 2006 08:33:57 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCbdj-0002RQ-Pt for ancp@ietf.org; Mon, 14 Aug 2006 08:33:57 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 14 Aug 2006 05:33:55 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,120,1154934000"; d="txt'?scan'208,217"; a="36108145:sNHT53751404" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7ECXslf023889; Mon, 14 Aug 2006 08:33:54 -0400 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 k7ECXsAL026770; Mon, 14 Aug 2006 14:33:54 +0200 (MEST) Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 14:33:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6BF9D.E728B983" Date: Mon, 14 Aug 2006 14:33:32 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Draft DSL Forum liaison Thread-Index: Aca/ndp02KWV+1iFR8aFMC44Hb2aYQ== From: "Wojciech Dec \(wdec\)" To: X-OriginalArrivalTime: 14 Aug 2006 12:33:53.0978 (UTC) FILETIME=[E76849A0:01C6BF9D] DKIM-Signature: a=rsa-sha1; q=dns; l=6525; t=1155558834; x=1156422834; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=22Wojciech=20Dec=20\(wdec\)=22=20 |Subject:Draft=20DSL=20Forum=20liaison |To:; X=v=3Dcisco.com=3B=20h=3D8iQGH0fCo6k9Fg67izXJB5Urqfg=3D; b=lSGhO7TdSN/U/k/HDiDVLNzZCEmfqZE9gTxhmrAmS9Ehz+rMWeVZX5oVFR378l0POXieaIoc kB+2dDn+ysNR9gIkrbTmJKzYOla5gLv1Jei1CLgp8/oq6Bd5D6pFSRFK; Authentication-Results: rtp-dkim-1.cisco.com; header.From=wdec@cisco.com; dkim=pass ( 43 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: Matthew.Bocci@alcatel.co.uk Subject: [ANCP] Draft DSL Forum liaison 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6BF9D.E728B983 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C6BF9D.E728B983" ------_=_NextPart_002_01C6BF9D.E728B983 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All, For your review please find attached a draft liaison statement addressed to the DSL Forum providing an update on the ANCP WG activity. Let us know if you have any remarks. Regards, Woj. <<2006-08-10-ANCP-DSLF-liaison.txt>>=20 ------_=_NextPart_002_01C6BF9D.E728B983 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft DSL Forum liaison

Hello All,

For your review please find attached a = draft liaison statement addressed to the DSL Forum providing an update = on the ANCP WG activity. Let us know if you have any remarks.

Regards,
Woj.
= <<2006-08-10-ANCP-DSLF-liaison.txt>>

------_=_NextPart_002_01C6BF9D.E728B983-- ------_=_NextPart_001_01C6BF9D.E728B983 Content-Type: text/plain; name="2006-08-10-ANCP-DSLF-liaison.txt" Content-Transfer-Encoding: base64 Content-Description: 2006-08-10-ANCP-DSLF-liaison.txt Content-Disposition: attachment; filename="2006-08-10-ANCP-DSLF-liaison.txt" VG86IERTTCBGb3J1bSBBcmNoaXRlY3R1cmUgJiBUcmFuc3BvcnQgV29ya2luZyBHcm91cA0KICAg ICAgIERhdmlkIEFsbGFuIDxkYWxsYW5Abm9ydGVsbmV0d29ya3MuY29tPg0KICAgICAgIERhdmlk IFRob3JuZSA8ZGF2aWQuai50aG9ybmVAYnQuY29tPg0KDQoNCkNjOiBJRVRGIHN0YXRlbWVudHNA aWV0Zi5vcmcNCiAgICAgICBKYXJpIEFya2tvIDxqYXJpLmFya2tvQHBpdWhhLm5ldD4NCiAgICAg ICBNYXJrIFRvd25zbGV5IDx0b3duc2xleUBjaXNjby5jb20+DQogICAgICAgQU5DUCBtYWlsaW5n IGxpc3QgPGFuY3BAaWV0Zi5vcmc+DQogICAgICAgDQoNCkZyb206IElFVEYgQU5DUCBXb3JraW5n IEdyb3VwDQoNClJlc3BvbnNlIGNvbnRhY3Q6IAlXb2pjaWVjaCBEZWMgPHdkZWNAY2lzY28uY29t PiwNCgkJIAlNYXR0aGV3IEJvY2NpIDxtYXR0aGV3LmJvY2NpQGFsY2F0ZWwuY29tPg0KDQpUZWNo bmljYWwgY29udGFjdDogV29qY2llY2ggRGVjIDx3ZGVjQGNpc2NvLmNvbT4NCg0KUHVycG9zZTog Rm9yIGluZm9ybWF0aW9uDQoNClN1YmplY3Q6IFVwZGF0ZSBvbiBBTkNQIFdHIGFjdGl2aXR5DQoN Cg0KV2UgYXJlIHBsZWFzZWQgdG8gaW5mb3JtIHlvdSB0aGF0IHRoZSBJRVRGknMgSW50ZXJuZXQg RW5naW5lZXJpbmcgU3RlZXJpbmcgR3JvdXAgYW5kIHRoZSBJbnRlcm5ldCBBcmVhIGRpcmVjdG9y cyBoYXZlIGFncmVlZCB0byBmb3JtIGFuIEFOQ1AgV29ya2luZyBHcm91cCB3aXRoIHRoZSBwdXJw b3NlIG9mIHRoZSBkZWZpbmluZyBhbiBJUCBiYXNlZCBBY2Nlc3MgTm9kZSBDb250cm9sIFByb3Rv Y29sIChBTkNQKSBmb3IgdXNlIGluIHNlcnZpY2UgcHJvdmlkZXIgRGlnaXRhbCBTdWJzY3JpYmVy IExpbmUgKERTTCkgYWNjZXNzIGFuZCBhZ2dyZWdhdGlvbiBuZXR3b3Jrcy4gIFRoaXMgd29yayBp cyBzZWVuIGFzIGNsb3NlbHkgcmVsYXRlZCB0byBEU0wgRm9ydW2ScyBXVC0xNDcgYWN0aXZpdHku DQoNCk91ciBncm91cJJzIGNoYXJ0ZXIsIGRldGFpbHMgb2Ygd2hpY2ggY2FuIGJlIGZvdW5kIGF0 IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaHRtbC5jaGFydGVycy9hbmNwLWNoYXJ0ZXIuaHRtbCwgYWRk cmVzc2VzIHRoZSBmb2xsb3dpbmcgQU5DUCB1c2UtY2FzZXM6DQoNCjEuIER5bmFtaWMgQWNjZXNz IExvb3AgQXR0cmlidXRlcw0KQU5DUCB3aWxsIHByb3ZpZGUgYSBtZWNoYW5pc20gdG8gY29tbXVu aWNhdGUgZHluYW1pYyBhY2Nlc3MtbG9vcCBhdHRyaWJ1dGVzIGZyb20gdGhlIEFjY2VzcyBOb2Rl IChBTikgdG8gdGhlIE5ldHdvcmsgQWNjZXNzIFNlcnZlciAoTkFTKS4NCg0KMi4gQWNjZXNzIExv b3AgQ29uZmlndXJhdGlvbg0KQU5DUCB3aWxsIGFsbG93IGEgTkFTIHRvIHNlbmQgbG9vcC1zcGVj aWZpYyBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIHRvIGFuIEFOIGJhc2VkIG9uIHRoZSByZXN1 bHRzIG9mIHN1YnNjcmliZXIgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gKGUuZy4s IGFmdGVyIEFBQSByZXNwb25zZXMgaGF2ZSBiZWVuIHJlY2VpdmVkIGF0IHRoZSBOQVMpLiANCg0K My4gUmVtb3RlIENvbm5lY3Rpdml0eSBUZXN0DQpBTkNQIHdpbGwgYWxsb3cgYSByZW1vdGUgcHJv Y2VkdXJlIGZvciBhIGxvY2FsIGxvb3AgY29ubmVjdGl2aXR5IHRlc3QgdG8gYmUgdHJpZ2dlcmVk IGZyb20gdGhlIE5BUyB3aXRoIHJlc3VsdHMgY29tbXVuaWNhdGVkIGJhY2sgdG8gdGhlIE5BUy4g DQoNCjQuIE11bHRpY2FzdA0KQU5DUCB3aWxsIHByb3ZpZGUgYSBtZWNoYW5pc20gdG8gY29tbXVu aWNhdGUgdGhlIG5lY2Vzc2FyeSBpbmZvcm1hdGlvbiBleGNoYW5nZSBiZXR3ZWVuIHRoZSBBTiBh bmQgTkFTIHNvIGFzIHRvIGFsbG93IHRoZSBBTiB0byBwZXJmb3JtIHN1YnNjcmliZXIgYm91bmQg bXVsdGljYXN0IGdyb3VwIHJlcGxpY2F0aW9uIGluIGxpbmUgd2l0aCB0aGUgc3Vic2NyaWJlcidz IHBvbGljeSBhbmQgY29uZmlndXJhdGlvbiwgYW5kIGFsc28gYWxsb3cgdGhlIE5BUyB0byBmb2xs b3cgZWFjaCBzdWJzY3JpYmVyJ3MgbXVsdGljYXN0IGdyb3VwIG1lbWJlcnNoaXAuDQoNCk91ciBj dXJyZW50bHkgZGVmaW5lZCBnb2FscyBmb3Jlc2VlIHRoZSBncm91cCB3b3JraW5nIHRvd2FyZHMg YW4gb3ZlcmFsbCBwcm90b2NvbCCTRnJhbWV3b3JrIGFuZCBSZXF1aXJlbWVudHOUIGludGVybmV0 LWRyYWZ0LCBmb2xsb3dlZCBieSBBTkNQIHByb3RvY29sIHNwZWNpZmljYXRpb24gYW5kIE1JQiBk ZWZpbml0aW9uIGludGVybmV0LWRyYWZ0cy4gDQoNCkR1cmluZyB0aGUgSUVURiA2NiBtZWV0aW5n IGhlbGQgaW4gTW9udHJlYWwgb24gSnVseSAxMC0xNSwgd2UgaGFkIHRoZSBvcHBvcnR1bml0eSB0 byBob2xkIG91ciBmaXJzdCBvZmZpY2lhbCBXb3JraW5nIEdyb3VwIG1lZXRpbmcuIFRoZSBhZ2Vu ZGEsIGNvbnRyaWJ1dGlvbiBtYXRlcmlhbHMgYW5kIG1pbnV0ZXMgY2FuIGJlIGZvdW5kIGF0Og0K aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9wdWJsaWMvbWVldGluZ19tYXRlcmlhbHMuY2dp P21lZXRpbmdfbnVtPTY2DQoNClRoZSBXb3JraW5nIEdyb3VwIGhhcyBhY2hpZXZlZCBwcm9ncmVz cyBieSBhZ3JlZWluZyB0byBhZG9wdCBkcmFmdC1vb2doZS1hbmNwLWZyYW1ld29yay0wMCAoaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtb29naGUtYW5jcC1mcmFtZXdv cmstMDAudHh0KSBhcyB0aGUgV29yayBHcm91cJJzIEludGVybmV0LURyYWZ0IHByb3RvY29sIHJl cXVpcmVtZW50cyBkb2N1bWVudC4gDQpVcC10by1kYXRlIGluZm9ybWF0aW9uIG9uIEFOQ1AgSW50 ZXJuZXQtRHJhZnRzIGFuZCBSRkNzIGNhbiBhbHdheXMgYmUgZm91bmQgYXQgaHR0cDovL3Rvb2xz LmlldGYub3JnL3dnL2FuY3ANCg0KV2UgaW52aXRlIHlvdSB0byBrZWVwIHVzIGluZm9ybWVkIG9m IHByb2dyZXNzIG9mIHlvdXIgd29yayBpbiB0aGUgV1QtMTQ3IGFyZWEuDQpXZSBhbHNvIGVuY291 cmFnZSBpbnRlcmVzdGVkIERTTCBGb3J1bSBtZW1iZXJzIHRvIGpvaW4gYW5kIHBhcnRpY2lwYXRl IGluIG91ciBXb3JrIEdyb3VwknMgZGlzY3Vzc2lvbnMgYW5kIGFjdGl2aXRpZXMgdGFraW5nIHBs YWNlIG9uIHRoZSBhbmNwQGlldGYub3JnIG1haWxpbmcgbGlzdCBhbmQgZHVyaW5nIG9mZmljaWFs IFdHIG1lZXRpbmdzLiBEZXRhaWxzIG9uIGhvdyB0byBzdWJzY3JpYmUgdG8gdGhlIG1haWxpbmcg bGlzdCBjYW4gYmUgZm91bmQgb24gb3VyIGNoYXJ0ZXIgcGFnZS4NClRoZSBuZXh0IHRlbnRhdGl2 ZSBtZWV0aW5ncyBvZiB0aGUgSUVURiBBTkNQIFdHIGFyZToNCgktIE5vdiA1LTEwLCAyMDA2IJYg SUVURiA2NyCWIFNhbiBEaWVnbywgQ2FsaWZvcm5pYSwgVVNBDQoJLSBNYXIgMTgtMjMsIDIwMDcg liBJRVRGIDY4IJYgVEJELCBFdXJvcGUuDQo= ------_=_NextPart_001_01C6BF9D.E728B983 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_001_01C6BF9D.E728B983-- From ancp-bounces@ietf.org Mon Aug 14 10:34:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCdWj-00080U-Hg; Mon, 14 Aug 2006 10:34:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCdWi-00080P-Iu for ancp@ietf.org; Mon, 14 Aug 2006 10:34:48 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCdWh-00012G-Uj for ancp@ietf.org; Mon, 14 Aug 2006 10:34:48 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 14 Aug 2006 07:33:09 -0700 X-IronPort-AV: i="4.08,122,1154934000"; d="scan'208,217"; a="577256074:sNHT86210520" x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] Access-Node Partitioning Date: Mon, 14 Aug 2006 10:34:44 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2803B759E3@proton.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Access-Node Partitioning Thread-Index: Aca9PQuJrVahSX6gTl2dilcS7i6uTQCb9RNQ From: "Sanjay Wadhwa" To: "Wojciech Dec \(wdec\)" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd 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="===============0552658830==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0552658830== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6BFAE.C8C7676A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6BFAE.C8C7676A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IMHO, it will help to initially target "hard partitioning" and controller redundancy. The former is useful for instance in scenarios where we would like to terminate residential and business DSL lines on different IP edge nodes.=20 Graceful restart on a single controller helps with resiliency. However controller redundancy eliminates any single point of failure and is explicitly listed in the scope of ANCP charter. Once we are done with the work items in the initial charter we can consider visiting "functional partitioning" (which is more relevant to multi-edge architectures). =20 Regards -Sanjay -----Original Message----- From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] Sent: Friday, August 11, 2006 7:56 AM To: ancp@ietf.org Subject: [ANCP] Access-Node Partitioning Dear All,=20 During our IETF 66 ANCP meeting we briefly discussed the issue of access-node partitioning and I took the action to attempt to commence a discussion on what is actually required. The outcome of this would go into the protocol requirements framework. Brief background.=20 The GSMP protocol (citing RFC3292 here ) allows for a mode of operation whereby an access-node may be controlled by more than one controller by using the technique of partitioning. In effect the "physical" access-node can be partitioned into several virtual access-nodes that are referred to as partitions. The partitions of a physical access-node are isolated from each other by the implementation and the controller assumes that the resources allocated to a partition are at all times available to that partition. No controller redundancy mechanisms are described. In other words, as applied to our ANCP use, the GSMP base protocol allows for what may term a 1-1 control relationship between a particular access-ports in one partition and a controller, with other access-ports in other partitions having the same 1-1 relationship with their controller. For the sake of the discussion, I'll call this partitioning method "hard partitioning" Taking the partitioning concept above a step further, it is possible to imagine what one may term as "functional partitioning" scheme. In such a scheme, specific functions and/or data elements of a particular access-port would have a 1-1 relationship with a controller uniquely allowed to modify these functions or access data elements.=20 In terms of the ANCP use-cases, this could translate to a set-up whereby for a single access-port, say the access-port's modem train rate information would communicated to one controller (let's call it controller X), while the OAM function, or configuration parameters would be communicated with another controller (let's call it Y).=20 More elaborate combinations of such a scheme could also be possible, eg having the modem train rate be communicated to both X and Y, while retaining the OAM function's control only on controller Y. Given all of the above several questions appear to be appropriate for a start:=20 - Is there interest in enabling ANCP with "hard partitioning"?=20 - In case of "hard partitioning", is it expected that each controller will be a separate entity, or is there also a need to consider controller partitioning? (Two different partitions on the same access-node have an ANCP adjacency to the same controller) - Is there interest in enabling ANCP with "functional partitioning"?=20 - In any partitioning scheme (hard of functional), is there a need to allow for controller redundancy?=20 I hope that the above is sufficient to stimulate a discussion and make some progress on the issue of partitioning.=20 Kind Regards,=20 Woj.=20 ------_=_NextPart_001_01C6BFAE.C8C7676A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Access-Node Partitioning

IMHO,=20 it will help to initially target "hard partitioning" and controller=20 redundancy. The former is useful for instance in scenarios where = we would=20 like to terminate residential and business DSL lines on different = IP edge=20 nodes.

Graceful restart on a single = controller helps=20 with resiliency. However controller redundancy eliminates any = single=20 point of failure and is explicitly listed in the scope of ANCP = charter.

Once=20 we are done with the work items in the initial charter we can consider = visiting=20 "functional partitioning" (which is more relevant to multi-edge=20 architectures).

Regards

-Sanjay

-----Original Message-----
From: Wojciech Dec = (wdec)=20 [mailto:wdec@cisco.com]
Sent: Friday, August 11, 2006 7:56=20 AM
To: ancp@ietf.org
Subject: [ANCP] Access-Node=20 Partitioning

Dear All,

During our IETF 66 ANCP meeting we = briefly=20 discussed the issue of access-node partitioning and I took the action = to=20 attempt to commence a discussion on what is actually required. The = outcome of=20 this would go into the protocol requirements framework.

Brief background.
The GSMP protocol (citing RFC3292 here ) allows for a mode of = operation=20 whereby an access-node may be controlled by more than one controller = by using=20 the technique of partitioning. In effect the "physical" access-node = can be=20 partitioned into several virtual access-nodes that are referred to as=20 partitions. The partitions of a physical access-node are isolated from = each=20 other by the implementation and the controller assumes that the = resources=20 allocated to a partition are at all times available to that partition. = No=20 controller redundancy mechanisms are described.

In other words, as applied to our ANCP = use, the=20 GSMP base protocol allows for what may term a 1-1 control relationship = between=20 a particular access-ports in one partition and a controller, with = other=20 access-ports in other partitions having the same 1-1 relationship with = their=20 controller. For the sake of the discussion, I'll call this = partitioning method=20 "hard partitioning"

Taking the partitioning concept above a = step=20 further, it is possible to imagine what one may term as "functional=20 partitioning" scheme. In such a scheme, specific functions and/or data = elements of a particular access-port would have a 1-1 relationship = with a=20 controller uniquely allowed to modify these functions or access data = elements.=20

In terms of the ANCP use-cases, this = could=20 translate to a set-up whereby for a single access-port, say the = access-port's=20 modem train rate information would communicated to one controller = (let's call=20 it controller X), while the OAM function, or configuration parameters = would be=20 communicated with another controller (let's call it Y).

More elaborate combinations of such a = scheme could=20 also be possible, eg having the modem train rate be communicated to = both X and=20 Y, while retaining the OAM function's control only on controller = Y.

Given all of the above several = questions appear to=20 be appropriate for a start:
- = Is there=20 interest in enabling ANCP with "hard partitioning"?
- In case of "hard partitioning", is it expected = that each=20 controller will be a separate entity, or is there also a need to = consider=20 controller partitioning? (Two different partitions on the same = access-node=20 have an ANCP adjacency to the same controller)

- Is there interest in enabling ANCP = with=20 "functional partitioning"?
- In = any=20 partitioning scheme (hard of functional), is there a need to allow for = controller redundancy?

I hope that the above is sufficient to = stimulate a=20 discussion and make some progress on the issue of partitioning. =

Kind Regards,
Woj.

------_=_NextPart_001_01C6BFAE.C8C7676A-- --===============0552658830== 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 --===============0552658830==-- From ancp-bounces@ietf.org Tue Aug 15 04:12:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCu1n-0006ia-5G; Tue, 15 Aug 2006 04:11:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCu1m-0006iV-29 for ancp@ietf.org; Tue, 15 Aug 2006 04:11:58 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCu1j-0000fy-C7 for ancp@ietf.org; Tue, 15 Aug 2006 04:11:58 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GCu1i-000298-Bk; Tue, 15 Aug 2006 08:11:55 +0000 In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2803B759E3@proton.jnpr.net> References: <9BD5D7887235424FA97DFC223CAE3C2803B759E3@proton.jnpr.net> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <7A882747-0A15-40C1-A7AF-E0E7D6A54D57@acm.org> From: Avri Doria Subject: Re: [ANCP] Access-Node Partitioning Date: Tue, 15 Aug 2006 10:11:49 +0200 To: Sanjay Wadhwa X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa 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="===============1923544650==" Errors-To: ancp-bounces@ietf.org --===============1923544650== Content-Type: multipart/alternative; boundary=Apple-Mail-12--918832924 --Apple-Mail-12--918832924 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, I don't if you will find it useful, but the GSMP group did put out an informational of partitioning: http://www.ietf.org/rfc/rfc3532.txt It gets into the complexities of dynamic partitioning somewhat and suggests some terminology. And while http://www.watersprings.org/pub/id/draft-ietf-gsmp-v3-base- spec-08.txt (i will uprev in the next week so it remains an active reference) discusses link redundancy, we never got very far into controller redundancy. ForCES has done a little work in this area that may serve as a useful reference, though they still maintain the notion of a master control and backups. It may serve as a useful reference, though the draft is not yet RFC (soon now, we hope) cheers a. On 14 aug 2006, at 16.34, Sanjay Wadhwa wrote: > IMHO, it will help to initially target "hard partitioning" and > controller redundancy. The former is useful for instance in > scenarios where we would like to terminate residential and business > DSL lines on different IP edge nodes. > Graceful restart on a single controller helps with resiliency. > However controller redundancy eliminates any single point of > failure and is explicitly listed in the scope of ANCP charter. > Once we are done with the work items in the initial charter we can > consider visiting "functional partitioning" (which is more relevant > to multi-edge architectures). > > Regards > -Sanjay > -----Original Message----- > From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] > Sent: Friday, August 11, 2006 7:56 AM > To: ancp@ietf.org > Subject: [ANCP] Access-Node Partitioning > > Dear All, > > During our IETF 66 ANCP meeting we briefly discussed the issue of > access-node partitioning and I took the action to attempt to > commence a discussion on what is actually required. The outcome of > this would go into the protocol requirements framework. > > Brief background. > The GSMP protocol (citing RFC3292 here ) allows for a mode of > operation whereby an access-node may be controlled by more than one > controller by using the technique of partitioning. In effect the > "physical" access-node can be partitioned into several virtual > access-nodes that are referred to as partitions. The partitions of > a physical access-node are isolated from each other by the > implementation and the controller assumes that the resources > allocated to a partition are at all times available to that > partition. No controller redundancy mechanisms are described. > > In other words, as applied to our ANCP use, the GSMP base protocol > allows for what may term a 1-1 control relationship between a > particular access-ports in one partition and a controller, with > other access-ports in other partitions having the same 1-1 > relationship with their controller. For the sake of the discussion, > I'll call this partitioning method "hard partitioning" > > Taking the partitioning concept above a step further, it is > possible to imagine what one may term as "functional partitioning" > scheme. In such a scheme, specific functions and/or data elements > of a particular access-port would have a 1-1 relationship with a > controller uniquely allowed to modify these functions or access > data elements. > > In terms of the ANCP use-cases, this could translate to a set-up > whereby for a single access-port, say the access-port's modem train > rate information would communicated to one controller (let's call > it controller X), while the OAM function, or configuration > parameters would be communicated with another controller (let's > call it Y). > > More elaborate combinations of such a scheme could also be > possible, eg having the modem train rate be communicated to both X > and Y, while retaining the OAM function's control only on > controller Y. > > Given all of the above several questions appear to be appropriate > for a start: > - Is there interest in enabling ANCP with "hard partitioning"? > - In case of "hard partitioning", is it expected that each > controller will be a separate entity, or is there also a need to > consider controller partitioning? (Two different partitions on the > same access-node have an ANCP adjacency to the same controller) > > - Is there interest in enabling ANCP with "functional partitioning"? > - In any partitioning scheme (hard of functional), is there a need > to allow for controller redundancy? > > I hope that the above is sufficient to stimulate a discussion and > make some progress on the issue of partitioning. > > Kind Regards, > Woj. > > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp --Apple-Mail-12--918832924 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi,

I don't if you will find it = useful, but the GSMP group did put out an informational of = partitioning:

http://www.ietf.org/rfc/rfc35= 32.txt

It = gets into the complexities of dynamic partitioning somewhat and suggests = some terminology.

And while http://www.watersprings.org/pub/id/draft-ietf-gsmp-v3-base-spec-08.t= xt (i will uprev in the next week so it remains an active reference) = discusses link redundancy, we never got very far into controller = redundancy.

ForCES has done a little = work in this area that may serve as a useful reference, though they = still maintain the notion of a master control and backups.=A0 It may = serve as a useful reference, though the draft is not yet RFC (soon now, = we hope)

cheers

On 14 aug = 2006, at 16.34, Sanjay Wadhwa wrote:

=
IMHO, it will help to initially target = "hard partitioning" and controller redundancy.=A0 The former is useful = for instance in scenarios where we would like to terminate residential = and business DSL lines on=A0different IP edge = nodes.=A0

Graceful restart on a = single controller=A0helps with=A0resiliency. However=A0controller = redundancy eliminates any single point of failure=A0and=A0is explicitly = listed in the scope of ANCP charter.

Once we are done with the work items in the = initial charter we can consider visiting "functional partitioning" = (which is more relevant to multi-edge = architectures).

=A0

Regards

-Sanjay

-----Original = Message-----
From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]
Sent: = Friday, August 11, 2006 7:56 AM
To: ancp@ietf.org
Subject: = [ANCP] Access-Node Partitioning

Dear All,
During our IETF 66 ANCP meeting we briefly discussed the = issue of access-node partitioning and I took the action to attempt to = commence a discussion on what is actually required. The outcome of = this would go into the protocol requirements = framework.
Brief = background.
The GSMP protocol = (citing RFC3292 here ) allows for a mode of operation whereby an = access-node may be controlled by more than one controller by using the = technique of partitioning. In effect the "physical" access-node can be = partitioned into several virtual access-nodes that are referred to as = partitions. The partitions of a physical access-node are isolated from = each other by the implementation and the controller assumes that the = resources allocated to a partition are at all times available to that = partition. No controller redundancy mechanisms are = described.
In other words, = as applied to our ANCP use, the GSMP base protocol allows for what may = term a 1-1 control relationship between a particular access-ports in = one partition and a controller, with other access-ports in other = partitions having the same 1-1 relationship with their controller. For = the sake of the discussion, I'll call this partitioning method "hard = partitioning"
Taking the = partitioning concept above a step further, it is possible to imagine = what one may term as "functional partitioning" scheme. In such a = scheme, specific functions and/or data elements of a particular = access-port would have a 1-1 relationship with a controller uniquely = allowed to modify these functions or access data elements. =
In terms of the ANCP = use-cases, this could translate to a set-up whereby for a single = access-port, say the access-port's modem train rate information would = communicated to one controller (let's call it controller X), while the = OAM function, or configuration parameters would be communicated with = another controller (let's call it Y).
More elaborate combinations of such a scheme could also be = possible, eg having the modem train rate be communicated to both X and = Y, while retaining the OAM function's control only on controller = Y.
Given all of the above = several questions appear to be appropriate for a start: =
- Is there interest in enabling = ANCP with "hard partitioning"?
- In case of "hard partitioning", is it expected that each = controller will be a separate entity, or is there also a need to = consider controller partitioning? (Two different partitions on the = same access-node have an ANCP adjacency to the same = controller)
- Is there = interest in enabling ANCP with "functional partitioning"? =
- In any partitioning scheme (hard = of functional), is there a need to allow for controller = redundancy?
I hope that = the above is sufficient to stimulate a discussion and make some = progress on the issue of partitioning.
Kind Regards,
Woj.

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

= --Apple-Mail-12--918832924-- --===============1923544650== 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 --===============1923544650==-- From ancp-bounces@ietf.org Tue Aug 15 09:19:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCypE-0001y4-Fp; Tue, 15 Aug 2006 09:19:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCypD-0001xz-7u for ancp@ietf.org; Tue, 15 Aug 2006 09:19:19 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCypD-0001zL-5f for ancp@ietf.org; Tue, 15 Aug 2006 09:19:19 -0400 Received: from ilsmtp01.ecitele.com ([147.234.1.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GCypB-00079T-JK for ancp@ietf.org; Tue, 15 Aug 2006 09:19:19 -0400 In-Reply-To: To: "Wojciech Dec \(wdec\)" Subject: Re: [ANCP] Draft DSL Forum liaison MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.3 September 14, 2004 Message-ID: From: Menachem.Dodge@ecitele.com Date: Tue, 15 Aug 2006 16:19:03 +0300 X-MIMETrack: Serialize by Router on ILSMTP01/ECI Telecom(Release 6.5.3FP1 | December 22, 2004) at 08/15/2006 16:27:48, Serialize complete at 08/15/2006 16:27:48 X-Spam-Score: -1.9 (-) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: ancp@ietf.org, Matthew.Bocci@alcatel.co.uk 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="===============2051994194==" Errors-To: ancp-bounces@ietf.org This is a multipart message in MIME format. --===============2051994194== Content-Type: multipart/alternative; boundary="=_alternative 0049284CC22571CB_=" This is a multipart message in MIME format. --=_alternative 0049284CC22571CB_= Content-Type: text/plain; charset="US-ASCII" Hello Woj, I suggest asking the DSL Forum to look at two of the issues you raised at the end of the Montreal Meeting, namely: 1. Partitioning Issue 2. Security Best Regards, Menachem Dodge "Wojciech Dec \(wdec\)" 14/08/2006 15:33 To cc Matthew.Bocci@alcatel.co.uk Subject [ANCP] Draft DSL Forum liaison Hello All, For your review please find attached a draft liaison statement addressed to the DSL Forum providing an update on the ANCP WG activity. Let us know if you have any remarks. Regards, Woj. <<2006-08-10-ANCP-DSLF-liaison.txt>> [attachment "2006-08-10-ANCP-DSLF-liaison.txt" deleted by Menachem Dodge/ECI Telecom] _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --=_alternative 0049284CC22571CB_= Content-Type: text/html; charset="US-ASCII"
Hello Woj,

I suggest asking the DSL Forum to look at two of the issues you raised at the end of the Montreal Meeting, namely:

1. Partitioning Issue
2. Security

Best Regards,
Menachem Dodge

"Wojciech Dec \(wdec\)" <wdec@cisco.com>

14/08/2006 15:33

To	<ancp@ietf.org>
cc	Matthew.Bocci@alcatel.co.uk
Subject	[ANCP] Draft DSL Forum liaison

Hello All,

For your review please find attached a draft liaison statement addressed to the DSL Forum providing an update on the ANCP WG activity. Let us know if you have any remarks.

Regards,
Woj.
<<2006-08-10-ANCP-DSLF-liaison.txt>> [attachment "2006-08-10-ANCP-DSLF-liaison.txt" deleted by Menachem Dodge/ECI Telecom] _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp

--=_alternative 0049284CC22571CB_=-- --===============2051994194== 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 --===============2051994194==-- From ancp-bounces@ietf.org Mon Aug 28 09:57:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHhbm-0005nf-Fv; Mon, 28 Aug 2006 09:56:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHhbl-0005nZ-KI for ancp@ietf.org; Mon, 28 Aug 2006 09:56:57 -0400 Received: from ilsmtp01.ecitele.com ([147.234.1.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHhbk-0005Ou-0l for ancp@ietf.org; Mon, 28 Aug 2006 09:56:57 -0400 To: ancp@ietf.org, swadhwa@juniper.net, jmoisand@juniper.net, ssubramanian@juniper.net, thomas.haag@t-systems.com, norbert.voigt@siemens.com Subject: [ANCP] Layer 2 Parameters in the Protocol document MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.3 September 14, 2004 Message-ID: From: Menachem.Dodge@ecitele.com Date: Mon, 28 Aug 2006 16:56:49 +0300 X-MIMETrack: Serialize by Router on ILSMTP01/ECI Telecom(Release 6.5.3FP1 | December 22, 2004) at 08/28/2006 17:05:30, Serialize complete at 08/28/2006 17:05:30 X-Spam-Score: 0.3 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 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="===============0514206470==" Errors-To: ancp-bounces@ietf.org This is a multipart message in MIME format. --===============0514206470== Content-Type: multipart/alternative; boundary="=_alternative 004C9D80C22571D8_=" This is a multipart message in MIME format. --=_alternative 004C9D80C22571D8_= Content-Type: text/plain; charset="US-ASCII" Hi, I have a question regarding the "Access-Loop-Circuit-ID" as defined in the document "draft-wadhwa-gsmp-l2control-configuration-01.txt". In the case of an Ethernet based local loop the format is defined as: "Access-Node-Identifier eth slot/port[:vlan-id]" meaning that the vlan-id is optional. In the case of an ATM based local loop the format is defined as: "Access-Node-Identifier atm slot/port:vpi.vci" meaning that the vpi.vci is mandatory. I would like this changed to "Access-Node-Identifier atm slot/port[:vpi.vci]" meaning that the vpi.vci is optional. This would allow for multiple vpi/vci(s) on the same port as a message could be sent without the vpi.vci field. =========================================================================== I have a similar question regarding the "Access-Aggregation-Circuit-ID-ASCII" as defined in the document "draft-wadhwa-gsmp-l2control-configuration-01.txt". In the case of an Ethernet based local loop the format is defined as: "Access-Node-Identifier eth slot/port[:inner-vlan-id][:outer-vlan-id]" meaning that the vlan-ids are optional. In the case of an ATM based local loop the format is defined as: "Access-Node-Identifier atm slot/port:vpi.vci" meaning that the vpi.vci is mandatory. I would like this changed to "Access-Node-Identifier atm slot/port[:vpi.vci]" meaning that the vpi.vci is optional. Thank you kindly. Best Regards, Menachem --=_alternative 004C9D80C22571D8_= Content-Type: text/html; charset="US-ASCII"
Hi,

I have a question regarding the "Access-Loop-Circuit-ID" as defined in the document"draft-wadhwa-gsmp-l2control-configuration-01.txt".

In the case of an Ethernet based local loop the format is defined as:

"Access-Node-Identifier eth slot/port[:vlan-id]" meaning that the vlan-id is optional.

In the case of an ATM based local loop the format is defined as:

"Access-Node-Identifier atm slot/port:vpi.vci" meaning that the vpi.vci is mandatory.

I would like this changed to "Access-Node-Identifier atm slot/port[:vpi.vci]" meaning that the vpi.vci is optional.

This would allow for multiple vpi/vci(s) on the same port as a message could be sent without the vpi.vci field.

===========================================================================

I have a similar question regarding the "Access-Aggregation-Circuit-ID-ASCII" as defined in the document"draft-wadhwa-gsmp-l2control-configuration-01.txt".

In the case of an Ethernet based local loop the format is defined as:

"Access-Node-Identifier eth slot/port[:inner-vlan-id][:outer-vlan-id]" meaning that the vlan-ids are optional.

In the case of an ATM based local loop the format is defined as:

"Access-Node-Identifier atm slot/port:vpi.vci" meaning that the vpi.vci is mandatory.

I would like this changed to "Access-Node-Identifier atm slot/port[:vpi.vci]" meaning that the vpi.vci is optional.

Thank you kindly.

Best Regards,
Menachem
--=_alternative 004C9D80C22571D8_=-- --===============0514206470== 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 --===============0514206470==--