From ancp-bounces@ietf.org Fri Sep 01 05:40:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ5Vh-0008Uf-Vy; Fri, 01 Sep 2006 05:40:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ5Vg-0008UU-Sf for ancp@ietf.org; Fri, 01 Sep 2006 05:40:24 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ5Vg-0004hL-0h for ancp@ietf.org; Fri, 01 Sep 2006 05:40:24 -0400 Received: from unknown (HELO emailfeemea2.jnpr.net) ([172.26.192.142]) by borg.juniper.net with ESMTP; 01 Sep 2006 02:38:30 -0700 X-IronPort-AV: i="4.08,198,1154934000"; d="scan'208,217"; a="583837482:sNHT100782396" Received: from emailemea5.jnpr.net ([172.26.192.134]) by emailfeemea2.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Sep 2006 10:40:21 +0100 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: Fri, 1 Sep 2006 10:40:21 +0100 Message-ID: In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2803B759E3@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Access-Node Partitioning Thread-Index: Aca9PQuJrVahSX6gTl2dilcS7i6uTQCb9RNQA371fVA= From: "Derek Harkness" To: "Sanjay Wadhwa" , "Wojciech Dec \(wdec\)" , X-OriginalArrivalTime: 01 Sep 2006 09:40:21.0964 (UTC) FILETIME=[A4CC88C0:01C6CDAA] X-Spam-Score: 0.1 (/) X-Scan-Signature: ff67cea9f7df2d77f61a364cea0926e8 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="===============1369881205==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1369881205== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6CDAA.A4B6D6CA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6CDAA.A4B6D6CA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Apoloigies for late response but I was off buying some wine for a while there............... =20 In summary I know of multiple service provider demands for both hard partitioning and redundancy. I have yet to come across service provider demands for functional partitioning. =20 Therefore I would prioritise them accordingly. =20 Customer scenarios for hard partitioning I have been made aware of include: =20 (i) Residential/business split ( services often provided by different IP edges belonging to different organisations within a provider ) (ii) Capacity planning ( i.e. a large AN which is mapped to a controller/NAS which has reached it's capacity and therefore further ports need to be turned up on another node )=20 (iii) Wholesale scenarios ( a provider sells a "viirtual AN" to a retail provider ). =20 Redundancy is also a scenario service providers are very interested in. =20 Note that without wishing to get into that single edge / multi edge / holy grail thing, if you solve the redundancy problem then you may also be able to use this solution for a multi edge scenario ( your "internet" and your "karaoke on demand" IP edges appear to be active/active redundant, if that makes sense. ) =20 I'm not sure functional partitioning solves multi edge ( maybe both edges want to know the line BW ? ) and if I have a node which is informed of the BW then it is probably providing a service across that line and will want to verify via OAM if it's working.=20 =20 Maybe for line config I could see functional partitioning being useful - with ANs having some kind of line config relationship with a "master controller" but I think we are looking at corner cases here and getting away from the main focus. =20 Cheers, =20 Derek. =20 =20 =20 =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 Systems Engineer Juniper Networks=20 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 =20 ________________________________ From: Sanjay Wadhwa=20 Sent: 14 August 2006 16:35 To: Wojciech Dec (wdec); ancp@ietf.org Subject: RE: [ANCP] Access-Node Partitioning 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 =09 =09 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_01C6CDAA.A4B6D6CA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Access-Node Partitioning
Apoloigies for late response but I was off = buying some wine=20 for a while there...............
 
In summary I know of multiple service provider = demands for=20 both hard partitioning and redundancy.
I have yet to come across service provider = demands for=20 functional partitioning.
 
Therefore I would prioritise them=20 accordingly.
 
Customer scenarios for hard partitioning I have = been made=20 aware of include:
 
(i) Residential/business split ( services often = provided by=20 different IP edges belonging to different organisations within a = provider=20 )
(ii) Capacity planning ( i.e. a large AN which = is mapped to=20 a controller/NAS which has reached it's capacity and therefore further = ports=20 need to be turned up on another node )
(iii) Wholesale scenarios ( a provider sells a = "viirtual=20 AN" to a retail provider ).
 
Redundancy is also a scenario service providers = are very=20 interested in.
 
Note that without wishing to get into that = single edge /=20 multi edge / holy grail thing, if you solve the redundancy problem then = you may=20 also be able to use this solution for a multi edge scenario ( your = "internet"=20 and your "karaoke on demand" IP edges appear to be active/active = redundant, if=20 that makes sense. )
 
I'm not sure functional partitioning = solves multi edge=20 ( maybe both edges want to know the line BW ? ) and if I have a node = which is=20 informed of the BW then it is probably providing a service across that = line and=20 will want to verify via OAM if it's working.
 
Maybe for line config I could see functional = partitioning=20 being useful - with ANs having some kind of line config relationship = with a=20 "master controller" but I think we are looking at corner cases here and = getting=20 away from the main focus.
 
    Cheers,
 
        = Derek.
 
 
 
 
+=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
Systems Engineer
Juniper Networks
Nymphenburger = Strasse=20 13-15
80335 Munich
Germany
Tel: +49 89 5529 4916
Mobile: +49 = 172 843=20 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: Sanjay Wadhwa
Sent: = 14 August=20 2006 16:35
To: Wojciech Dec (wdec); = ancp@ietf.org
Subject:=20 RE: [ANCP] 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_01C6CDAA.A4B6D6CA-- --===============1369881205== 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 --===============1369881205==-- From ancp-bounces@ietf.org Sat Sep 09 05:54:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLzXU-0006ZX-0h; Sat, 09 Sep 2006 05:54:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLzXS-0006ZR-HB; Sat, 09 Sep 2006 05:54:14 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLzXO-0000V3-Ru; Sat, 09 Sep 2006 05:54:14 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 09 Sep 2006 02:54:10 -0700 X-IronPort-AV: i="4.09,135,1157353200"; d="txt'?scan'208,217"; a="40753419:sNHT63848832" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k899s9aZ031711; Sat, 9 Sep 2006 05:54:10 -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 k899s9g2022505; Sat, 9 Sep 2006 11:54:09 +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); Sat, 9 Sep 2006 11:54:08 +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_01C6D3F5.E49D90C4" Date: Sat, 9 Sep 2006 11:53:49 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Liaison statement on progress in the ANCP WG Thread-Index: AcbT9di+E5i9VT6mSEWlh/zgc74Tgg== From: "Wojciech Dec \(wdec\)" To: "David Allan" , X-OriginalArrivalTime: 09 Sep 2006 09:54:08.0761 (UTC) FILETIME=[E4E9BE90:01C6D3F5] DKIM-Signature: a=rsa-sha1; q=dns; l=6577; t=1157795650; x=1158659650; c=relaxed/simple; s=rtpdkim2001; 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:Liaison=20statement=20on=20progress=20in=20the=20ANCP=20WG=20 |To:=22David=20Allan=22=20, =20; X=v=3Dcisco.com=3B=20h=3DALxWuNdeABwdahptWOvvWtsc5xM=3D; b=MTEi8z3uHOUWjEMZRa+POLbBA0fxHutvZpF8jYLElqZzBCdIvZBTPXJzsoAdwpUrR3JwyAK2 ZUWEd471CWUOH9VYm4JC/gO9arDobyjj94ZFXvG1pFtTcw5aNoFvPBM4; Authentication-Results: rtp-dkim-2.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: 7da5a831c477fb6ef97f379a05fb683c Cc: statements@ietf.org, jari.arkko@piuha.net, ancp@ietf.org, gavin.young@connectfree.co.uk, Matthew.Bocci@alcatel.co.uk Subject: [ANCP] Liaison statement on progress in the ANCP WG 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_01C6D3F5.E49D90C4 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C6D3F5.E49D90C4" ------_=_NextPart_002_01C6D3F5.E49D90C4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear David, David, please find attached a liaison statement from the ANCP Work Group containing an update on WG's activity. Kind Regards, Wojciech Dec IETF ANCP Working Group Co-chair <<2006-09-ANCP-DSLF-liaison.txt>>=20 ------_=_NextPart_002_01C6D3F5.E49D90C4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Liaison statement on progress in the ANCP WG

Dear David, David,

please find attached a liaison = statement from the ANCP Work Group containing an update on WG's = activity.

Kind Regards,
Wojciech Dec

IETF ANCP Working Group Co-chair
= <<2006-09-ANCP-DSLF-liaison.txt>>


------_=_NextPart_002_01C6D3F5.E49D90C4-- ------_=_NextPart_001_01C6D3F5.E49D90C4 Content-Type: text/plain; name="2006-09-ANCP-DSLF-liaison.txt" Content-Transfer-Encoding: base64 Content-Description: 2006-09-ANCP-DSLF-liaison.txt Content-Disposition: attachment; filename="2006-09-ANCP-DSLF-liaison.txt" VG86IERTTCBGb3J1bSBBcmNoaXRlY3R1cmUgJiBUcmFuc3BvcnQgV29ya2luZyBHcm91cA0KICAg ICAgIERhdmlkIEFsbGFuIDxkYWxsYW5Abm9ydGVsbmV0d29ya3MuY29tPg0KICAgICAgIERhdmlk IFRob3JuZSA8ZGF2aWQuai50aG9ybmVAYnQuY29tPg0KDQoNCkNjOiBJRVRGIHN0YXRlbWVudHNA aWV0Zi5vcmcNCiAgICAgICBKYXJpIEFya2tvIDxqYXJpLmFya2tvQHBpdWhhLm5ldD4NCiAgICAg ICBNYXJrIFRvd25zbGV5IDx0b3duc2xleUBjaXNjby5jb20+DQoJIEdhdmluIFlvdW5nIDxnYXZp bi55b3VuZ0Bjb25uZWN0ZnJlZS5jby51az4NCiAgICAgICANCg0KRnJvbTogSUVURiBBTkNQIFdv cmtpbmcgR3JvdXANCg0KUmVzcG9uc2UgY29udGFjdDogCVdvamNpZWNoIERlYyA8d2RlY0BjaXNj by5jb20+LA0KCQkgCU1hdHRoZXcgQm9jY2kgPG1hdHRoZXcuYm9jY2lAYWxjYXRlbC5jb20+DQoN ClRlY2huaWNhbCBjb250YWN0OiBXb2pjaWVjaCBEZWMgPHdkZWNAY2lzY28uY29tPg0KDQpQdXJw b3NlOiBGb3IgaW5mb3JtYXRpb24NCg0KU3ViamVjdDogVXBkYXRlIG9uIEFOQ1AgV0cgYWN0aXZp dHkNCg0KDQpXZSBhcmUgcGxlYXNlZCB0byBpbmZvcm0geW91IHRoYXQgdGhlIElFVEaScyBJbnRl cm5ldCBFbmdpbmVlcmluZyBTdGVlcmluZyBHcm91cCBhbmQgdGhlIEludGVybmV0IEFyZWEgZGly ZWN0b3JzIGhhdmUgYWdyZWVkIHRvIGZvcm0gYW4gQU5DUCBXb3JraW5nIEdyb3VwIHdpdGggdGhl IHB1cnBvc2Ugb2YgdGhlIGRlZmluaW5nIGFuIElQIGJhc2VkIEFjY2VzcyBOb2RlIENvbnRyb2wg UHJvdG9jb2wgKEFOQ1ApIGZvciB1c2UgaW4gc2VydmljZSBwcm92aWRlciBEaWdpdGFsIFN1YnNj cmliZXIgTGluZSAoRFNMKSBhY2Nlc3MgYW5kIGFnZ3JlZ2F0aW9uIG5ldHdvcmtzLiAgVGhpcyB3 b3JrIGlzIHNlZW4gYXMgY2xvc2VseSByZWxhdGVkIHRvIERTTCBGb3J1bZJzIFdULTE0NyBhY3Rp dml0eS4NCg0KT3VyIGdyb3VwknMgY2hhcnRlciwgZGV0YWlscyBvZiB3aGljaCBjYW4gYmUgZm91 bmQgYXQgaHR0cDovL3d3dy5pZXRmLm9yZy9odG1sLmNoYXJ0ZXJzL2FuY3AtY2hhcnRlci5odG1s LCBhZGRyZXNzZXMgdGhlIGZvbGxvd2luZyBBTkNQIHVzZS1jYXNlczoNCg0KMS4gRHluYW1pYyBB Y2Nlc3MgTG9vcCBBdHRyaWJ1dGVzDQpBTkNQIHdpbGwgcHJvdmlkZSBhIG1lY2hhbmlzbSB0byBj b21tdW5pY2F0ZSBkeW5hbWljIGFjY2Vzcy1sb29wIGF0dHJpYnV0ZXMgZnJvbSB0aGUgQWNjZXNz IE5vZGUgKEFOKSB0byB0aGUgTmV0d29yayBBY2Nlc3MgU2VydmVyIChOQVMpLg0KDQoyLiBBY2Nl c3MgTG9vcCBDb25maWd1cmF0aW9uDQpBTkNQIHdpbGwgYWxsb3cgYSBOQVMgdG8gc2VuZCBsb29w LXNwZWNpZmljIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gdG8gYW4gQU4gYmFzZWQgb24gdGhl IHJlc3VsdHMgb2Ygc3Vic2NyaWJlciBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiAo ZS5nLiwgYWZ0ZXIgQUFBIHJlc3BvbnNlcyBoYXZlIGJlZW4gcmVjZWl2ZWQgYXQgdGhlIE5BUyku IA0KDQozLiBSZW1vdGUgQ29ubmVjdGl2aXR5IFRlc3QNCkFOQ1Agd2lsbCBhbGxvdyBhIHJlbW90 ZSBwcm9jZWR1cmUgZm9yIGEgbG9jYWwgbG9vcCBjb25uZWN0aXZpdHkgdGVzdCB0byBiZSB0cmln Z2VyZWQgZnJvbSB0aGUgTkFTIHdpdGggcmVzdWx0cyBjb21tdW5pY2F0ZWQgYmFjayB0byB0aGUg TkFTLiANCg0KNC4gTXVsdGljYXN0DQpBTkNQIHdpbGwgcHJvdmlkZSBhIG1lY2hhbmlzbSB0byBj b21tdW5pY2F0ZSB0aGUgbmVjZXNzYXJ5IGluZm9ybWF0aW9uIGV4Y2hhbmdlIGJldHdlZW4gdGhl IEFOIGFuZCBOQVMgc28gYXMgdG8gYWxsb3cgdGhlIEFOIHRvIHBlcmZvcm0gc3Vic2NyaWJlciBi b3VuZCBtdWx0aWNhc3QgZ3JvdXAgcmVwbGljYXRpb24gaW4gbGluZSB3aXRoIHRoZSBzdWJzY3Jp YmVyJ3MgcG9saWN5IGFuZCBjb25maWd1cmF0aW9uLCBhbmQgYWxzbyBhbGxvdyB0aGUgTkFTIHRv IGZvbGxvdyBlYWNoIHN1YnNjcmliZXIncyBtdWx0aWNhc3QgZ3JvdXAgbWVtYmVyc2hpcC4NCg0K T3VyIGN1cnJlbnRseSBkZWZpbmVkIGdvYWxzIGZvcmVzZWUgdGhlIGdyb3VwIHdvcmtpbmcgdG93 YXJkcyBhbiBvdmVyYWxsIHByb3RvY29sIJNGcmFtZXdvcmsgYW5kIFJlcXVpcmVtZW50c5QgaW50 ZXJuZXQtZHJhZnQsIGZvbGxvd2VkIGJ5IEFOQ1AgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiBhbmQg TUlCIGRlZmluaXRpb24gaW50ZXJuZXQtZHJhZnRzLiANCg0KRHVyaW5nIHRoZSBJRVRGIDY2IG1l ZXRpbmcgaGVsZCBpbiBNb250cmVhbCBvbiBKdWx5IDEwLTE1LCB3ZSBoYWQgdGhlIG9wcG9ydHVu aXR5IHRvIGhvbGQgb3VyIGZpcnN0IG9mZmljaWFsIFdvcmtpbmcgR3JvdXAgbWVldGluZy4gVGhl IGFnZW5kYSwgY29udHJpYnV0aW9uIG1hdGVyaWFscyBhbmQgbWludXRlcyBjYW4gYmUgZm91bmQg YXQ6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3B1YmxpYy9tZWV0aW5nX21hdGVyaWFs cy5jZ2k/bWVldGluZ19udW09NjYNCg0KVGhlIFdvcmtpbmcgR3JvdXAgaGFzIGFjaGlldmVkIHBy b2dyZXNzIGJ5IGFncmVlaW5nIHRvIGFkb3B0IGRyYWZ0LW9vZ2hlLWFuY3AtZnJhbWV3b3JrLTAw IChodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1vb2doZS1hbmNwLWZy YW1ld29yay0wMC50eHQpIGFzIHRoZSBXb3JrIEdyb3VwknMgSW50ZXJuZXQtRHJhZnQgcHJvdG9j b2wgcmVxdWlyZW1lbnRzIGRvY3VtZW50LiANClVwLXRvLWRhdGUgaW5mb3JtYXRpb24gb24gQU5D UCBJbnRlcm5ldC1EcmFmdHMgYW5kIFJGQ3MgY2FuIGFsd2F5cyBiZSBmb3VuZCBhdCBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvd2cvYW5jcA0KDQpXZSBpbnZpdGUgeW91IHRvIGtlZXAgdXMgaW5mb3Jt ZWQgb2YgcHJvZ3Jlc3Mgb2YgeW91ciB3b3JrIGluIHRoZSBXVC0xNDcgYXJlYS4NCldlIGFsc28g ZW5jb3VyYWdlIGludGVyZXN0ZWQgRFNMIEZvcnVtIG1lbWJlcnMgdG8gam9pbiBhbmQgcGFydGlj aXBhdGUgaW4gb3VyIFdvcmsgR3JvdXCScyBkaXNjdXNzaW9ucyBhbmQgYWN0aXZpdGllcyB0YWtp bmcgcGxhY2Ugb24gdGhlIGFuY3BAaWV0Zi5vcmcgbWFpbGluZyBsaXN0IGFuZCBkdXJpbmcgb2Zm aWNpYWwgV0cgbWVldGluZ3MuIERldGFpbHMgb24gaG93IHRvIHN1YnNjcmliZSB0byB0aGUgbWFp bGluZyBsaXN0IGNhbiBiZSBmb3VuZCBvbiBvdXIgY2hhcnRlciBwYWdlLg0KVGhlIG5leHQgdGVu dGF0aXZlIG1lZXRpbmdzIG9mIHRoZSBJRVRGIEFOQ1AgV0cgYXJlOg0KCS0gTm92IDUtMTAsIDIw MDYgliBJRVRGIDY3IJYgU2FuIERpZWdvLCBDYWxpZm9ybmlhLCBVU0ENCgktIE1hciAxOC0yMywg MjAwNyCWIElFVEYgNjggliBUQkQsIEV1cm9wZS4NCg== ------_=_NextPart_001_01C6D3F5.E49D90C4 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_01C6D3F5.E49D90C4-- From ancp-bounces@ietf.org Mon Sep 11 04:01:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMgj5-0001eb-Sb; Mon, 11 Sep 2006 04:01:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GM5YV-0006RD-1n; Sat, 09 Sep 2006 12:19:43 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GM5YT-0002rU-Nz; Sat, 09 Sep 2006 12:19:43 -0400 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k89GJMs08917; Sat, 9 Sep 2006 12:19:23 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 9 Sep 2006 12:19:22 -0400 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE08A2A37E@zcarhxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Liaison statement on progress in the ANCP WG thread-index: AcbT9di+E5i9VT6mSEWlh/zgc74TggANcLYw From: "David Allan" To: "Wojciech Dec \(wdec\)" , "David Allan" , X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 X-Mailman-Approved-At: Mon, 11 Sep 2006 04:01:06 -0400 Cc: statements@ietf.org, jari.arkko@piuha.net, ancp@ietf.org, gavin.young@connectfree.co.uk, Matthew.Bocci@alcatel.co.uk Subject: [ANCP] RE: Liaison statement on progress in the ANCP WG 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="===============0761034919==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0761034919== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D42B.B5BDE781" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D42B.B5BDE781 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI Woj: =20 Can you upload it as a contribution so it is visible to the secretariat....there is a button for liaisons... =20 thx Dave ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: Saturday, September 09, 2006 5:54 AM To: David Allan; david.j.thorne@bt.com Cc: jari.arkko@piuha.net; Mark Townsley (townsley); gavin.young@connectfree.co.uk; statements@ietf.org; Matthew.Bocci@alcatel.co.uk; ancp@ietf.org Subject: Liaison statement on progress in the ANCP WG Dear David, David,=20 please find attached a liaison statement from the ANCP Work Group containing an update on WG's activity.=20 Kind Regards,=20 Wojciech Dec=20 IETF ANCP Working Group Co-chair=20 <<2006-09-ANCP-DSLF-liaison.txt>>=20 ------_=_NextPart_001_01C6D42B.B5BDE781 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Liaison statement on progress in the ANCP WG
HI Woj:
 
Can you upload it as a contribution so it is = visible to the=20 secretariat....there is a button for liaisons...
 
thx
Dave

From: Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com]
Sent: Saturday, September 09, 2006 = 5:54=20 AM
To: David Allan; david.j.thorne@bt.com
Cc:=20 jari.arkko@piuha.net; Mark Townsley (townsley); = gavin.young@connectfree.co.uk;=20 statements@ietf.org; Matthew.Bocci@alcatel.co.uk;=20 ancp@ietf.org
Subject: Liaison statement on progress in the = ANCP=20 WG

Dear David, David,

please find attached a liaison statement = from the=20 ANCP Work Group containing an update on WG's activity.

Kind Regards,
Wojciech Dec

IETF ANCP Working Group Co-chair =
<<2006-09-ANCP-DSLF-liaison.txt>>=20


------_=_NextPart_001_01C6D42B.B5BDE781-- --===============0761034919== 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 --===============0761034919==--